# What Is an Agentic Inbox? (And How to Build One)

Published: August 6, 2026

An agentic inbox is a real mailbox owned by an AI agent. Learn what it needs, then provision one by API, receive via webhook, and reply in-thread.

An agentic inbox is a real, addressable mailbox owned by an AI agent rather than a person. It has its own address, receives mail over the internet, delivers each inbound message to code as structured JSON, and lets the agent reply in the same thread. The distinguishing feature is not that AI drafts the text, it is that the mailbox itself is a programmable endpoint: no IMAP polling, no shared human inbox, no human in the send path.

That definition matters because "AI inbox" has been claimed by two very different products. One is an assistant that sits on top of your personal Gmail and suggests replies. The other, the agentic inbox, is infrastructure: an identity your agent owns, so it can transact with the outside world by email. This post covers the second one, what it requires operationally, and how to stand one up in a few minutes.

## What makes an inbox "agentic"

Five properties separate an agentic inbox from a mailbox that a human happens to automate.

**It has a real address on a real domain.** Not a plus-alias on your personal account, not a catch-all you grep. `shopping-agent@yourdomain.com` is where vendors reply, where password resets land, where a counterparty starts a thread. Address ownership is what makes the agent a participant instead of a spectator.

**Inbound is push, not pull.** The agent should not run a cron job against IMAP. A message arrives, the provider parses MIME, and your handler gets a webhook POST with sender, subject, body text, thread id, and attachment references. Latency drops from minutes to seconds and you stop writing dedupe logic against message flags.

**Send and receive live in the same system.** Bulk ESPs are one-directional by design. An agent that can send but not receive cannot do anything conversational, which is most of the interesting work. See [sending and receiving](/blog/sending-and-receiving) for why the split causes so much pain.

**Threading is handled for you.** A reply must carry the right `In-Reply-To` and `References` headers or Gmail and Outlook will show it as a new, disconnected message. Humans notice. Agents that break threads get ignored or marked as spam.

**It is provisionable per agent.** One mailbox per agent, per task, or per customer, created and destroyed by API. This is the difference between an architecture and a workaround. If your agent count can grow to hundreds, manual mailbox creation in an admin console is already the bottleneck.

## Why not just use Gmail or an SMTP relay

Two default answers, both of which break in production.

| Approach | Inbound | Threading | Per-agent provisioning | Failure mode |
|---|---|---|---|---|
| Gmail / Workspace API | Polling or Pub/Sub, OAuth scoped to a human | Manual header work | Seat-based, admin console | Rate limits, token refresh, ToS friction for automation |
| SMTP relay / bulk ESP | Usually none, or a bolted-on parse route | Manual | Domain-level, not mailbox-level | Agent can send but never hear back |
| Agentic inbox provider | Webhook push, parsed JSON | Automatic on reply | API call per mailbox | You still own reputation and content quality |

Gmail was built for a person with a browser. Every automation you layer on it fights that assumption, which is why so many teams end up at [Gmail and Outlook don't work for agents](/blog/gmail-outlook-dont-work). Bulk senders were built for one-way campaigns. Neither was designed around an autonomous process that needs an identity.

If you are weighing running your own Postfix plus a MIME parser, we have written the honest version of that tradeoff in [build vs buy for agent email](/blog/build-vs-buy-agent-email). Short version: receiving mail correctly is much harder than sending it, and the hard parts are DNS, spam filtering, MIME edge cases, and deliverability reputation, none of which are interesting to your product.

## How to build an agentic inbox: the managed path

Three steps. Provision, receive, reply.

### 1. Provision the mailbox

From the CLI, one command per agent:

```bash
npx @robotomail/cli mailbox create shopping-agent
```

Or from your own code, so a new mailbox can be created the moment a new agent or customer workspace spins up:

```bash
curl -X POST https://api.robotomail.com/v1/mailboxes \
  -H "Authorization: Bearer rm_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"address": "shopping-agent"}'
```

Omit `domainId` and the mailbox lands on a platform domain, which is fine for development and internal tools. Pass a verified domain's UUID and the agent gets an address on your own domain, which is what you want anytime a human on the other side will read the From line. Details in [custom domains](/docs/guides/custom-domain).

Naming matters more than it looks. Use names a recipient can parse: `orders-agent`, `support-intake`, `recruiting-bot`. Opaque identifiers like `a7f3c2@` look like throwaway spam addresses and get treated that way. More on the mailbox model in [concepts: mailboxes](/docs/concepts/mailboxes).

### 2. Receive inbound as JSON

Register a webhook endpoint once, then every message to that mailbox is delivered as a POST. The envelope is `{ event, timestamp, data }` with snake_case fields inside `data`:

```json
{
  "event": "message.received",
  "data": {
    "message_id": "...",
    "mailbox_id": "...",
    "mailbox_address": "shopping-agent@robotomail.co",
    "from": "vendor@example.com",
    "subject": "Re: Order #A-4521 delivery update?",
    "body_text": "It ships Thursday.",
    "thread_id": "...",
    "received_at": "2026-04-17T10:00:00.000Z"
  }
}
```

Your handler does the boring but important work before the model ever sees the text:

```python
from fastapi import FastAPI, Request

app = FastAPI()

@app.post("/inbound")
async def inbound(request: Request):
    payload = await request.json()
    if payload["event"] != "message.received":
        return {"ok": True}

    msg = payload["data"]

    # 1. Ack fast, work async. Webhook handlers should return in under a second.
    enqueue_agent_turn(
        mailbox_id=msg["mailbox_id"],
        thread_id=msg["thread_id"],
        message_id=msg["message_id"],
        sender=msg["from"],
        subject=msg["subject"],
        body=msg["body_text"],
    )
    return {"ok": True}
```

Three rules we would enforce in review on any handler like this:

1. **Return 200 immediately and process in a queue.** If your model call takes 20 seconds, the delivery attempt may time out and retry, and you will send duplicate replies.
2. **Deduplicate on `message_id`.** Any at-least-once delivery system will occasionally deliver twice. Store the id, skip the repeat.
3. **Treat `body_text` as untrusted input.** Inbound email is the widest prompt-injection surface an agent has. Anyone can email your agent. Keep tool permissions narrow, and never let email content alone authorize a payment, a credential change, or a data export.

Webhook setup specifics, including verification and retries, are in [concepts: webhooks](/docs/concepts/webhooks).

### 3. Reply in the same thread

The agent's reply is a send call against the mailbox, with `inReplyTo` set to the inbound message id. That is what keeps the conversation stitched together in the recipient's client.

```bash
curl -X POST https://api.robotomail.com/v1/mailboxes/mbx_shopping/messages \
  -H "Authorization: Bearer rm_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"to": ["vendor@example.com"], "subject": "Order #A-4521 delivery update?", "bodyText": "Thanks, noting Thursday. Will there be a tracking number?"}'
```

For a first outbound message, omit `inReplyTo`. For replies, include it and the headers are set correctly for you. Why this is fiddly to do by hand is covered in [what is email threading](/blog/what-is-email-threading), and the end-to-end walkthrough lives in [receive and reply](/docs/guides/receive-and-reply).

## Design decisions you will hit next

**One mailbox per agent, or one per conversation?** Per agent is the default and usually right: a stable address builds recognition and sending reputation. Go per-conversation or per-customer when isolation matters, for example a legal intake flow where each matter must be separable, or a multi-tenant SaaS where a customer's thread should never leak into another's context. [Multi-agent architecture](/blog/multi-agent-architecture) walks through the routing patterns.

**What is the agent's context window on a thread?** The webhook gives you one message. The agent usually needs the thread. Fetch the thread and pass a trimmed history, oldest to newest, rather than replaying the entire quoted chain. Quoted text balloons token counts and confuses models about what is new.

**When does the agent stop and ask a human?** Decide this before launch, not after an incident. Common tripwires: any message mentioning money above a threshold, any request to change an address or bank detail, any thread where the agent has already sent three messages without resolution, any inbound from an unknown sender to a mailbox that should only see known counterparties.

**Deliverability is still your job.** A managed inbox handles MX, parsing, and header hygiene. It does not make bad sending behavior land. Publish SPF, DKIM, and DMARC on your custom domain, keep volume proportional to engagement, and honor unsubscribe intent even when the recipient phrases it casually. Start with [how to configure DKIM](/blog/how-to-configure-dkim) and [publish a DMARC record](/blog/publish-dmarc-record).

## What people build with agentic inboxes

The pattern shows up wherever a workflow was already conducted over email between humans:

- **Order and vendor follow-up.** Agent emails a supplier, parses the reply, updates the order record, escalates when the answer is ambiguous. See [ecommerce orders](/use-cases/ecommerce-orders).
- **Inbound intake.** A public address collects requests, the agent classifies, asks clarifying questions in-thread, and files a structured record. Related: [email to ticket system](/blog/email-to-ticket-system).
- **Scheduling.** The agent negotiates a time across two or three participants, which is almost entirely a threading and state problem. See [appointment booking](/use-cases/appointment-booking).
- **Monitoring in reverse.** The agent receives alerts by email from tools that only speak email, then acts. See [monitoring and alerting](/use-cases/monitoring-alerting).
- **Coding agents that report back.** Long-running jobs email their results and take instructions by reply, covered in [email for Claude Code](/blog/email-claude-code).

The full list is on [use cases](/use-cases).

## FAQ

### Is an agentic inbox the same thing as an AI email assistant?

No. An assistant helps a human manage their own inbox: drafting, sorting, summarizing. An agentic inbox is a mailbox the agent owns and operates, with its own address and no human in the send loop. Different intent, different architecture.

### Can I use my own domain?

Yes, and you should for anything customer-facing. Verify the domain, publish the DNS records, then create mailboxes against that domain's id. Walkthrough in [custom domain setup](/docs/guides/custom-domain).

### How do I stop the agent from replying to spam or looping with another bot?

Rate limit per thread and per sender, cap the number of consecutive agent messages without a human reply, and never auto-reply to bounces or automated notifications. Detecting `auto-submitted` headers and no-reply sender patterns catches most loops. See [email automation best practices](/blog/email-automation-best-practices).

### Do I need to parse MIME or handle attachments myself?

No. Inbound is parsed for you and attachments are exposed as retrievable resources rather than raw base64 in the webhook body. See [concepts: attachments](/docs/concepts/attachments).

Ready to give an agent its own inbox? Create a mailbox in one API call and point a webhook at your handler, start at [robotomail.com](https://robotomail.com) or read the [quickstart](/docs/quickstart).