Multi-agent output governance: the caller should hear one agent

VOICE HAS NO UNDO · PART 2 OF 6

Five deployments, five ways the machinery leaked into the conversation

A member of a specialty pharmacy has just verified their identity to check on an order. Then, the way people do: "Actually, can I refill my prescription instead?"

The agent answers by reading out its own error message: "Handoff to the order-status specialist blocked: condition not met. Collect the required data first, then retry."

Nothing in that sentence was meant for a caller. It was one part of the system talking to another, and it came out of the speaker.

We have seen the same thing across very different deployments. At one of APAC’s largest private banks, a caller heard the model's private reasoning right after the greeting: "…I have to respond as the services supervisor. We already captured the mobile number…" At another bank in the middle east, a raw function call appeared in the chat window, and then the agent promised to forward a request it never forwarded. A hotel guest asking to cancel heard the cancellation policy read out twice. And a driver booking a car service with a Dubai-based group asked, halfway through, for roadside assistance from the group's insurance business. The request disappeared between two supervisors, and the caller would have had to repeat it.

Five deployments, one failure: the customer heard the machinery.

Why multi-agent systems leak

A single agent has one voice. A multi-agent system has many: a router that decides who should answer, specialists that own each task, flows that collect details, and tools that act. Each one can produce text, and in most stacks each has its own idea of what is fit to say.

In chat that arrangement mostly survives. A screen can hide control messages, and a duplicate reply disappears when the page reloads. On a call, anything that reaches the speaker is spoken, and nothing spoken can be taken back.

Three things make it worse:

• One stream carries everything. Model text, tool-call syntax and internal diagnostics travel together. Streaming speech starts on the first words, before anyone knows whether the rest is a sentence or a function call.
• Handoffs happen mid-turn. When a router passes the caller to a specialist, no new message arrives from the caller. The system has to decide on its own what the caller hears next.
• Checks multiply. At the Indian bank, seven separate output points each had their own filter. The reasoning leak came through the one that didn't know to look for it.

One rule, one final answer, one thread of context

We stopped asking each component to police itself. Three rules now hold across every agent, channel and model.

Only conversation reaches the customer. Every point where text can leave the system applies the same rule. Internal routing messages fail closed: diagnostics go to the trace, and the caller hears an authored message, once, or a safe fallback. A stream guard holds back tool-call text even when it arrives split across chunks. For model reasoning, the gate holds output only from the first suspicious signal. A clean sentence is released at full speed; a leaking one is repaired, cut back to the clean text before the leak, or replaced with a fallback.

Each turn has one final answer. A delivered response is marked as delivered. When a specialist finishes its flow and hands back, its one visible response becomes the turn's final answer instead of being generated a second time. Interim and final output are tracked separately, so the hotel guest hears the policy once.

Context survives every hop. When a request belongs to another agent, the caller's words travel with it, unchanged, through every return hop. We validated this across three levels of agents and two return hops. Intent is worked out from the current turn, not the previous one, so a change of subject doesn't trip a stale condition. When the request needs a phone transfer, the destination comes from the agent's compiled configuration, never from text the model produced.

What we got wrong first

Our first instinct was to add a filter wherever a leak appeared. Each fix worked, and each was local, so the next leak came through an output point nobody had filtered yet. The lesson was structural. Output governance holds only when one rule decides "may the customer see this?", everywhere. We have moved from separate filters to one shared rule, and the end state is a single authority that every word passes through.

The second lesson was about latency. Holding every sentence until it is checked would make a voice agent feel slow. So the gate holds text only from the first suspicious signal, and everything before it flows at normal speed. That is a trade-off, not a free lunch: a new kind of leak needs a new signal. Every held response is recorded in the trace, which is how we find the next one.

The principle

However many agents collaborate behind the scenes, the caller hears one agent. Routing, reasoning and retries are machinery. They belong in the trace, not in the conversation.

In chat, a leak can at least be deleted. On a call it can't, which is why voice is where this discipline gets tested. Across its AI agents, the Middle Eastern bank in this essay now handles more than 500,000 conversations a month, and 8 in 10 are resolved without a human agent.

Four turns to test before you launch

Try these on any multi-agent system, ours included:

1. Verify your identity, then change the subject. Are you asked to verify again, or read an error?
2. Halfway through one task, ask for something another agent owns. Do you have to repeat yourself?
3. Finish a task a specialist handled. Do you hear the confirmation once?
4. Upgrade the model. Does anything it used to keep to itself now reach the caller?

‍

Want to build your own usecase with production traces? Ask for Proof