How to give an AI agent its first mailbox

An agent that can email customers needs more than permission to call a send API. It needs an identity, a bounded credential, a safe first test, and an explicit definition of what “sent” means.

The smallest useful setup is one mailbox and one key scoped to that mailbox. This keeps the agent out of a human inbox and avoids giving it account-wide access merely to answer support mail.

Start with a job, not an inbox

Name the mailbox after the workflow: support-bot, invoice-intake, or order-updates is more useful than agent-1. A workflow-specific identity makes it easier to set recipient rules, inspect activity, and replace the agent later without changing the public address.

Create an agent key for only that mailbox. Store it in the agent runtime's secret store, never in a prompt, source file, or transcript. The agent should receive the mailbox name as configuration rather than choosing any identity in the account.

Prove the connection without emailing anyone

Do not make recipient confirmation the first proof that the integration works. Send through the normal scanning and delivery path to ReplyLayer's first-party simulator:

rly send \
  --from support-bot \
  --to [email protected] \
  --subject "First agent mailbox test" \
  --body "Checking the governed send path."

The simulator address does not deliver to a real inbox, and a Sandbox account can use it without verifying a recipient. The command response still matters: inspect the returned status and email_effect instead of treating a successful HTTP request as proof of delivery.

For automated jobs, add an idempotency key. If the request times out, repeat the same request with the same key. That lets the service replay a known result instead of creating a second email because the agent was uncertain.

Add the real-world boundary second

Once the simulator path works, decide who the agent may contact. Sandbox requires each real recipient to confirm their address. Production workflows can also use a mailbox recipient allowlist when the agent should only contact a known set of people or domains.

This order separates two questions that are often accidentally tangled together:

1. Can the agent authenticate, select the right mailbox, and understand a send outcome?
2. Is this real recipient allowed for this workflow?

When those checks fail independently, the remedy is clear. A credential problem should not look like a recipient problem, and a recipient-policy denial should never encourage the agent to rotate keys or retry blindly.

Teach the agent the stop conditions

The agent should branch on the effect of the email operation:

• sent: the provider accepted the message; continue the workflow and watch later delivery events when needed.
• held_for_review: tell the operator it is waiting for review and do not retry.
• blocked: report the reason and stop.
• an uncertain infrastructure outcome: keep the same idempotency key and follow the returned retry guidance.

That small outcome contract prevents the two costliest early mistakes: duplicate replies and an agent that rewrites a held message until it slips through.

Start a free 30-day Sandbox or follow the full quickstart.