A2A explained: when AI agents need to talk to each other

Most businesses do not need it yet. A2A standardises how agents built by different teams or vendors delegate work to each other, which only starts to matter once you have more than one agent and the other one is not yours to change.

JarvisBitz

MCP gave agents a standard way to reach your tools. A2A, agent to agent, is the other half of the same idea: a standard way for one agent to hand work to another agent and get a result back. Discovery, delegation, progress updates, and authentication between two autonomous systems, in a defined shape rather than a bespoke one.

It is a reasonable piece of engineering and it will matter. It is also the part of the stack most oversold right now, because the interesting problems in multi agent systems are not the ones a protocol can solve. Worth understanding what it covers before you plan an architecture around it.

What A2A actually standardises

Four things, and it is useful to be precise about them because the marketing tends to imply a fifth that does not exist.

• Discovery. An agent publishes a description of what it can do, so another agent can find it and understand its capabilities without a human wiring them together.
• Delegation. One agent sends another a task rather than a single function call, which matters because a task can take minutes and involve judgement.
• Progress. Long running work streams updates back, so the calling agent is not left guessing between submit and result.
• Identity. Agents authenticate to each other, so the receiving side knows who is asking and can decide what it will accept.

What it does not standardise is whether the delegation was a good idea, whether the answer that came back is correct, or who is responsible when it is not. Those stay your problem, and they are the hard part.

The distinction from MCP that actually matters

Both are connection standards, so they get discussed together and often conflated. The difference is not protocol detail, it is what sits on the far end.

A tool that fails tells you it failed. An agent that fails may return a fluent, plausible answer to a question you did not ask. Every design decision downstream follows from that, which is why treating A2A as "MCP for agents" leads people to under engineer the parts that bite.

When you actually need it

There is a short test, and most teams fail it, which is fine and worth knowing early.

• Do you have more than one agent? If you have one, this is not your problem yet. Make that one reliable first.
• Are they built by different teams or vendors? If one team owns all of them, a shared orchestrator and ordinary function calls are simpler, faster, easier to debug, and easier to secure.
• Does the work genuinely need delegating? A lot of what gets described as agent collaboration is a sequence of steps one agent could run itself, split up because the diagram looked better that way.

Do you need several agents, or one with better tools?

Worth separating from the protocol question, because teams reach for A2A having already assumed the answer. Most workflows that look like they need a multi agent rebuild need a better toolkit instead. Splitting one capable agent into three specialists adds coordination, latency and cost, and the split is usually justified on a diagram rather than a measurement.

There is a nice illustration of this in a January 2026 study comparing multi agent and single agent systems on essay grading. The authors report that "few-shot calibration emerges as the dominant factor in system performance, providing just two examples per score level improves QWK by approximately 26% for both architectures". The largest available gain came from showing either system what good looks like, not from restructuring it. Their conclusion was that the architectures suit different jobs, with the multi agent setup better at flagging weak work and the single agent more cost effective for general assessment, which is a narrower claim than multi agent being better.

The signals that genuinely justify more than one agent are specific: real parallelism where subtasks do not depend on each other, distinct model configurations per subtask, or a compliance requirement that certain data never reaches the same context. Wanting the diagram to look sophisticated is not on the list. If one agent with clearer instructions and better tools has not been tried, that is the cheaper experiment, and it is usually the one that moves the number.

What it does not solve

Accountability

When your agent delegates a refund decision to a partner agent and the decision is wrong, the protocol tells you the message was delivered. It does not tell you who owns the outcome. That has to be settled in a contract and enforced in your own logs, because the customer will hold you responsible regardless of which system made the call.

Runaway delegation

Agents that can call agents can call agents. Without explicit depth limits and budgets, a task that looks small at the top can fan out into a great deal of work, and the cost shows up on a bill nobody was watching. Cap delegation depth, cap spend per task, and make both visible before you need them rather than after.

Latency, which compounds

Each hop adds the receiving agent's full reasoning time, not just network transit. Three agents in a chain, each taking a few seconds to think, produces a wait that is fine in a batch job and unusable in a chat window. Decide which one you are building before you distribute the work.

Whether the other agent is any good

The same caution as MCP applies here, more sharply. A standard connection to a weak agent gives you a standard way to receive weak answers. Evaluate the agent you are delegating to on your own tasks, with your own data, before you depend on it.

The security question, again

The lesson from tool results being untrusted input carries over, and gets worse.

• Another agent's output is untrusted input. It is not a return value from your own code. It is text produced by a model you do not control, which may itself have been influenced by content it read. Treat it as data to evaluate, never as instructions to follow.
• Delegation widens the blast radius. Whatever your agent can do, it can now be talked into doing by something a partner agent said. Permissions have to be scoped at your boundary, because you cannot audit theirs.
• Identity is not trust. Authentication proves which agent is calling. It says nothing about whether that agent is behaving correctly today, or whether its own inputs were compromised this morning.

Worth separating one more time, because these three questions are routinely collapsed into one. Whether you need something that acts is capability. How many of them there are, and whether they talk, is topology, which is this page. Whether your code or the model decides the next step is control flow, and that is settled in most agents should be workflows.

How to start, if you should

The sequence that works is unglamorous. Build one agent that does a real job reliably, with guardrails and a human approval step wherever it changes something that matters. Add a second when there is a second job, and let a plain orchestrator sequence them while you own both. Reach for A2A at the point where the agent you need is genuinely someone else's, because that is the boundary the protocol exists to cross.

If you are being sold a multi agent architecture before you have one agent in production, the architecture is not the thing being sold.

Related reading

Prompt injection: why filters fail and what actually works

Not with filters. A model cannot tell where an instruction came from, so any defence that tries to spot a malicious one will eventually be talked past. What holds is constraining what the agent is able to do after it reads untrusted content, which is an architecture decision rather than a prompt.

Where human approval actually belongs in an AI agent

In front of actions that cannot be undone, or that reach further than a blast radius you have deliberately chosen. Gating everything is close to gating nothing, because a control that fires constantly stops being read. The design work is deciding which actions qualify, then shrinking permissions so the list stays short.

How to test an AI agent before it touches production

Run it against real inputs with its writes going nowhere, compare what it proposed against what actually happened, then give it a small share of live traffic with spend caps and a fast stop. Stages without written promotion criteria are decoration.