IMAP for agent inboxes: when the protocol still matters
API-first inboxes are the default. IMAP remains useful for migrations, human clients, and tools that already speak the old protocol.
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 should not scrape a mailbox the way a 2008 desktop client did. The production path is an inbox API: create an address, list threads, read bodies, send a reply, and fire a webhook when mail arrives. IMAP is still useful as a compatibility layer—for migrations, for a human who wants to inspect the same mailbox in Apple Mail, and for tools that already speak IMAP and will not grow an SDK this quarter.
API-first, IMAP second
Agent Inbox is built so a Neuro OS role can own a mailbox without borrowing a person’s Gmail. Webhooks and SDKs are how the role should work. Polling IMAP every thirty seconds is how you recreate rate limits, missed UIDVALIDITY events, and a backlog of unread flags the model does not understand.
Use IMAP when:
- You are moving history out of a legacy mailbox and need a standard fetch path.
- A human operator must open the same address in a mail client during an incident.
- A partner system can only subscribe over IMAP and you refuse to stand up a second store.
Do not use IMAP as the agent’s primary loop. The agent needs thread objects, attachment extraction, and Ask on outbound—not a folder tree and a sequence number.
What IMAP does not give you
IMAP was designed for people who leave messages on a server and sync clients. It does not provision a new identity. It does not isolate tenants. It does not enforce Neuro OS Ask. It does not turn a forwarded customer thread into a role skill. Those jobs sit above the protocol.
If you only connect IMAP to a shared human inbox, you still have the identity problem: the agent is a parasite on someone else’s address. Provision the inbox first. Then, if you must, expose IMAP against that inbox so humans and legacy tools can read the same store.
Forwarding still beats scraping
Operational mail often starts elsewhere. A founder forwards a vendor thread. Bitrix dumps a notification. Finance CC’s a shared alias. Forwarding (“пересылка”) into the agent inbox is cleaner than teaching the agent to poll three IMAP accounts. Humans and systems drop work into the role’s address; the webhook wakes Neuro OS; Ask gates the reply.
A practical split
| Job | Mechanism |
|---|---|
| Role owns an address | Inbox API create |
| Agent reads and replies | SDK / MCP / webhook |
| Human inspects the same box | IMAP (optional) |
| Work arrives from another system | Forward into the agent address |
| Outbound leaves the building | Ask on Neuro OS |
IMAP support is a bridge, not a strategy. Give the agent a real inbox, keep the protocol for the cases that still need it, and run the role on Neuro OS so a human stays on the send path.
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.