Running several email agents in one workspace

The second agent is where the design decisions you postponed arrive at once. Do they share an address book. Can the sales agent read the support inbox. What happens when both answer the same customer on the same day. Who owns the domain reputation they are both spending.

26 July 2026 · 5 min read

One identity per agent, always#

Start from the rule that makes everything else tractable: each agent gets its own identity, its own address, and its own key. Scope, attribution, and revocation all attach to the identity, so the blast radius of anything going wrong is one agent, and turning one off is one key rather than a rotation.

The alternative, several agents sharing a key, collapses the audit trail exactly when you need it and makes "which agent sent that" unanswerable. Key handling, rotation, and what to do when one leaks are in keys, scope, and what to do the day one leaks. The full comparison against shared mailboxes and provider APIs is in agent inbox or shared mailbox.

Addresses people can read#

Name agents by function, not by product. support@, billing@, recruiting@, scheduling@, all on one agents subdomain. Recipients then know what a message is about before they open it, and your own team can route by address without a lookup table.

Two conventions worth adopting early. Keep every agent on the same sending subdomain so reputation accrues in one place, warmed once rather than five times. And keep the addresses stable, because they end up in signatures, calendar invites, and customers' address books, and changing one is a small migration.

What to share, and what not to#

The useful default: share knowledge, isolate mail.

Contacts are worth sharing. When the billing agent learns that an account's AP contact changed, the support agent should benefit. Contacts are a workspace resource, and facts recorded with remember_about_contact accumulate across agents rather than per silo. This is the main reason a workspace beats four unrelated accounts.

Notes are worth sharing selectively. Policy, escalation limits, product facts: shared. Anything sensitive to one function: not.

Inboxes should stay isolated. Other identities are invisible unless access is granted, and that default is correct. A support agent with read access to the recruiting inbox is a data protection incident waiting for a bad prompt.

Vault secrets are per grant. Values are encrypted with a key you hold, and get_secret takes that key from your own environment at call time. Grant per agent, never broadly. See contacts, notes, and vault.

Handoffs between agents#

Sooner or later a customer asks the support agent a billing question. Three ways to handle it, in increasing order of how much you should like them.

Forward the thread. Simple and honest. forward_email moves the conversation to the other agent's address with the context attached, and the customer sees a normal handover. Best when the second agent will own the rest of the conversation.

Answer with a note. The support agent records what is needed on the contact and tells the customer a colleague will follow up. The billing agent picks it up on its next run. Best when the answer is not urgent.

Escalate to a human. Always available, and the right answer whenever the handoff itself is the confusing part.

What to avoid is agents emailing each other in a loop. Two models corresponding through an inbox is expensive, slow, and produces threads nobody can read. If two agents need to exchange structured information, do it in your own code or through shared contacts and notes, not through the mail path.

Preventing the double-answer#

The failure that shows up at three agents is two of them replying to the same customer within an hour, having each decided the message was theirs.

• Route inbound by address, not by content. One address, one owner. Content-based routing between agents guesses, and guesses collide.
• Have each agent check for recent threads with the sender's domain before starting a new conversation. search_inbox makes this one call, and it also catches the case where a human is mid-conversation.
• Give one agent the tie-break. Where overlap is genuinely possible, make one of them the default owner and the others explicit referrers.

Reputation is shared, so behaviour is everyone's problem#

All these agents send from one subdomain, which means one reputation. A single badly-behaved outreach agent can degrade delivery for the support agent that has been carefully warming the domain for a month.

Two things follow. Keep cold outreach on a tight quota and review it, per keeping an autonomous agent from becoming a spam problem. And if you genuinely need higher-risk outbound, give it its own subdomain and warm it separately, using the warmup plan, rather than letting it borrow trust the others built.

Operating four agents without four dashboards#

The practical difference between one agent and four is that nobody can read every thread any more. What replaces that:

1. One weekly pass over each agent's sent mail, fifteen threads, looking for drift.
2. Per-agent metrics rather than a workspace aggregate, since one agent regressing is invisible in a total. The set worth tracking is in evaluating an email agent.
3. Alerts on the shared risks: first sends to new domains, bounce and complaint movement, and any agent suddenly sending more than usual.
4. A named owner per agent. An agent nobody owns is an agent nobody reads, and it will drift.

Questions#

Can several AI agents share one email workspace?

Yes, and they should: contacts and notes accumulate across them while inboxes stay isolated. Each agent needs its own identity and key so scope, attribution, and revocation stay per agent.

Should agents share an inbox?

No. Other identities are invisible unless you grant access, and that default is right. Share the address book, not the mail.

How should agents hand a conversation to each other?

By forwarding the thread to the other agent's address, or by recording the need on the contact and letting the other agent pick it up. Avoid agents emailing each other conversationally.

What stops two agents answering the same customer?

Routing inbound by address rather than by content, checking for recent threads with the sender before starting a new conversation, and naming a default owner where overlap is genuinely possible.

Do all agents have to send from the same domain?

They do not, but sharing one agents subdomain means warming it once and keeping reputation in one place. Give higher-risk outbound its own subdomain rather than letting it spend the trust the others built.

How many agents is too many?

The limit is operational, not technical: each agent needs an owner who reads its mail weekly. When that stops happening, you have more agents than you can run.