# A2A Is the New API: What Agent-to-Agent Protocols Actually Solve > Source: > Published: 2026-07-15 00:01:03+00:00 For thirty years, the API was the contract. One system exposed a fixed set of endpoints, another system called them in a known order, and both sides agreed on the shape of the data flowing between them. That contract worked because both sides were, fundamentally, static. Your billing service didn’t wake up one morning and decide to query the inventory service in a different sequence. It called what it was told to call, when it was told to call it. Agents broke that assumption. An autonomous agent doesn’t consume an API the way a script does — it reasons about which capability it needs, discovers whether something can provide it, and adapts its call pattern based on intermediate results. The traditional API was never built to be discovered, negotiated with, or reasoned about. It was built to be read in documentation and hard-coded. That gap is what the Agent2Agent protocol, better known as A2A, was built to close. And it’s worth being precise about what it actually does, because most of the coverage since its release has either oversold it as a universal fix for multi-agent chaos or dismissed it as another vendor-driven standards effort destined for the interoperability graveyard. Neither framing holds up under scrutiny. Multi-agent coordination is not a new research area. Distributed AI researchers were formalizing agent communication languages in the late 1990s, well before “agent” meant anything close to what it means today. FIPA’s Agent Communication Language tried to standardize how autonomous software entities could exchange performatives — structured speech acts like “inform” or “request” — across heterogeneous systems. It had real academic rigor behind it and essentially no commercial traction, because the agents of that era weren’t capable enough to make the coordination problem urgent. What changed is not the theory. What changed is that large language models turned “agent” from a research toy into a production workload. Once organizations started deploying dozens of specialized agents — a procurement agent here, a customer support agent there, a fraud-detection agent somewhere else — they ran into the exact coordination problem FIPA tried to solve twenty-five years earlier, except now with actual budget behind fixing it and actual production incidents forcing the question. The immediate, unglamorous version of the problem looked like this: every vendor’s agent framework spoke its own internal dialect. An agent built on one framework couldn’t hand off a task to an agent built on another without a custom integration written by hand, for that specific pair, maintained indefinitely. Multiply that across a portfolio of agents from different teams, different vendors, and different frameworks, and you get an integration surface that grows quadratically with the number of agents you deploy. Nobody’s architecture diagram survives that math. A2A was developed by Google and released in 2025, then handed over to the Linux Foundation later that year to be governed as a vendor-neutral open standard rather than a single company’s roadmap. That transfer matters more than it sounds — a protocol meant to prevent lock-in loses its credibility fast if the company that invented it also controls its evolution. Structurally, A2A solves three specific problems, and it’s worth separating them because they get conflated constantly: **Discovery.** Every A2A-compliant agent publishes what’s called an Agent Card — a structured, machine-readable description of what the agent can do, what inputs it expects, what authentication it requires, and how to reach it. Instead of a human reading documentation and wiring up an integration, a calling agent can fetch another agent’s card at runtime and determine, programmatically, whether that agent is capable of handling the task at hand. **Task lifecycle management.** A2A defines a standard task state machine — submitted, working, input-required, completed, failed — so that a calling agent doesn’t just fire a request and hope. It gets structured status updates, can supply additional input mid-task if the receiving agent needs clarification, and can track long-running work without polling blindly or building custom webhook logic for every counterpart. **Transport-level interoperability.** Under the hood, A2A rides on standard web infrastructure — HTTP, JSON-RPC, server-sent events for streaming — rather than inventing a proprietary wire format. That was a deliberate choice, and it’s the right one. It means an A2A integration doesn’t require both parties to adopt a new networking stack, only a shared vocabulary for describing capabilities and task state on top of infrastructure they already run. None of that is exotic. Which is precisely the point. A2A isn’t solving agent coordination through some breakthrough in reasoning or planning — it’s solving it the way every durable infrastructure standard solves its problem: by being boring, well-specified, and transport-agnostic enough that adoption doesn’t require anyone to rip out what they already have. The most common confusion in enterprise architecture conversations right now is treating A2A and the Model Context Protocol as competitors. They’re not. They operate at different layers, and conflating them leads teams to build the wrong thing. MCP standardizes how a single agent connects to its tools, data sources, and functions — it’s the interface between one agent and the resources it needs to do its job. A2A standardizes how that agent, once equipped, talks to other agents outside its own boundary. A useful mental model: MCP is how an agent gets equipped. A2A is how an equipped agent goes to work with other equipped agents. Consider a claims-processing agent inside an insurance company. It uses MCP to query internal policy databases, pull document records, and call a fraud-scoring function — all tools within its own operational boundary. When that agent needs to verify something with an external reinsurer’s system, or hand a flagged case to a specialized investigation agent built by a different team on a different stack, it does that over A2A. One protocol governs the agent’s relationship with its own toolkit. The other governs its relationship with the outside world. Enterprises that build agent architectures without this distinction tend to end up with agents that either can’t reach their own tools cleanly or can’t collaborate with anyone else’s agents at all. Standards efforts in enterprise software have a bad track record of staying on paper. A2A is a partial exception, and it’s worth saying why, because skepticism toward “the next universal protocol” is usually earned. Within its first year under Linux Foundation governance, A2A picked up support from more than 150 organizations and landed integration across all three major cloud platforms rather than staying confined to its originating vendor’s ecosystem. Production deployments have shown up in supply chain coordination, financial services, insurance claims workflows, and IT operations — domains where the coordination problem is expensive enough that companies were already paying engineers to solve it badly with point-to-point integrations before a standard existed. That’s the tell that separates a protocol with real legs from one that’s a press release: adoption showing up in production verticals with actual operational stakes, not just pilot demos on a conference stage. It doesn’t guarantee A2A wins the next decade. But it’s a meaningfully different starting position than FIPA ACL ever had, because the economic pressure to solve agent coordination is now large enough to fund the unglamorous integration work that adoption actually requires. This is the part that gets dropped from the enthusiastic coverage, and it’s the part that matters most for anyone actually building on this. A2A standardizes the mechanics of discovery and task exchange. It does not standardize trust. Knowing that another agent claims certain capabilities via its Agent Card is not the same as knowing that agent will behave safely, won’t hallucinate a task result, or is authorized to act on your organization’s behalf in the way it claims. Authentication and authorization schemes exist in the protocol, but the actual trust decision — should this agent be allowed to place this order, approve this claim, move this money — remains an organizational governance problem that no wire protocol can absorb for you. It also doesn’t solve semantic interoperability. Two agents can exchange a perfectly well-formed A2A message and still disagree about what the underlying business terms mean. A “priority” field in a logistics agent’s task might not map cleanly to a “priority” field in a customer support agent’s task, even if both speak fluent A2A. Protocols standardize syntax and exchange mechanics. They don’t standardize meaning, and any team that assumes adopting A2A eliminates the need for careful interface design between specific agents is going to relearn, expensively, a lesson that API integration teams learned a decade ago. And it doesn’t solve negotiation logic. When two agents disagree — about price, about task ownership, about whose result is authoritative — A2A gives them a structured way to exchange that disagreement. It does not resolve it. The reasoning still has to live somewhere, usually back in a human-defined policy layer, because handing negotiation entirely to model-driven judgment across organizational boundaries is a liability question, not a protocol question. The practical takeaway isn’t “adopt A2A” as a blanket instruction. It’s narrower and more useful than that: A2A is the right layer to invest in the moment your agent architecture crosses a boundary you don’t fully control — a different team, a different vendor, a different company. Inside a single team’s boundary, where you control both ends of an integration, a custom interface is often still simpler and A2A’s overhead isn’t buying you much. The teams getting real value out of A2A right now are the ones treating it the way mature engineering organizations treated REST fifteen years ago — as infrastructure plumbing that reduces integration cost at scale, not as a strategy. The Agent Card becomes part of your agent’s deployment checklist alongside its system prompt and its tool permissions. Task state handling becomes part of your observability stack, not an afterthought bolted on when something silently hangs in “working” for six hours. The organizations that will get burned are the ones treating A2A adoption as a substitute for the governance work — ownership, authorization boundaries, semantic contracts between specific agent pairs — that the protocol was never designed to do. A2A is the new API in the narrow, correct sense: a shared, boring, well-governed contract for how independently built systems talk to each other. It is not, and was never going to be, the thing that makes multi-agent systems trustworthy by default. That part is still on you. [A2A Is the New API: What Agent-to-Agent Protocols Actually Solve](https://pub.towardsai.net/a2a-is-the-new-api-what-agent-to-agent-protocols-actually-solve-301fc8196d6e) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.