Give your agents an email inbox
An agent inbox needs more than an address. It needs a trusted receiving path, message history, scoped sending, and a rule that incoming mail cannot issue commands.
A shared email address sounds like a simple way to make an agent useful. Customers can write to it. The agent can read the message, do the work, and reply. The address is the easy part.
The hard part is making that loop reliable. Where does the original message live? How does the agent learn that it arrived? Can it tell a duplicate event from a new request? What happens when a reply fails? And who decides whether an email is allowed to trigger an action at all?
Build the inbox as a system
A useful agent inbox has a domain that the operator controls, a receiving service that preserves the message, a signed event when mail arrives, and an API for reading the full message. The agent needs an identity scoped to that inbox and an outbound path for replies. It also needs message IDs and an idempotency rule so retries do not send the same answer twice.
Incoming mail is evidence, not authority. A sender can ask for help, but the body of an email can also contain instructions intended to redirect the agent. Treat the subject, body, attachments, and quoted thread as untrusted input. Check the sender and the request against your application policy before the agent changes data or sends anything consequential.
Keep the human in the loop where it counts
You can let an agent classify mail, draft a reply, or look up a known record without giving it permission to close an account or disclose private information. For sensitive replies and irreversible actions, put the proposed action in a review queue with the source message and the exact destination visible to the reviewer.
Operationally, the receiver should verify the event signature against the raw request body, enqueue the work durably, and deduplicate by event ID. The agent can fetch the message it needs from the regional API. A successful webhook response means the event was accepted by your system; it is not proof that the agent completed the task or that a reply reached an inbox.
The regional boundary matters
An inbox can contain a support history, medical details, or identity documents. If the application promises a regional boundary, the receiving path, message storage, queue, event log, and outbound reply path all belong in that discussion. The agent provider and recipient mailbox are separate parts of the data path and need their own review.
Boundry's Sydney project model is designed to keep project message operations in one region and expose scoped message tools to agents. Native inbound is implemented but still deployment gated. Do not publish a receiving MX record until the selected regional deployment reports that receiving is enabled and ready.
When receiving is ready, a New Email workflow can pass selected message metadata to an HTTPS endpoint that you control. See the inbound email to HTTPS API template
The goal is a boring, inspectable loop: receive one real message, verify the event, fetch the source, decide what the agent may do, review when needed, send once, and check the delivery record. That is an inbox an application can depend on.
The receiving guide records the current availability gate and the setup steps for a ready region. Read the inbound email guide