When an agent and a person are on the same thread

Most writing about agent email imagines a clean two-party conversation. Real threads are not that. There is a colleague in cc, an account manager who joined at message four, a customer who added their finance person, and now an agent deciding whether to reply to all of them.

1 August 2026 · 5 min read

Getting this wrong is not a correctness failure, it is a social one, and social failures are the ones people remember.

Reply-all is the default, and it is the right one#

reply_all keeps the audience: the original sender goes in To, everyone else stays in Cc, and the agent's own address drops out. That is what a competent person does, and it is what keeps a thread readable for the people watching.

The temptation to reply only to the sender comes from wanting to reduce noise. It does the opposite: the colleague in cc now sees half a conversation and, eventually, asks a question that was already answered where they could not see it.

Two exceptions worth encoding. Drop recipients who explicitly ask to be removed. And when a thread is genuinely splitting into two topics, start a new conversation with the right subject and the right people rather than letting one thread carry both, per how email threading works.

Who speaks when a human joins#

The rule that prevents nearly all the awkwardness: once a person replies on a thread, the agent stops speaking unless it is addressed.

Not pauses, stops. A thread where an agent and a colleague both answer a customer reads as chaotic and occasionally contradicts itself in public. When a human takes over, the agent's remaining job is to keep its record straight and stay out of the way.

Coming back needs to be explicit: the person addresses the agent by name or by address, or hands it back through your own tooling. "Assistant, can you send them the invoice" is an invitation; a colleague answering a different question is not.

That last row matters more than it looks, and it leads to the rule people forget.

Adding someone mid-thread exposes the history#

When a customer copies in their colleague at message six, that colleague can now read messages one to five. When your agent copies in a specialist, the same is true in the other direction.

So an agent should never add a recipient to an existing thread on its own initiative. If someone else needs to be involved, the correct move is a forward with a fresh summary, which puts a deliberate boundary around what is shared. forward_email in wrapped mode preserves the original for the recipient who needs it, without dragging them into a live conversation they have no context for.

Internal threads have their own trap#

Agents on internal mail meet a specific hazard: other automation. A ticketing system that copies an address on every update, a notification bot, another agent. Two automated participants on one thread will correspond politely forever if nothing stops them.

Three defences, all cheap. Block your own agent addresses in the mail rules, per deciding what reaches your agent. Cap turns per thread and alert past the cap. And recognise auto-submitted headers so an out-of-office does not read as an answer worth replying to.

Sign so the thread is legible#

On a thread with several people, everyone needs to know who is speaking without checking headers. That means the agent's name reads as an assistant, its address sits on an agents subdomain, and it says plainly that it is one when asked.

This is not only courtesy. On a shared thread the ambiguity is operational: a colleague deciding whether to jump in needs to know at a glance whether the last reply came from a person, and getting that wrong wastes their time or duplicates their work.

A short rule set#

1. Reply-all by default; never quietly narrow the audience.
2. Stop when a human replies; return only when addressed.
3. Never add recipients to a live thread; forward instead.
4. Never remove someone unless they asked.
5. Keep the subject stable; split topics into new threads.
6. Block other agent addresses and cap turns per thread.
7. Be obviously an assistant, in name and in signature.

None of these need a model to enforce. Most are one line in the prompt and a matching constraint in tooling, which is the division argued throughout the system prompt for an email agent.

Questions#

Should an AI agent reply to all?

Yes, by default. reply_all keeps the sender in To and the others in Cc, which is what a competent colleague does and what keeps a shared thread readable.

What happens when a human replies on the thread?

The agent stops for that thread and returns only when addressed directly. An agent and a person both answering reads as chaotic and can contradict itself publicly.

Can the agent add someone to a thread?

It should not. Adding a recipient exposes the entire history to them. Forward with a fresh summary instead, which puts a deliberate boundary around what is shared.

How do I stop two agents emailing each other forever?

Block your own agent addresses in the mail rules, cap turns per thread, and alert when a thread passes the cap. Also recognise auto-submitted headers so an autoresponder is not treated as a reply.

Should the agent identify itself on a shared thread?

Yes. On a multi-party thread, colleagues need to know at a glance whether the last message came from a person, or they duplicate work.

What if someone asks to be taken off?

Remove them and keep replying to the rest. It is the one case where narrowing the audience is correct.