Agent-to-agent: when AI agents talk to each other

This year we built several systems in which one LLM does not answer one question; instead, multiple agents with different jobs hand work to each other. Our experience is mixed: for certain tasks this is the only viable route, while elsewhere a simple deterministic workflow is cheaper, faster and more reliable. In this article we summarise what we learned.

Tool use and MCP: the shared language

Collaboration between agents rests on the model being able to call tools: it invokes a function with structured parameters and continues reasoning with the result. The Model Context Protocol (MCP) standardises this: tools live in a separate server with a self-describing schema, and any agent, with any model provider, reaches them the same way.

For us this effectively means that our internal systems (CRM lookup, calendar booking, call initiation, billing status) are exposed as MCP servers, and agents reach anything only through them. This has two advantages: tools can be tested and permission-controlled in one place, and the agent’s prompt contains nothing about the details of the integration.

The most important lesson in tool design: a few well-delineated tools beat many tiny ones. A “find the customer by email” tool is more reliable than a general-purpose SQL runner.

Orchestration patterns

We regularly use two patterns.

In the planner/worker setup, one agent breaks the task down into steps and hands each step to a worker running on a cheaper model with a narrower context. The worker does not see the whole conversation, only its own task and the tools it needs for it. This reduces cost and the chance of error, but the quality of the planner determines everything.

In the handoff pattern, one agent passes the conversation to another at some point, together with the full or filtered context. In voice-based customer support this is the typical case: a general reception agent recognises that the caller wants to book an appointment and hands over to the booking agent, which has narrower but more precise instructions and tools. The handoff is invisible to the caller, but for the system it is a clear state change.

In both patterns the communication is structured: agents do not “chat” in free text but exchange schema-validated messages. Free-text agent-to-agent dialogue looks impressive in demos, but in practice it is long, expensive and hard to debug.

Guardrails and human-in-the-loop

More agents mean more ways to fail, and failures propagate. So the lines of defence are not in the prompt but in the code:

• every tool call goes through a permission check based on the agent’s identity and the tenant;
• write operations (booking, sending email, changing status) are on an explicit allowlist, and all other tools are read-only;
• input and output are schema-validated; if the agent returns a bad format, we retry once and then report an error;
• step-count and cost limits per agent and per run, so that an agent going in circles cannot run forever.

Some decisions we never allow to happen automatically: refunds, changing contractual terms, or closing an escalated complaint. For those the agent prepares a proposal and a human approves it, from a single line, with one click. Human-in-the-loop is not a weakness of the system but a designed part of it: one well-defined output of the agent’s work is “ask a human”.

Observability: tracing across agents

Debugging a multi-agent run is hopeless without tracing. Every run is a single trace, within which each agent step, model call and tool call is a span, with input, output, token count and duration. Trace identifiers carry across handoffs, so the whole path is visible in one place.

This is also what gives cost and latency analysis. With multiple agents, response times add up: if a planner step takes 2 seconds and three workers run one after another, the caller waits 8 to 10 seconds. In a voice-based system that is unacceptable, so there the workers run in parallel where possible, and the caller gets filler feedback in the meantime. Cost easily multiplies too, because every agent sends its own context again and again; prompt caching and narrow-context workers matter a lot here.

When it makes sense, and when it does not

Multiple agents are justified when the steps of the task are not known in advance, when the subtasks require different knowledge and toolsets, and when a wrong step is reversible or can be tied to human approval. A typical example is a complex support case where identification, handling and follow-up touch different systems.

They are not justified when the order of steps is known and fixed. A “write a summary after the call, send it by email, update the CRM” process is a plain workflow with an LLM in exactly one step (the summary). In that case the agent-based approach only adds uncertainty, cost and latency.

Our rule is simple: first describe the process as a deterministic workflow. Where that does not work, because the decision really is context-dependent, an agent comes in. Where one agent’s context grows too large, we split it into several. Starting from agents and working backwards almost always produces an over-complicated system.