Introducing Agent Inbox: email inboxes for AI agents
Give each agent its own mailbox—provisioned by API, threaded for replies, and gated by Ask before anything leaves.
Discuss this post in AI
Send a pre-filled prompt to ChatGPT, Claude, Gemini, or Perplexity — get a summary, ask follow-ups, or compare ideas from this guide.
Agents that only speak inside a chat UI are incomplete workers. Real company work still arrives as email: vendor invoices, customer replies, OTP codes, support escalations, and threads that a human forwarded because the agent should own the next step. Pattern Automation built Agent Inbox so a role on Neuro OS can have a mailbox of its own—not a borrowed Gmail OAuth session, not a shared alias that five people monitor, and not a fire-and-forget send API that cannot receive the reply.
Why a mailbox the agent owns
OAuth into a person’s inbox couples the agent’s identity to that person’s career, vacation, and permission model. When the person leaves, the agent loses its channel. When compliance asks who sent a message, the answer is muddy. An agent inbox flips the model: the address belongs to the role, credentials are scoped to the role, and humans remain owners of policy—not of the mailbox itself.
Provisioning is an API call. Create an inbox with a username and domain, then attach that address to a Neuro OS role the same way you attach a connector or a skill.
from agentinbox import AgentInbox
client = AgentInbox()
inbox = client.inboxes.create(username="hello", domain="agentinbox.space")
Python, TypeScript, and cURL SDKs cover the same surface. MCP exposes inbox tools to agents that already speak the protocol. Attachments can be read and extracted so a role can act on PDFs and images without inventing a second pipeline.
Forwarding is first-class
Operational reality is messy. A customer emails a founder. Finance CC’s a shared box. Bitrix or amoCRM fires a notification that should become agent work. Forwarding (“пересылка”) is how those threads enter the agent’s world without rewriting every upstream system. Humans and other systems forward into the agent inbox; when Ask requires review, the agent can forward the thread back to a person with context intact.
That loop is the product: inbound thread → role skill → proposed reply → Ask → send or escalate. Outbound mail defaults to Ask on Neuro OS. The agent drafts; a human confirms. Self-host when policy requires the mailbox and the runtime to stay inside your boundary.
What Agent Inbox is not
It is not a human mail client with unread badges and keyboard shortcuts. It is an inbox API for agents: create inboxes, read thread history, send replies, extract attachments, and wire webhooks into Neuro OS. It is also not a claim that SMTP alone makes an agent autonomous. Deliverability, domain authentication, and tenant isolation still matter—see email deliverability and multi-tenant isolation.
How it fits Neuro OS
Neuro OS keeps roles in git, runs them in sandboxes, brokers connectors server-side, and lets you pick any approved model. Agent Inbox is the email channel for those roles. A support role gets support@…, a billing role gets billing@…, and a coding agent that needs registry OTPs gets an address that vendors can actually reach. Writes and sends stay behind Ask unless you deliberately widen the gate.
If you are choosing between a notify-only send API and an owned mailbox, read email API vs inbox API. If you want the full loop—provision, send, threaded inbound, webhook, Ask, act—start with the definitive guide.
Agent Inbox exists so agents stop pretending chat is the only channel that matters. Give the role an address people can reply to, keep humans on the send path, and treat email as infrastructure for company automation—not a side quest bolted onto a demo.
Agent Inbox gives each role a mailbox people can reply to, with forwarding into Neuro OS when a human must see the thread. Outbound mail defaults to Ask. Run the role on Neuro OS. To scope the first inbox, get started.