How A2A works
Most protocols connect a model to a tool. A2A, short for agent to agent, addresses a different problem: how one agent talks to another agent that it did not build, does not control and cannot see inside.
The pieces are straightforward. Each agent publishes a description of itself — an agent card — saying what it can do, where to reach it and how to authenticate. Another agent reads that card, sends a task, and the two exchange messages until the task is finished or refused. Work that takes time can report progress rather than making the caller wait. Crucially, neither side has to expose its prompts, its model or its internal steps; the conversation happens at the level of a task and a result, which is what makes the arrangement usable between separate companies.
Why A2A matters
The interesting case is across an organisational boundary. If a supplier, a booking system or an agency runs an agent, a standard way of asking it to do something is more durable than a bespoke integration written for that one relationship.
It is worth being honest about the stage this is at. Agent-to-agent standards are young, adoption is still forming, and most businesses have no second agent to talk to. If you are being sold A2A as a reason to buy something today, the useful question is which specific agent you would connect to and what it would do that a plain integration would not. For nearly everyone, that question has no good answer yet, and the sensible position is to understand the term without spending on it.
Where A2A goes wrong
The first mistake is confusing it with MCP. MCP connects a model to tools and data; A2A connects agents to one another. They solve different problems and a setup may use both, so a vendor claiming one replaces the other is worth questioning.
The second is trust. An outside agent is an outside party. Anything it returns is data to be checked, not an instruction to be followed, and anything it does on your behalf needs the same scrutiny as work from a supplier you have never met.
The third is accountability. When two agents from different companies exchange work and the outcome is wrong, the trail sits in two places. Without agreed logging on both sides, nobody can say what was asked or what came back.
What to do about it
Learn the term, watch where it settles, and build nothing on it until you have a named counterpart worth connecting to. Get your own house in order first: a single agent that works reliably inside your workflow automation is worth more than a standard connecting two agents you have not built.
If a genuine case does appear, treat the other agent as an untrusted supplier. Scope what it may request, validate everything it returns, keep your own record of every exchange, and put a person at the point where its work becomes a commitment to a customer.