A2A
Why it matters
Deep Dive
The problem A2A addresses is straightforward to state: as organizations deploy more agents, those agents need to hand work to each other, and every pair currently requires bespoke integration. A2A defines a common pattern for that handoff. One agent acts as the client, formulating a task; another acts as the remote agent, executing it. The two exchange context, instructions, and results over ordinary web infrastructure — HTTP with JSON-RPC 2.0 as the wire format, and Server-Sent Events for live updates — so adoption does not require a new transport layer or a shared runtime. Crucially, agents remain opaque to one another: they coordinate through declared capabilities and task state, not by sharing memory, weights, or internal reasoning.
Agent Cards and Capability Discovery
Discovery in A2A works through the agent card: a small JSON document, typically published at a well-known path such as /.well-known/agent.json on the agent's domain, that describes who operates the agent, what skills it offers, which input and output formats it accepts, and what authentication it requires. A client agent fetches the card before sending any real work, so it can decide — programmatically or through an LLM planner — whether this remote agent is even a candidate for the job. In practice, cards surface in two ways: directly, when a workflow already knows the URL of a partner agent, or through curated registries that an enterprise maintains for its approved agents. The card model is what turns A2A from a messaging convention into an actual discovery layer, and it mirrors how an autonomous agent reasons about any other resource: read a description, match it against the goal, then act.
Tasks, Messages, and Artifacts
The unit of work in A2A is the task, and it has an explicit lifecycle: submitted, working, input-required, completed, failed, or canceled. Inside a task, the two agents exchange messages, and each message is made of parts rather than raw text — a text part for natural language, a file part for binary content, or a data part for structured JSON payloads like forms and price quotes. This part model matters because real business workflows run on structured data, and A2A lets agents negotiate over structured output instead of forcing everything through chat prose. When a task finishes, its results are delivered as artifacts: named outputs, again built from parts, that the client agent can consume itself or pass along to the next step of a larger agentic workflow.
The lifecycle states earn their keep on long-running work. A task that takes minutes or hours can stream progress events to the client over Server-Sent Events, or deliver updates through push notifications to a webhook when the client cannot hold a connection open, keeping streaming viable even for disconnected consumers. The input-required state is the subtle one: it lets the remote agent pause and ask a clarifying question mid-task, which is how multi-turn negotiation between agents happens without breaking the task abstraction.
A2A Doesn't Replace MCP
The most common misconception about A2A is that it competes with MCP. It does not — the two protocols operate at different layers. MCP standardizes how a single agent connects to tools and data sources: calling a function, reading a resource, running a query. A2A standardizes how two independent agents coordinate, with one delegating a task to a peer that may belong to a different team, vendor, or trust domain entirely. The shorthand you will hear is that MCP is the vertical interface (agent to tool) while A2A is the horizontal one (agent to agent).
A realistic production setup uses both in the same call chain. An orchestrator agent might use MCP for tool use — hitting a CRM, a search index, or a code repository — and then use A2A to subcontract a specialist agent, such as a contract-review agent run by the legal department, which itself relies on MCP and function calling internally. Neither protocol dictates what happens inside the other agent, and that opacity is a deliberate design choice: it lets organizations collaborate without exposing prompts, memory, or proprietary reasoning.
Governance, Ecosystem, and Open Questions
Google released A2A as an open specification with reference SDKs in 2025, backed at launch by more than 50 technology partners spanning enterprise software vendors, frameworks like LangChain, and consultancies. It then donated the project to the Linux Foundation so that no single vendor controls its evolution. That governance move matters for adoption: protocols only become plumbing when competitors can implement them without fearing that the rules will change under them. The specification, SDKs, and sample agents are all public, and the design deliberately reuses existing web standards rather than inventing new ones.
The hard problems ahead are less about message formats and more about trust. An agent card declares what authentication an agent requires, but nothing in the protocol tells you whether to believe the card, which makes cross-organization A2A traffic an AI security question as much as an integration question. Prompt injection is a concrete risk: a malicious or compromised remote agent can embed hostile instructions in task results that the client agent's model will dutifully read. Teams building multi-agent systems on A2A today typically counter this by restricting discovery to curated registries, validating artifacts before they reach a model, and treating every remote agent as untrusted by default.