A2A - the Agent2Agent protocol

When two agents built by different teams need to work together, the usual answer is to wrap one as the other’s tool - a function call dressed up as collaboration. That works for a fixed set of capabilities, but it collapses everything an agent can do into a signature: the wrapped agent cannot push back, cannot ask a clarifying question, cannot say “that part of the task is outside what I will do”. A2A is the open protocol that lets agents talk to each other as agents - discovering what the other can do, handing over a task, and tracking it to completion - without either side seeing inside the other.

Originally built at Google and now governed by the Linux Foundation’s Agentic AI Foundation - the same body that looks after MCP - A2A reached v1.0 in 2026 as its first stable, production-facing release. The technical steering committee includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow, which matters less as a list of names than as an answer to the question every open protocol has to pass: does anyone besides its author have to implement it?

What boundary it actually governs

A2A’s place in the stack is specific, and easy to get wrong:

MCP connects an agent to tools, data and prompts - the boundary between a model’s host and the capabilities it can call.
A2A connects one agent to another agent - the boundary between two autonomous systems that each have their own loop, their own tools and their own state.

The distinction that matters is opacity. Two A2A agents are opaque to each other by design: neither exposes its internal logic, memory, or the tools it used to complete a task. A2A exists precisely because wrapping an agent as a tool strips that opacity - the caller sees a function, not a partner. If what you need is a function, use MCP; A2A is for when the thing on the other end is itself an agent that might negotiate, refuse, or ask for clarification.

The model in four objects

A2A keeps its surface small: four objects carry nearly all of it.

Object	What it is	The point of it
Agent Card	A JSON document a server publishes describing its identity, capabilities, skills and authentication requirements	How a client finds out what a remote agent can do before sending it work - the discovery mechanism
Task	The stateful unit of work, identified by a unique id	Everything A2A does is a task that moves through a lifecycle; the client tracks it rather than holding a connection open
Message	One unit of communication between client and server	Carries the content of a turn - and can request more input mid-task
Artifact	A result the task produces	A file, a record, a piece of generated content - the thing the task was for

A Message is made of Parts - text, data, or a file - which is how the protocol stays modality-independent: the wire does not care whether the content is prose or a spreadsheet.

Discovery: the Agent Card

A client learns what a remote agent can do by fetching its Agent Card - typically from a well-known URI - before it sends anything. The card says what the agent can do, what skills it advertises, which protocol bindings and versions it supports, and how to authenticate.

v1.0 hardened this in two ways that matter for cross-organisation use. An agent can publish a signed card - a JWS signature over a canonicalised form of the card - so a client can verify that the card really came from who it claims to be, rather than trusting whatever answered on a URL. And an agent can expose an extended card behind authentication, so the public card stays a minimal advertisement while the richer detail is only visible once the caller has identified itself.

The task lifecycle - and why it is not a job queue

Life of an A2A task

Four terminal states, two states that are interruptions rather than endings.

The interrupted states are the point. Input-required and auth-required let a remote agent hand a task back to the client mid-flight - for an answer, or for a credential - without the task ending. A protocol with only terminal states would be a job queue, not a conversation. On a narrow screen, scroll the diagram horizontally; the same states are listed below.

Submitted: the task is acknowledged and carries a unique id.
Working: the remote agent is processing it. The client streams updates or gets push notifications.
Input-required / auth-required: interrupted states - the task is alive but paused until the client supplies an answer or a credential.
Completed, failed, canceled, rejected: terminal states. A task that reaches one cannot move again, and a client can only cancel a task that has not reached one.

The lifecycle is the part of the protocol that most clearly separates it from a request-response API. A task is created in submitted, moves to working while the remote agent processes it, and ends in one of four terminal states: completed, failed, canceled, or rejected. Two further states - input-required and auth-required - are interruptions, not endings: the remote agent can pause the task to ask the user a question, or to demand a credential, and the task resumes when the client supplies what was asked for. A protocol without those states could only express “done” or “not done”; with them, it can express a real back-and-forth that outlives any single connection.

That is also why A2A builds delivery of updates into the model rather than bolting it on: a client can stream task updates over Server-Sent Events, subscribe to a task, or register a push notification endpoint for work that outlives the HTTP request - the pattern the spec calls long-running operations.

Three wire bindings, one contract

A2A is not one transport - it is one logical protocol expressed over three bindings, with the specification requiring functional equivalence across them:

JSON-RPC 2.0 over HTTP - the reference shape, and the one most SDKs lead with
gRPC - for environments already on it, with native multi-tenancy scoping in v1.0
HTTP + JSON / REST - plain endpoints for stacks that do not want a framework

The agent’s AgentCard declares which interfaces it supports (each AgentInterface carries its own url, protocolBinding and protocolVersion in v1.0), so a client picks the binding that fits - and can negotiate version differences per interface rather than per agent.

What v1.0 changed

v1.0 is less a new protocol than a hardening of 0.3 - the release notes describe it as refinement rather than reinvention. The changes that affect a deployment:

Renamed operations for consistency, and a reorganised Agent Card structure.
Versioning moved to the interface: protocolVersion lives on each AgentInterface rather than the card, so an agent can serve v0.3 and v1.0 side by side and clients migrate progressively.
Signed Agent Cards and modern OAuth 2.0 (device code flow, PKCE), with the deprecated implicit and password flows removed.
Multi-tenancy and cursor-based pagination for task listing.
A versioned extension mechanism with declared requirements - extensions are first-class, not fields bolted onto the schema.

Cards are designed so an agent can advertise both the old and new protocol behaviour at once, which is the migration story: not a flag day, but overlap.

Where it breaks

Discovery is only as fresh as the card. A cached card describes an agent that may have moved or changed - the spec has explicit caching rules for a reason, and treating the card as static configuration is how “suddenly the agent does not exist” bugs happen.
Opaque means opaque. The caller cannot see how a remote agent did its work, which is the security property and the debugging problem in one - a wrong answer arrives with no trace of why.
Tasks that outlive the connection need somewhere to live. Streaming covers the connected case; for genuinely long-running work you need push notifications and somewhere durable to hold task state, and the spec deliberately leaves both as deployment decisions.
A2A does not compose the agents. It standardises the conversation between two agents, not the orchestration that decides which agent should be called - that is still the harness’s or framework’s job.

What this is not for

Connecting an agent to a database or a tool - that is what MCP is for, and the two are designed to sit together rather than compete.
Intra-process coordination inside one system - the overhead of a wire protocol buys nothing when a function call would do.
Anything that needs the caller to see or control how the callee works - A2A is deliberately opaque, and a workflow that needs to inspect the remote agent’s steps wants a framework-level handoff instead.

What to watch

Specific things that would change what this page concludes.

Whether A2A extensions become the place where real deployments live - the extension mechanism is versioned and required-declared, which means ecosystems can diverge inside the spec
Whether the signed Agent Card becomes the de facto trust layer, or whether deployments keep relying on out-of-band allowlists
Adoption relative to vendor-specific agent APIs - the protocol wins only if calling a foreign agent is genuinely cheaper than wrapping one as a tool