Customer emails support@. The agent drafts a reply as support-agent@. The customer answers. The agent is wrong. A person opens the same thread and continues. Six months later you can search what was promised.
That is the loop most agent demos skip. They stop at send: the model writes a message, an API key fires it, and the screenshot looks done. Production is the other direction. Replies arrive. Exceptions appear. A human has to take over. Someone has to prove what was said.
A send-only key is a megaphone. Agents that talk to people need a mailbox.
What an agent actually needs
Sending is the easy half. The rest looks like ordinary mail, which is the point.
- A stable identity on a domain you control, not a shared sandbox address.
- An inbox that keeps the thread, not a log that expires with a transactional plan.
- A reply-to a person can reach if the agent is wrong or stuck.
- A way for a teammate to open the same conversation and continue as the company.
- Headers, a searchable record, and attachments stored with the mail.
If any of those are missing, the agent is a notifier. Notifiers are useful. They are not correspondents.
Conversations and product mail are different jobs
Do not put every agent message on the transactional sending path. Transactional mail is the mail your product must send because something happened: receipts, password resets, invites, alerts. Those messages should stay on the API. Conversations should live in a mailbox.
- Receipts, resets, 2FA. Transactional API. Event-triggered. No back-and-forth.
- Anything a human might reply to. Mailbox, plus a webhook or MCP connection so the agent can act.
- One workflow, one mailbox.
support-agent@orbilling-agent@, not a shared personal inbox.
Mailbox mail stays until you delete it. Transactional copies are retained for 45 to 90 days by plan. If the agent is corresponding, the mailbox is the system of record. Read what transactional email is before you let an agent own a stream.
Webhooks are not an inbox
Posting inbound JSON to a Worker or a queue is the right way to automate. It is the wrong place to store the conversation. Operators still need to open a message, search last week, and reply as the same address the customer already trusts.
Build the automation against the mailbox. Do not make the automation be the mailbox. ArawaMail keeps the message in the inbox even when the webhook endpoint is down. After three failed attempts the notification is dropped. The mail is not. Deduplicate on id or message_id. Fetch attachments from the signed URL within 24 hours if your agent needs the file.
One more operational detail: mail that lands in Spam does not appear in Inbox, normal search, unread counts, or incoming-email webhooks. If the agent never saw the complaint, check Spam before you assume the parser failed. The incoming-mail webhook guide and the mailbox guide cover the contract.
One domain for people and agents
Customers do not care that one letter came from the product and the next from an agent. They care that billing@ and support@ stay consistent. Put staff and agents on the same authenticated domain. That is the same reason to keep inboxes and product email together.
Give the agent a real mailbox you create under Email accounts: [email protected], or one mailbox per workflow. A person can open that mailbox from the workspace. API-originated sends are written to Sent so outbound activity is visible next to the thread.
Restrict the sending API key to the company domain. Today a sending key is not locked to a single mailbox address, so the agent should still send as its own address. Do not hand it a key that also fires password resets.
How to wire it
- Activate receiving and sending on the company domain.
- Create a dedicated mailbox for the agent.
- Connect the agent with MCP on that mailbox, or listen to incoming-mail webhooks and send through the API.
- Keep the conversation in the mailbox so a human can take over without a deploy.
- Review recipients and message text before the agent sends anything that touches money, access, or legal language. Email can contain untrusted instructions.
MCP is the direct assistant path: search, read a thread without marking it read, send or reply, archive, and trash. It is scoped to the mailbox you approve. It does not download attachments, manage drafts or spam, or administer domains. Attachments still live in the mailbox. Webhooks expose a short-lived download URL when you need the file in your own worker.
What to refuse
- Do not let an agent send from a personal inbox.
- Do not let it share a key with password resets.
- Do not drop inbound mail because the parser failed. The mailbox is the record; the webhook is a notification.
- Do not treat “we have a sending API” as “this agent can have a conversation.”
- Do not let the agent auto-send first contact, refunds, or access changes without a review path.
- Do not mix chatty agent mail and high-volume product mail on one identity if the agent can improvise. Reputation is shared on the domain.
ArawaMail is built for company-managed domains, not one-off sandbox inboxes. Staff inboxes, API sending, inbound webhooks, and MCP sit on the same domain. The first 3,000 transactional emails each month are free. Start a workspace, or compare plans when you know which messages the agent is allowed to own.