# Give the agent its own address. Keep its work distinct.

A dedicated mailbox makes an agent’s conversations easier to identify, connect and control. Understand when a new email identity fits the job.

Decide what the agent should own before deciding how it connects.

[Create a mailbox](/sign-up) · [See plans](/pricing)

## Start with the identity, history and permissions

Does the agent need to conduct its own conversations, or act inside a mailbox a person already uses? That decision affects the address people see, the history the agent can access and the permissions your application must manage.

Robotomail provides new mailboxes for agents and application roles. A support or research workflow can have a distinct address and a key restricted to the relevant mailbox. Your application decides which data to pass to the model and which actions need approval.

An agent's own address also gives replies a stable destination when a developer changes jobs or a runtime is replaced. Keep business state outside the model and use the mailbox as the communication identity.

## Make the address follow the work

Create a mailbox for a task or role, connect it to your agent and test a conversation. Use a verified custom domain when recipients should recognize the address as part of your organization.

Choose access boundaries deliberately. Separate mailboxes can distinguish workflows, but your application still needs tenant mapping, authorization and safe handling of message content. Review [API key scopes](/docs/authentication) and [agent security](/docs/guides/agent-email-security).

Keep customer conversations, project requests and sensitive staff mail in the access boundaries you intend. Do not grant an agent an entire personal inbox merely because a single task arrived by email.

## Expand the mailbox and personal-account comparison

| Question | Dedicated Robotomail mailbox | Existing personal or employee account |
| --- | --- | --- |
| Whose address is it? | An agent or application role you provision | The existing account holder or organization |
| Which history is available? | Messages received and sent through the Robotomail mailbox | The existing account's history, subject to granted permissions |
| How does software connect? | Robotomail API keys and supported integrations | Provider-specific authorization and API access |
| How are replies handled? | They arrive at the agent mailbox | They arrive in the existing account |
| How is a new identity created? | Provision another mailbox within plan limits | Account, alias or directory provisioning is separate from reading messages |
| Who owns business decisions? | Your agent application | Your agent application |

The Gmail API exposes a Gmail mailbox through authorized scopes. Google Workspace user and alias administration is separate from the Gmail message API. Microsoft Graph similarly has its own account and application permission model. Neither access pattern should be described as universally unsuitable for automation; the relevant question is whether the workflow needs that existing identity and history.

Robotomail does not automatically import a personal mailbox or impersonate its owner. Preserve existing-inbox requirements in the project specification before choosing a new agent address.

## Expand rollout and migration considerations

### Existing conversations
Decide whether the agent needs historical messages, only new messages or a curated context summary. Moving routing or adding a new address does not automatically copy mailbox history. Keep any required export, data access and retention process explicit.

### Permission changes
Scope credentials to the task, rotate them when the runtime changes and remove access when an agent is retired. Keep human approval for actions that disclose sensitive data, create commitments or change account settings.

### Custom domains
If a staff email provider already handles the parent domain, a dedicated subdomain can give agent mail a separate inbound route. Follow the returned DNS records and verify external delivery before changing a production workflow. See [custom domains with an existing provider](/docs/guides/custom-domain#existing-email-provider).

### A useful pilot
Start with a new project address and a low-risk conversation. Measure whether the agent can interpret replies, keep the thread intact and hand off uncertain requests. Expand based on that result and the workload's actual access requirements.

## Common questions

### Can I keep using my current staff email?

Yes. A separate domain or subdomain can give agents their own mail route. Do not replace your existing domain’s MX records without planning the effect on staff mail.

### Does a new mailbox copy my old email?

No. Provisioning an address or changing DNS routing does not migrate historical messages from another account.

### Can I limit an agent to one mailbox?

Use a mailbox-scoped API key where appropriate and enforce task-specific permissions in your application. The mailbox boundary and the agent’s business permissions work together.

### What's included in the Free plan?

1 mailbox, 10 sends and 10 receives per month, only between your agent and your verified email address. No credit card, no expiry. Allowances reset on the first of each month (UTC). Upgrade to email other people or use a custom domain.

## Continue building

- [Create agent-owned mailboxes](/email-for-ai-agents)

- [Gmail API comparison](/compare/gmail-api)

- [Custom domain guide](/docs/guides/custom-domain)