Agent-to-Agent Protocols: What They Solve and What They Do Not

MCP standardised how an agent reaches tools and data. A second category of protocol has followed, addressing a different question: how one autonomous agent discovers, delegates to and negotiates with another that it did not build and cannot inspect.

The distinction matters because the two are frequently conflated. Connecting to a tool is a call with a known contract. Delegating to another agent is handing work to something that will make its own decisions, take an unknown amount of time, and possibly come back asking for clarification.

The problem they are actually solving

Within one organisation, agents talking to each other is a solved problem. You control both sides, so you use function calls, a queue, or an internal HTTP API. Nothing needs standardising because there is no interoperability requirement.

The problem appears at organisational boundaries. Your procurement agent needs to negotiate with a supplier's sales agent. Neither side controls the other, neither wants to publish an SDK, and neither can assume a shared framework. That is a genuine N-by-M problem of the same shape MCP addressed for tools.

It also appears at framework boundaries inside larger companies, where one team built on one stack and another team built on a different one, and neither is going to rewrite. The protocol becomes the lowest-cost integration point.

What these protocols standardise

The designs vary, but the components converge on a recognisable set, and it is worth knowing them independently of any particular specification.

Discovery. A machine-readable description of what an agent can do, where to reach it, and how to authenticate. This is the equivalent of a service catalogue entry, and it is what lets one agent find another without a human wiring them together.

Task lifecycle. Agent work is long-running and asynchronous in a way that ordinary requests are not. So these protocols model a task as an object with states — submitted, working, needs input, completed, failed — that both sides can poll or subscribe to, rather than as a single request-response.

Structured messages and artefacts. A common envelope for the content passed back and forth, including intermediate outputs, so a delegating agent can inspect partial progress rather than waiting for a final answer.

Clarification. The state that distinguishes this from tool calling entirely. A remote agent can come back and ask a question mid-task, which no function call ever does. Your side needs a defined way to answer or to escalate to a human.

How this differs from MCP

MCP is vertical: an agent reaching downward to capabilities it uses. Agent protocols are horizontal: peers exchanging work. They compose rather than compete, and a real system will often run both — MCP for the tools each agent uses internally, an agent protocol for the boundary between them.

The contract differs in kind, not just in shape. A tool has a fixed signature and deterministic-ish semantics; you know what create_ticket does. A remote agent has a capability description and its own judgement, so the same request can produce different work on different days.

That means you cannot test a remote agent the way you test a tool. You need behavioural evaluation against your own cases, run repeatedly, because the counterparty can change without telling you. Evaluating agent reliability applies directly, and the counterparty is now a dependency whose reliability you do not control.

The reliability arithmetic is unforgiving

Chaining agents multiplies failure probability. Three delegations at ninety percent each land near seventy-three percent end to end, and unlike a tool chain there is no assertion you can run on the intermediate steps to catch the drift early.

Ambiguity compounds too. A task description passed between agents is natural language on both ends, so each hop is a re-interpretation. By the third hop the work being done can be recognisably different from what was asked, with every individual step looking reasonable in isolation.

This is the same argument against enthusiastic multi-agent architectures generally, and it applies with more force across an organisational boundary where you cannot read the other side's traces. Multi-agent systems: when they help and when they hurt covers the internal case.

Trust across the boundary

Everything in the prompt injection discussion applies, with the added complication that the untrusted content is now produced by something actively pursuing a goal rather than by a static document.

Treat everything a remote agent returns as untrusted input, including its status messages and its clarifying questions. A returned artefact should never be executed, and a returned instruction should never be promoted into your system prompt. Prompt injection and agent security covers why the model cannot reliably tell the difference.

Authorisation needs to be explicit about scope and delegation depth. If your agent delegates to a remote agent that delegates onward, what did you actually authorise, and can you see the chain? Cap delegation depth, require the chain to be reported, and refuse work whose provenance you cannot reconstruct.

Log the full exchange. When a delegated task produces a wrong result, the message history is the only evidence you have, and you will not be able to reproduce it from the other side. Agent observability and tracing covers what to capture.

Whether you need one yet

If both agents are yours, you almost certainly do not. A function call, a queue message or an internal endpoint is simpler, faster, testable and debuggable, and adopting a protocol for a boundary you control buys interoperability you will never use.

If you are integrating with an external party that already speaks a protocol, use it — that is exactly the case it exists for. If you are the external party and you want to be integrable, publishing an agent interface is a reasonable way to be found.

The middle case, several internal teams on incompatible stacks, is a real fit but worth a second look. Sometimes the honest answer is that one team should expose an ordinary API and the other should call it, and the agent framing is adding autonomy nobody asked for. When not to use an agent is the relevant sanity check.

If you do adopt one

Start with a single delegation across one boundary, with a human reviewing results until you have data. Define what a completed task means in terms you can check without reading prose. Cap delegation depth and cost per task explicitly, since a remote agent will happily spend your budget. Keep a frozen set of test tasks and rerun them on a schedule, because the counterparty changes underneath you.

And keep the fallback path warm. The most common outcome of an early agent-to-agent integration is discovering that a plain API call would have done the job, and you want that retreat to be cheap.