Inside A2A: How Agents Become Peers

The last two parts went down, into MCP and the tool boundary. This part crosses the other line from part one, the one that goes across, to a peer. The protocol there is Agent2Agent, or A2A, introduced by Google in April 2025 and now developed under the Linux Foundation.¹ Everything about A2A looks different from MCP, and the reason is the single fact established in part one: the thing on the other side of this boundary is not a dumb, transparent tool but another agent, with its own model, its own tools, and one defining property worth saying out loud before anything else.

A new counterparty: the opaque peer

A peer agent is opaque. You cannot see its prompt, its memory, its model, or its toolset, and it will not show you; the word “opaque” is built into A2A’s own definition of itself as a protocol for communication between “opaque agentic applications.”² That single property flips the design. You do not invoke a peer the way you call a tool, because you do not know its internals well enough to call a function on it. You delegate to it: you hand it a goal expressed in messages, let it work however it works, and receive a result. A2A’s own documentation draws the line as agents partnering on tasks versus, in MCP, agents using capabilities.² Hold onto delegation-not-invocation; it explains every design choice below.

The Agent Card: discovery before trust

Before you can delegate to a peer you have never met, you need to know who it is and what it can do. A2A’s answer is the Agent Card, a JSON document an agent publishes, conventionally at the well-known path /.well-known/agent-card.json.² The card is the agent’s public identity: its name and description, the endpoint where it listens, the skills it offers, the protocol capabilities it supports (such as streaming or push notifications), and crucially the authentication schemes it requires, declared in a security field aligned with the OpenAPI specification.³

This is discovery before trust, and it is a different model from MCP’s. An MCP client is configured to connect to a specific server; an A2A client can find a peer by fetching its card, read off how to authenticate, check whether it has the skills the job needs, and only then decide to engage. Because the card is a security-relevant document, the v1.0 spec made signed Agent Cards a first-class, verifiable feature, letting a client cryptographically verify that a card really belongs to the agent it claims to.⁴ The card is the front door, and it tells you how to knock before you are let in.

Tasks: work with a lifecycle

When a client does engage, the unit of work is a task: a stateful job with a unique id, created when the client sends its first message.⁵ This is the deepest difference from MCP. A tool call is a function that returns; a task is a process that lives through a lifecycle, because a peer’s work can take minutes, can pause to ask you something, and can fail in ways a function call cannot.

The state machine is the thing to learn. A task begins submitted, moves to working, and can pause at two interrupted states: input-required when it needs a detail from the client, and auth-required when it needs credentials to proceed, each returning to working once satisfied.⁵ It ends in one of four terminal states: completed, failed, canceled, or rejected (the last for a task the agent declined before starting). A terminal task cannot be restarted; if you want to continue the thread, you open a new task that shares the same contextId, the identifier that groups related tasks into one ongoing conversation. That rule, terminal-is-final, is what lets both sides reason about a task without ambiguity: once it is done, it is done, and continuation is explicit.

Messages, Parts, and Artifacts

Inside a task, communication is structured into three nested pieces.² A Message is a single turn, tagged with a role of either user (the client) or agent (the remote). Each message carries one or more Parts, and a Part is the atomic content container holding exactly one of three things: text, a file (by URL or inline bytes), or structured data. When the agent produces a tangible output, it returns an Artifact: a document, an image, a structured result, with its own id, which can be streamed incrementally as it is generated.

The split between messages and artifacts is worth noticing because it separates the conversation from the deliverable. Messages are the back-and-forth of getting the work done; artifacts are the work itself, handed back as a first-class result rather than buried in chat text. That is again the delegation model showing through: you asked a peer to produce something, and the protocol gives that something a named place to live.

Three transports and two ways to stream

A2A speaks over ordinary web infrastructure, and as of v1.0 it offers three first-class transport bindings: JSON-RPC 2.0 over HTTP(S), gRPC, and HTTP+JSON / REST, with the spec requiring stricter, more uniform behavior across all three.^{5 4} The core methods read the way the task model implies: message/send to start or continue a task and get a single response, message/stream for a streaming response, tasks/get to poll a task’s state, tasks/cancel to stop one, and a small family of tasks/pushNotificationConfig/* methods to manage webhooks.⁵

Because a peer’s work can outlast a single HTTP request, A2A gives you two ways to receive progress. The first is streaming over Server-Sent Events, for a client that stays connected and wants live updates and incremental artifacts; it requires the agent to advertise streaming in its card. The second is push notifications, where the agent calls back to a client-registered webhook when something changes, for long-running or disconnected work where holding a connection open is impractical; it requires the pushNotifications capability.²

The flow to notice is that discovery and delegation are separate steps: fetch the card, then send the task, then receive a stream of status changes and artifacts. That shape is the whole protocol in one picture, and it is built around a task that takes time, not a call that returns immediately.

Security: enterprise auth at the edge

A2A’s security model is deliberately boring, which for enterprise software is a compliment. Because a remote agent is just an HTTP endpoint, A2A treats it like any other enterprise web service and reuses standard web auth rather than inventing its own.³ The agent declares its accepted schemes in the Agent Card’s security field using OpenAPI-style definitions, and clients authenticate with established mechanisms like OAuth2 and OpenID Connect. Credentials travel in HTTP headers, never in the A2A payload itself, which carries no user or client identity; a missing or invalid credential gets a 401, a valid but unauthorized one gets a 403; and production traffic must run over HTTPS.³

Opacity is itself a security property here. Because peers do not share internal memory, tools, or direct resource access, each agent can be secured as a standard client-server boundary without leaking its internals to its callers. That is a cleaner story than MCP’s, and the reason is structural: a peer is a separate trust domain by design, whereas an MCP tool runs inside the agent’s own context, which is exactly why part three’s threat model was so much hairier.

The road from 0.x to v1.0

It is worth being honest about how young this is. A2A was announced in April 2025 and donated to the Linux Foundation in June 2025, but it spent its entire first year on 0.x versions; the v1.0.0 spec only shipped in March 2026, which is when the three transports became uniformly first-class, signed Agent Cards arrived, and the patterns were tightened.⁴ Along the way even the discovery path changed, from an earlier agent.json to today’s agent-card.json, so older write-ups point at a path that has moved. If you read this and find a detail has shifted again, that is the nature of a protocol stabilizing in public, and the same caution from part three applies: pin to a spec version and expect the edges to keep moving. The shape, though, discovery then delegation then a task with a lifecycle, is settled, because it follows from the boundary rather than from any one release.

Takeaways

A2A is MCP’s mirror image, and the differences all trace to one fact:

1. You delegate to a peer, you do not invoke it. Because a peer is opaque, the protocol hands it a goal and lets it work, rather than calling a typed function. Every design choice follows from that.
2. Discovery comes before trust, through the Agent Card. A peer publishes a signed JSON card at a well-known URL describing its skills, capabilities, and auth schemes, so a client can find and vet it before engaging.
3. A task is a process with a lifecycle, not a call that returns. The state machine, with its interrupted and terminal states and its contextId grouping, exists because a peer’s work takes time and can pause or fail. Terminal is final; continuation is a new task.
4. Security is ordinary web auth at a real trust boundary. Standard OAuth2/OIDC declared in the card, credentials in headers, opacity by design. A peer is a separate trust domain, which makes its boundary cleaner than a tool’s. Next part zooms out from the two protocols to the landscape and the governance fight around them.