How A2A Works: The Agent2Agent Protocol Explained

If 2024 was the year every company built an AI agent, 2025 is the year they realized those agents cannot talk to each other. A travel agent built on one framework cannot hand a booking to an airline agent built on another. A research agent that finds a paper cannot ask a separate coding agent to reproduce it. Each agent lives in its own silo, fluent only with its own tools. The Agent2Agent protocol, usually shortened to A2A, is the open standard built to fix this: a common language so agents built by different teams, on different frameworks, from different vendors can delegate work to each other and cooperate on a goal.

Understanding how A2A works means understanding one analogy and four pieces. The analogy is that A2A is for agents what HTTP was for websites: a shared protocol that turns a collection of isolated systems into a network. The four pieces are the agent card (how an agent advertises what it can do), discovery (how other agents find it), the task (the unit of work one agent asks another to do), and the transport (how messages actually move). Everything else is security and ergonomics built on those four.

The problem: the agent interop wall

Today’s agents are good at calling tools, and standards like the Model Context Protocol have made connecting an agent to its own tools much easier. But tool-calling is an agent reaching down to a function it owns. Cooperating with another agent is a peer relationship: two independent systems, each with its own model and its own owner, negotiating who does what. Without a protocol, the only way for two agents to interact is a bespoke integration, and bespoke integrations do not scale.

This is the classic N-by-M problem. Ten agent vendors wanting to interconnect need forty-five custom integrations. A hundred vendors would need nearly five thousand. The cost explodes, so nobody bothers, and every agent stays an island. A2A collapses that to a single protocol each agent implements once, the same way MCP collapsed tool integration to a single standard. A useful shorthand is that MCP connects an agent to its tools, and A2A connects agents to each other.

What A2A actually is

A2A is an open protocol, contributed by Google in 2025 with a broad coalition of partners, for agent-to-agent communication over the web. It is deliberately model-agnostic and framework-agnostic. An agent built with LangGraph, an agent built with the Google Agent Development Kit, an agent built by hand: all of them can speak A2A as long as they implement the protocol. It rides on ordinary web infrastructure: HTTP, JSON-RPC for requests, and Server-Sent Events for streaming. There is no central registry or broker; an A2A agent is just a network endpoint that implements a small set of methods.

The design goal is that delegating a task to a remote agent should feel as natural to the delegating agent as calling a local tool. The delegating agent does not need to know which model powers the remote agent or how it is built. It only needs to know what the remote agent can do and how to ask.

The agent card: how an agent advertises itself

Every A2A agent publishes an agent card: a small JSON manifest, usually served at a well-known URL, that describes the agent to the world. The card contains the agent’s identity, the network endpoint where it lives, its capabilities (streaming, push notifications), and a list of skills. Each skill has a name, a description, and the input and output types it accepts. The agent card is the protocol’s version of a tool description, but for a whole agent instead of a single function.

The card is doing the same job a good tool description does inside a single agent: it lets a caller decide, without trial and error, whether this agent is the right one for a job. A delegating agent reads the skill descriptions of candidate agents and routes the task to whichever advertises the matching capability. This makes the agent card the central object in discovery and routing: invest in it the way you would invest in any public API surface.

Discovery and routing

Discovery in A2A is intentionally lightweight. There is no mandatory global directory (though registries can exist). In the common case, an application or orchestrator already knows the URLs of the agents it wants to use, fetches each one’s agent card, and decides which to call based on the skills advertised. An orchestrator building a travel flow might hold a shortlist of three booking agents, read their cards, and route each user request to the agent whose skills best match.

Because routing is driven by the agent card, the quality of your skill descriptions determines how well other systems can find and use your agent. Vague skills mean misrouted tasks. This mirrors the lesson from single-agent tool use, where tool description quality drives tool selection: except now the stakes are higher because the callee is a whole remote service, not a local function.

The task lifecycle

The task is the unit of work in A2A. When one agent wants another to do something, it creates a task with a message describing the goal and any input data. The remote agent receives the task, works on it, and eventually returns a result, but the path from request to result is richer than a single function call.

A task moves through states: submitted, working, input-required, completed, canceled, or failed. Most interesting is input-required, which lets the remote agent ask the caller a clarifying question mid-task instead of guessing. This turns a delegation into a conversation: the airline agent can ask the travel agent which seat class the user prefers, get the answer, and continue. Tasks can also stream progress updates as they run, which matters for long-running work, and they return artifacts (structured outputs like a booked itinerary or a generated file) alongside their final message.

This lifecycle is what makes A2A feel like cooperation rather than a remote procedure call. A tool returns or throws. An A2A agent can negotiate, ask questions, stream progress, and hand back rich results. That is the difference between calling a function and collaborating with a colleague.

Transport: JSON-RPC and streaming

Under the hood, A2A uses JSON-RPC over HTTP for its request-response methods: sending a task, querying its status, canceling it. For long-running tasks, it streams updates over Server-Sent Events, and for truly asynchronous work it supports push notifications via webhooks so the caller does not have to hold a connection open. These are mundane choices, and that is the point: A2A uses boring, reliable web primitives so it works through existing infrastructure, proxies, and firewalls without special handling.

A2A versus MCP

The most common confusion is whether A2A replaces the Model Context Protocol. It does not: the two solve different problems and compose cleanly. MCP lets an agent connect to tools and data sources: a database, a file system, an API. It is a vertical connection between an agent and resources it uses. A2A lets agents connect to each other: a horizontal connection between peers. A single agent typically uses both: MCP to reach its own tools, A2A to delegate to other agents. The travel agent uses MCP to call a payment tool and A2A to hand the booking to an airline agent. They are layers, not alternatives.

A worked example: planning a trip across agents

Picture a user asking a personal assistant agent to plan a weekend trip. The assistant is one agent; it does not itself book flights or hotels. Through A2A it discovers a flights agent and a hotels agent, reads their cards, and confirms both advertise the skills it needs. It sends a task to the flights agent with the destination and dates. The flights agent, working asynchronously, streams back candidate itineraries and then asks a clarifying question about preferred departure time. The assistant relays the question to the user, sends the answer back, and the flights agent completes the task with a booked ticket artifact. Meanwhile the assistant has kicked off a hotels task in parallel. The user sees one coordinated trip; behind it, three agents from three different vendors cooperated through a shared protocol.

Notice what each agent did not need to know. The assistant did not know which model powered the flights agent. The flights agent did not know how the assistant’s UI worked. Neither needed a bespoke integration with the other. The agent cards told them enough to cooperate, and the task lifecycle handled the conversation. That decoupling is the entire value proposition.

Authentication, authorization, and trust

Because A2A agents call each other across ownership boundaries, identity and permission are first-class concerns. Agent cards declare their authentication schemes, and callers present credentials such as OAuth tokens or API keys. Beyond authentication, there is the harder question of authorization and trust: should an agent be allowed to incur cost, take a side effect, or see certain data? Production deployments enforce scopes and often put a human checkpoint before an agent delegates anything irreversible. Trust between autonomous agents is still an active area, and most real systems today keep a human close to any delegation that has real-world consequences.

Where A2A is still early

A2A is young. The protocol is evolving, real-world deployments are growing but not yet ubiquitous, and the hardest problems (trust, payments between agents, shared memory, reasoning about a remote agent’s reliability) are unsettled. Treat it the way you would treat any early web standard: promising, worth building against, but not yet something to bet a critical path on without a fallback. The agent card and task lifecycle are stable enough to be useful; the ecosystem around them is still forming.

Common misconceptions

A2A is not a model or a framework. It is a protocol. It does not run agents; it lets them talk.
A2A does not replace MCP. They operate at different layers and are designed to be used together.
A2A does not require a central broker. Agents are peers on the web; registries are optional.

Pro Tips
Write agent cards like public API docs. Other agents route to you based on your skill descriptions. Treat them with the same care as a tool description inside a single agent, clear, scoped, with concrete examples.
Plan for the input-required state. The power of A2A is that a remote agent can ask a clarifying question mid-task. Build your orchestrator to relay those questions rather than treating delegation as fire-and-forget.
Keep a human near irreversible delegations. Inter-agent trust is unsolved. For any task with a real-world side effect, confirm before the remote agent acts.