One Contract, Every Agent

The most useful thing my years in payments left me is a nose for one particular wall. It is the wall you hit when two systems built by two different companies, who have never met and never will, still have to exchange something precise and get it exactly right. You cannot solve that with a clever integration, because there is no single owner to be clever. You solve it the only way it has ever been solved: everyone agrees, once, on a shared contract, and then anyone who speaks it can talk to anyone else. I watched the card networks live on that bargain for decades. So when agents started needing to hand work to other agents built by other people, I knew the shape of the answer before I read the spec.

The fleet dive decided who talks to whom. This one is how they actually talk. It assumes you have read the MCP dive and will not re-explain it; A2A is that same standardisation move, turned ninety degrees, and the whole article turns on seeing the angle.

The Wall, One Layer Up

MCP killed a wall you have already met: before it, every model provider had its own tool-calling format, so every tool needed bespoke glue for every model, and the ecosystem's cost grew with every pair. One shared contract turned N times M into N plus M. A2A is the identical economics against an identical wall, except the wall now stands between agents rather than between a model and its tools. Wire agent A to agent B by hand, then A to C, then B to C, and you are back in pairwise-integration hell, except each endpoint is a whole autonomous system built by a different team. Anyone who lived through pre-standard payments has felt this exact wall and can predict its exact ending: somebody writes down a shared contract, and the pairwise glue dies.

Vertical and Horizontal

Here is the whole distinction, and it is worth making a picture, because getting it wrong is what makes people ask whether A2A and MCP compete. They do not. They are perpendicular.

The tool dive's minted line was one contract, every tool. This is its horizontal twin: one contract, every agent. Everything below is A2A-specific, with no MCP equivalent, because talking to a peer who has their own goals, their own memory, and their own opinions is a genuinely different problem from calling a tool that just does what it is told.

How an Agent Introduces Itself

A tool is passive; you read its contract and call it. A peer agent is a stranger, and strangers have to introduce themselves. In A2A the introduction is an agent card: a small public document, typically served at a well-known address, that advertises who the agent is, what skills it offers, and how you are allowed to authenticate to it. It is the horizontal echo of MCP's runtime discovery, and it is a pattern you have shipped before under a plainer name: a service directory with an auth handshake. Peers find each other's contract at runtime instead of hard-wiring it, which is the whole reason a standard can scale to agents that did not exist when yours was written. An agent card is a stranger's business card with the authentication printed on the back: here is what I can do, and here is how you are allowed to ask.

The Unit of Work Is a Task

The other thing peers force that tools do not is time. A tool call returns. A request you hand to another agent might take a minute or an hour, might need a follow-up question halfway through, might stream partial progress. So A2A's unit of work is not a request and a reply. It is a task with a lifecycle.

The Contract You Already Know

Read the mechanics with an integration engineer's eye and there is almost nothing new under the new names. Every piece maps onto something you have built and operated before.

The Confused Deputy, Now Between Strangers

A contract standardises the conversation. It does not standardise the trust, and the trust is where the horizontal move gets genuinely harder than the vertical one. When an agent you did not build can hand work to yours, and yours can act on it, the confused-deputy problem from the tool dive crosses an organisation boundary: authority now flows between parties who answer to different bosses. The payments instinct is the right one and it carries intact. Authorization is not clearing. Nothing irreversible happens on a stranger's first message. A peer agent's request earns no authority just by arriving: something to weigh, not a command to execute, and the security discipline of the agent-security chapter is exactly the discipline a cross-vendor conversation demands. A shared protocol gets the strangers talking. Deciding what you will actually let them make you do is still your bill, and it now crosses an org line.

Bet on the Shape, Not the Version

A2A is real and moving fast. It was announced in 2025 and quickly handed to a neutral foundation so that no single vendor owns it, with the major clouds and enterprise software firms signed on, and it has already reached a stable release with the interoperability conversation now including MCP as its complementary, vertical half. That is exactly why the honest advice is to learn the shape and not the version. The field names and the exact fields will keep moving; a signed capability document, a task with a status machine, typed messages, and one shared contract so peers can find and use each other will not. Bet on that. It is the same bet payments made, and it is still paying out decades later.