AI agents talking to each other: how it works, and when one agent is better

The short version

• AI agents talk to each other by passing messages: a model writes the message and ordinary software delivers it.
• Google Research reports an 80.9% gain from multi-agent setups on parallelisable tasks with central coordination, and losses of 39% to 70% on other task types.
• A2A is a protocol for agent-to-agent communication, and its project counts more than 150 supporting organisations, but support is not the same as production use.
• A shared protocol sets the message format. It does not establish whether an answer is correct or whether an agent may act on it.
• Start with one agent, and add a second only when you can name the failure it fixes.

How do AI agents talk to each other?

AI agents talk to each other by passing messages. One agent produces text or structured data, software delivers it, and another agent reads it as part of its input. There is no shared mind. Each agent knows only what it was sent, plus whatever it can look up.

The message can be plain language, a JSON object with fixed fields, or a task record in a queue. Plain language is flexible and demos well. Structured messages are easier to validate, log and retry, which makes them the better default for anything that runs unattended.

What changes between systems is the route the message takes. Four patterns cover most of what gets built: orchestrator and workers, handoff, shared workspace, and peer to peer.

Which patterns do AI agents use to communicate?

What should a message between AI agents contain?

A message between agents should contain the goal, the constraints, the evidence so far, and what a finished result looks like. A vague handoff forces the receiving agent to guess, and it will guess confidently.

Think of it as a ticket, not a chat. 'Look into this supplier' invites a long, unfocused answer. A task with the supplier's ID, the rule to check, the documents in scope and a required output format can be verified by software before anyone reads it.

Carry identifiers and source references, not just summaries. An agent that receives only another agent's summary cannot check anything. An agent that receives the record ID can go back to the original. Each message should also carry the task ID and who started the task, so permissions and logs stay attached as the work moves.

What does it look like when AI agents negotiate with each other?

It looks like two models exchanging offers in ordinary language, each acting for a different person. Anthropic ran this as Project Deal, a one-week pilot in December 2025. It gave 69 self-selected employees in San Francisco a $100 budget each, and Claude agents bought and sold their belongings by negotiating in natural language.

It is a useful picture of the idea and a poor guide to your business. This was a vendor testing its own models on its own staff, so it does not represent how companies operate. The narrower point stands: agents can hold a back-and-forth conversation on behalf of different people. Whether you should rely on one is a separate question.

What is the A2A protocol?

A2A is a protocol that lets agents built by different teams or vendors exchange tasks in a shared format. It runs as a Linux Foundation project. In a press release dated 9 April 2026, the project said it had passed 150 supporting organisations. That is its own count. Support is not production use, and the release gives no number of deployments.

A2A is often confused with the Model Context Protocol. MCP connects an agent to tools and data. A2A connects an agent to another agent. One system can use both.

A protocol settles the format, not the judgement. It tells two agents how to exchange a task. It does not tell either one whether the other's answer is correct, whether it may act on that answer, or who is accountable when it is wrong. If all your agents live inside one application, you may not need it at all, because a function call does the same job with less to maintain.

Does letting AI agents talk to each other improve results?

It depends on the task, and the swing is large. Google Research evaluated 180 agent configurations across five architectures, four benchmarks and GPT, Gemini and Claude model families. It reports an 80.9% gain on parallelisable tasks with central coordination, and losses of 39% to 70% on other task types.

Hold the exact numbers loosely. The paper is an arXiv preprint and we have not seen a peer-reviewed version. The current version uses 260 configurations and keeps the same range of losses. The direction is the useful part: more agents is not automatically better, and on the wrong task it is clearly worse.

The mechanism is easy to follow. When subtasks are independent, such as checking twenty supplier documents against one rule, agents can work at the same time and none needs the others' detail. When each step depends on the exact result of the last, splitting the work means each agent sees part of the picture, and every handoff is a chance to drop something that mattered. That reasoning is ours, not a quoted finding.

What does it cost to have AI agents talk to each other?

It costs tokens, time and debugging effort, and all three grow with each agent you add. Every message is written by one model and read by another, and each agent needs its context restated. Anthropic's engineering team, describing its own multi-agent research system, reports from internal usage data that token use rises by a multiple. It states no sample size, and a token multiple is not a price.

Time is the cost people forget. Agents working in parallel can finish sooner, but a chain of agents waits on every link, and each link is a model call that can be slow or fail.

Debugging is the cost that arrives last. When one agent gets something wrong, you read one trace. When five agents get it wrong, you have to find which message carried the error, and you can only do that if every message was logged.

What goes wrong when AI agents talk to each other?

The usual failure is quiet: an error passes from one agent to the next and sounds more confident on the way. Nothing crashes. The final answer reads well, and it is wrong because a detail fell out three messages earlier.

This is harder to catch than a bad answer from a single agent, because the output has been through several steps that look like review.

Which failures should you design against?

• •Lost context: the receiving agent gets a summary and acts on what the summary left out.
• •False agreement: a reviewing agent approves the work because it reads well, not because it checked anything.
• •Loops: two agents pass work back and forth, spending tokens until something stops them.
• •Injected instructions: text from an email or web page reaches one agent, which passes it on, and the next agent treats it as a request.
• •Permission drift: a low-privilege agent asks a high-privilege agent to do what it could not do itself.

Who actually needs AI agents talking to each other?

Mostly large organisations with many systems run by separate teams, where no single agent can reasonably hold every tool and permission. MuleSoft's own survey of 1,050 IT leaders reports that respondents' organisations average 957 applications. That is a large-enterprise picture, not a firm of under 50 staff. It is also a vendor survey, and the page does not say who fielded it.

If you run a dozen systems, the case is weaker. One agent with well-described tools, or a plain workflow with a single model step, usually does the job with less to monitor. The useful question is not how many agents you could run. It is what a second agent does that a function call could not.

When should you use one AI agent instead of several?

Use one agent unless the work splits into parallel parts, needs separate permissions, or crosses a boundary between organisations. Those are the reasons that hold up. 'It feels more like a team' is not one of them.

Start with one agent and a fixed test set. Add a second only when you can name the failure it fixes, then run both versions on the same cases. If the two-agent version is not measurably better on your tasks, it is the same system at a higher cost.

How do you keep AI agents under control once you split the work?

1. Keep one orchestrator responsible for the outcome.
2. Pass structured messages and reject any that do not match the schema.
3. Cap the number of turns, so a loop ends on its own.
4. Log every message with the task it belongs to.
5. Check permissions against whoever started the task.
6. Put a human approval in front of anything that cannot be undone.