A2A Protocol Explained: Agent Discovery, Delegation, and Beyond

On April 9, 2025, Google announced the Agent2Agent protocol at Google Cloud Next, releasing it as an open specification for how autonomous AI agents from different vendors, frameworks, and organizations can discover one another, delegate tasks, and coordinate work without exposing internal logic, memory, or implementation details. Understanding what the A2A protocol needs requires an understanding of the infrastructure problem it was built to solve.

The Fragmentation Problem Before A2A

Before the Google A2A protocol existed, enterprise teams building multi-agent systems operated inside a structurally broken wiring model. An agent built on LangGraph had no standard way to hand off work to an agent built on CrewAI or deployed inside a Salesforce workflow. Every cross-vendor agent pair required custom API integration code, negotiated on a case-by-case basis. At scale, organizations found themselves maintaining a tangle of bespoke connectors, each with its own auth scheme, error model, and message format.

Anthropic's Model Context Protocol addressed one dimension of the problem: how a single agent connects to tools and data sources. MCP operates on the vertical axis, linking an agent downward to its resources. A2A protocol AI agents need something different: a horizontal layer that lets peers find each other, negotiate capabilities, and delegate work without any prior bilateral agreement. A2A fills exactly that role.

The Protocol's Architecture and Governing Body

The A2A protocol is built on transport and messaging standards that enterprise teams already run: HTTP/HTTPS at the network layer, JSON-RPC 2.0 for request-response messaging, and Server-Sent Events for streaming long-running tasks. Building on widely adopted web infrastructure was a deliberate choice. The goal was an A2A protocol architecture that existing IT stacks could adopt without introducing new transport dependencies.

Two months after launch, on June 23, 2025, Google donated the full specification, SDKs, and developer tooling to the Linux Foundation, establishing the Agent2Agent Protocol Project under neutral governance. Removing single-vendor control over the specification was the signal the broader industry needed to commit at scale.

From 50 Partners to an Industry Bus

The launch cohort in April 2025 included over 50 technology partners, with active production interest in A2A protocol use cases spanning HR, finance, IT operations, and customer workflows. By April 2026, that number had grown to more than 150 organizations, with the GitHub repository accumulating well over 20,000 stars and production-ready SDKs available in Python, JavaScript, Java, Go, and .NET.

Major cloud providers have integrated A2A natively into their platforms. The protocol now standardizes how A2A protocol AI agents discover and message each other across organizational and vendor boundaries, much like how HTTP standardizes request exchange between web services. A2A defines the messaging contract. It doesn't supply the routing, registry, and governance infrastructure that an AI agent orchestration layer still needs to provide on top of it.

The A2A protocol architecture rests on a deliberate design constraint: agents should be able to find each other and exchange work using infrastructure that enterprise environments already run, without negotiating bespoke connection agreements at every integration point. Discovery at this level forms the foundation of AI agent orchestration, since no orchestration pattern built on top of the protocol can function until agents reliably locate one another.

The Client-Remote Agent Model

A2A defines two structural roles:

1. A client agent initiates work by identifying a task it wants to delegate, locating a suitable remote agent, and sending that task over the protocol.

2. The remote agent, functioning as an A2A server, receives the request, executes against it, and returns results through defined response channels.

Neither party needs visibility into the other's internal architecture, memory state, or model implementation, a separation that underpins dependable AI agent orchestration patterns at scale.

What makes A2A protocol agent discovery different from static API registration is its runtime nature. A client agent doesn't require pre-configured knowledge of every peer it might work with. Instead, discovery happens dynamically at runtime, through a standardized endpoint that every compliant agent must expose, a pattern that scales naturally as AI agent orchestration for complex workflows brings new agents online without manual reconfiguration.

How Well-Known URIs Enable Runtime Discovery

Every A2A server publishes an Agent Card at https://{server_domain}/.well-known/agent-card.json, following the conventions of RFC 8615. A client agent issues an HTTP GET to that path and retrieves a structured JSON document describing the remote agent's identity, skills, supported interaction modes, service endpoint URL, and authentication requirements.

A2A protocol agent discovery also supports two alternative resolution paths: enterprise-managed registries or catalogs for environments where agents are governed centrally, and direct configuration for cases where the Agent Card URL is pre-provisioned. All three methods converge on the same data structure. The Agent Card is the stable interface regardless of how a client finds it.

Transport, Messaging, and Streaming

All task communication in the A2A protocol architecture travels over HTTPS, with request and response payloads formatted as JSON-RPC 2.0 objects. The core task methods are message/send for synchronous interactions and message/stream for long-running work. When a client issues message/stream, the server responds with a Server-Sent Events stream, pushing incremental status updates and partial results as the task progresses. The SSE connection stays open until the task reaches a terminal state or the client cancels.

For fully asynchronous workflows, A2A protocol AI agents support push notifications: the client registers a webhook endpoint, and the server posts task state changes out of band without holding an open connection. Synchronous request-response, streaming, and async push notifications are all first-class interaction patterns in the same protocol, giving teams designing AI agent orchestration patterns flexibility in how agents exchange work.

Where A2A and MCP Divide the Problem Space

The relationship between A2A and MCP is architectural, not competitive. MCP defines how a single agent connects downward to tools, APIs, data sources, and external services. It operates on the vertical axis of an agent's capability stack. A2A handles the horizontal axis: how peer agents discover each other, negotiate capabilities at runtime, and delegate tasks across organizational or vendor boundaries.

Production multi-agent systems need both. An agent might use MCP to retrieve documents and query a database, then use A2A to delegate a specialized subtask to a peer agent running inside a different organization's infrastructure. We built our agentic mesh with this layered reality in mind, treating A2A protocol AI agents as distributed peers that require an AI agent orchestration layer well above the transport layer to collaborate reliably and maintain governance.

The Agent Card is the foundational unit of A2A protocol agent discovery. Every compliant A2A server must publish one, and every client agent relies on it before sending a single request. It's worth treating Agent Card design as an architectural decision in its own right because the way an agent declares itself shapes every downstream interaction.

Required and Optional Fields in the JSON Structure

An Agent Card is a JSON document with a defined schema. Required fields cover the agent's identity: name, description, version, url, skills, and protocolVersion.

The provider object identifies the organization that publishes the agent, including its name and optional support contact information.

The capabilities object specifies which A2A protocol features the server supports: whether it supports SSE streaming, whether it accepts push notification registration, and which A2A protocol version it implements. The supportedInterfaces field lists endpoint-and-transport combinations in preference order, allowing a single agent to expose the same functionality over multiple protocol bindings simultaneously.

The skills array carries the card's semantic weight. Each AgentSkill object includes an id, name, description, and the inputModes and outputModes fields, which specify supported MIME types for that skill. An agent that handles both text and structured JSON inputs explicitly declares them here. Clients use skill definitions to determine fit before initiating any task.

Authentication Declaration and Extension URIs

Authentication requirements appear directly in the Agent Card via security scheme objects modeled on OpenAPI 3.0 Security Scheme definitions. A card might declare Bearer token authentication, OAuth 2.0 flows, or API key schemes, giving the client everything it needs to acquire credentials before sending the first message/send request. A2A protocol security instructs that credentials themselves are never embedded in the card; only the scheme and flow type appear.

The extensions field supports protocol extension declarations using URI identifiers. The AP2 Agent Payments extension, for example, registers itself via a specific URI in the Agent Card, signaling to clients that the agent participates in agentic commerce workflows. Extension URIs let the protocol evolve without breaking existing card readers.

What v1.0 Signed Agent Cards Add

The v1.0 specification introduced Agent Card signing using JSON Web Signature as defined in RFC 7515, with JSON Canonicalization Scheme per RFC 8785 applied before signing to ensure consistent serialization across implementations. A client that receives a signed Agent Card can verify both that the card content is unaltered and that it originates from the declared provider.

In A2A protocol use cases where agents operate across organizational trust boundaries, unsigned cards leave a meaningful attack surface open: a compromised registry or a man-in-the-middle could substitute a card pointing to a malicious endpoint. Signed cards close that gap at the discovery layer, before any task delegation occurs. For teams building AI governance workflows across multiple agent providers, card signature verification belongs in the agent onboarding checklist, not as an afterthought.

The Task is A2A's fundamental unit of work. Every delegated operation, from a synchronous data lookup to a multi-day document analysis workflow, lives inside a Task object with a unique ID, a stateful lifecycle, and a structured output model. How A2A protocol AI agents manage that lifecycle determines how reliably they behave at production scale.

Initiating a Task with message/send and message/stream

A client agent initiates work by sending a message/send or message/stream JSON-RPC request to the remote agent's service endpoint. The message body includes a role field set to "user" and a parts array containing one or more content units, such as TextPart, FilePart, or DataPart. For synchronous work, message/send returns the completed Task or a direct Message response in the JSON-RPC reply.

For long-running work, the message/stream keeps the connection open, and the server pushes incremental updates via Server-Sent Events, each carrying a complete JSON-RPC response object, either a TaskStatusUpdateEvent or a TaskArtifactUpdateEvent. Clients consuming the SSE stream get real-time visibility into task progress without polling.

Task Lifecycle States

A Task moves through a defined set of states. The server marks it as submitted when it accepts the request, then working while the agent actively processes it. If the agent needs clarification before proceeding, the state becomes input-required. If it needs the client to complete an authentication step mid-task, the state becomes auth-required, a dedicated interrupted state distinct from a simple clarification request. A Task can also sit in unknown when its current state can't be determined, such as after a lost connection or an unrecognized status from the remote agent. Terminal states are completed, failed, canceled, and rejected.

The input-required and auth-required states matter most in A2A protocol use cases involving approval-dependent or regulated workflows. When a remote agent signals input-required, the client sends a follow-up message to the same Task ID to resume execution. When it signals auth-required, the client completes the necessary auth step, typically acquiring or refreshing a credential, before resuming the same Task. A Task that reaches a terminal state is immutable: retrying a failed operation requires creating a new Task.

Artifact Handling and Structured Output

When an agent produces output, it emits Artifacts alongside or instead of a reply message. An Artifact is a named, typed output composed of Parts, carrying a mimeType, an artifactId, and optionally a file reference for binary content. In SSE streams, artifacts arrive incrementally via TaskArtifactUpdateEvent objects, letting clients begin consuming large outputs before the task completes.

The A2A protocol architecture treats Artifacts as first-class deliverables. A coding agent producing source files, a data agent returning structured JSON, and a document agent generating a PDF all use the same Artifact model, keeping output handling consistent across A2A protocol AI agents regardless of the content type.

Polling, Cancellation, and Reconnection

For clients tracking a long-running task without an open stream, tasks/get retrieves the current Task state by ID. tasks/cancel instructs the remote agent to terminate execution and emit the canceled state. If a streaming client loses its SSE connection before a task completes, tasks/resubscribe re-establishes the stream against the existing Task ID.

For fully disconnected workflows, clients register a webhook URL for push notifications: the server posts status and artifact update events to that URL as the task progresses, with no persistent connection required.

Proper error recovery in distributed A2A protocol AI agents workflows means handling each JSON-RPC error code the specification, including task-not-found, unsupported operation, and push notification configuration failures. Teams building multi-agent lifecycle visibility find that task state transitions are the most reliable signal for understanding what a distributed agent system is doing at any moment.

A2A protocol security operates on a deliberate architectural principle: the protocol defines where credentials and identity schemes are declared, but it doesn't build a proprietary identity system. Instead, it integrates with the authentication infrastructure enterprises already run, placing security enforcement at the HTTP transport layer rather than inside JSON-RPC payloads.

How Authentication Schemes Map from Agent Cards to the Transport Layer

Each Agent Card's securitySchemes field declares which authentication mechanisms the server accepts. The specification defines five scheme types: API keys, HTTP authentication, OAuth 2.0 with configurable flows, OpenID Connect Discovery, and mutual TLS. A SecurityScheme object must specify exactly one type, giving the client agent unambiguous instructions for credential acquisition before sending any request.

OAuth 2.0 is the recommended framework for most cross-organizational A2A protocol use cases. The Agent Card declares the supported flow type, whether authorization code, client credentials, device code, or implicit, along with the token endpoint URL. The client acquires a short-lived token out of band and presents it in the HTTP Authorization: Bearer header. The receiving agent validates the token's iss, aud, sub, exp, and scope claims and caches the jti to prevent replay.

For environments requiring higher assurance, mTLS adds certificate-based mutual authentication at the transport layer. Both client and server present certificates during the TLS handshake, establishing machine identity independently of token-based flows. Layering mTLS-bound tokens per RFC 8705, or demonstrating Proof of Possession per RFC 9449, further constrains token usability to the authenticated connection that produced them.

Trust Boundaries and Opaque Execution

A2A protocol AI agents operating across organizational boundaries share no internal state. The protocol enforces opaque execution: a remote agent processes a task against its own tools and context, returning only defined Artifacts and status updates. The client agent never gains visibility into the remote agent's model, memory, prompts, or tool configurations.

Identity in A2A lives at the HTTP layer. The JSON-RPC payload carries no authentication material, keeping the attack surface on the messaging layer narrow. Authorization is the remote agent's responsibility once authentication succeeds. The specification aligns with enterprise practices but doesn't mandate a specific authorization model, leaving scope enforcement and data residency controls to implementers.

Threat Surfaces Specific to Cross-Organizational Agent Networks

A2A protocol security threat modeling identifies three primary attack classes: agent impersonation via fabricated Agent Cards, Agent Card tampering in transit or within a compromised registry, and lateral movement across delegation chains when downstream agents inherit the initiating client's trust level without independent verification.

Signed Agent Cards, introduced in v1.0 via JWS per RFC 7515, make card provenance cryptographically verifiable and directly address the first two classes. For teams managing AI governance across enterprise agent networks, treating card signature validation and authentication scheme verification as mandatory pipeline steps closes the gaps the protocol intentionally leaves to implementers.

The A2A protocol specification is precise about what it governs: transport bindings, Agent Card structure, task lifecycle states, authentication scheme declaration, and artifact formatting. Everything above that layer - the decisions about who approves what, when humans review agent output, how delegation authority gets scoped, and what gets logged for compliance - belongs to the implementer. That's architecture by design, not an oversight.

The Governance Gap Is Structural

The specification explicitly states that authentication, authorization, privacy, tracing, resiliency, and monitoring must align with established enterprise practices, without mandating how to do so. For straightforward A2A protocol use cases, this flexibility works well: a pair of internal agents exchanging structured data can operate within existing API governance frameworks with minimal additional infrastructure.

Regulated environments expose the limits of that flexibility. A financial services workflow where a client agent delegates a trade analysis task to a remote agent has no native A2A mechanism for capturing an auditable approval record, enforcing a human review gate before the task advances, or restricting delegation depth across a chain of agent-to-agent handoffs. The protocol delivers the task and returns the artifact. What happens in between, at the decision layer, is entirely outside its scope.

Intent Negotiation and Semantic Ambiguity

A2A protocol agent discovery gives a client agent enough information to determine whether a remote agent declares the right skills for a task. What it doesn't provide is a framework for resolving semantic ambiguity when the client's intent and the remote agent's interpretation of a skill diverge. The input-required task state surfaces this problem at runtime, but the resolution protocol is left to the messaging content, not to any structured negotiation layer.

In multi-hop delegation chains, where a client agent delegates to a remote agent that delegates further, semantic drift compounds across handoffs. Each agent interprets the task using its own context window and tool configuration, without a shared interaction contract to enforce consistent intent across the chain.

Where Differentiation Lives

For A2A protocol AI agents operating in high-stakes or regulated environments, the interaction layer above A2A is where architectural decisions carry the most operational weight. Approval workflows, delegation-authority scoping, audit-trail generation, human-in-the-loop checkpoints, and policy enforcement all require infrastructure that the protocol deliberately leaves open. The protocol's delegation model compounds the issue further. A2A defines how a client sends a task and how a remote agent returns a result, but it doesn't give either side a native way to pause mid-task, ask a clarifying question, and resume the same exchange. Real agent collaboration depends on that kind of back-and-forth, the way one colleague checks a detail with another before finishing a task, and building it requires interaction infrastructure that the specification never set out to provide.

The Google A2A protocol's design reflects a sound principle: standardize the transport and task exchange, then let implementers build the governance layer appropriate to their risk and compliance context. Teams investing in multi-agent lifecycle management and AI governance standardization are building precisely in that space, layering interaction-layer controls atop a protocol that was never meant to carry them natively.

Band's platform is built for closing the gaps the A2A protocol leaves open by design, providing the infrastructure that A2A protocol AI agents need to collaborate with humans under governed, auditable conditions.

The Agentic Mesh and Agent Interaction Control Plane

Band treats multi-agent systems as distributed systems with a distinct communication challenge: agents use natural language, behave non-deterministically, establish trust across organizational boundaries, and fail by cascading errors down delegation chains rather than returning error codes. Standard API governance infrastructure, the kind that works well for microservices, doesn't map onto any of those properties.

The Agentic Mesh provides the connectivity layer that lets A2A protocol AI agents find each other and participate in shared workflows. The Agent Interaction Control Plane sits above it, providing agents with tools to communicate and humans with visibility into what's happening, while leaving sequencing and delegation decisions to the agents themselves. Where the A2A protocol architecture handles transport and task exchange, Band handles the interaction infrastructure that makes distributed agent work visible and auditable, without dictating how agents choose to work together.

Governance Where Agent Work Happens

Band's approach to AI governance standardization anchors approval workflows inside the shared interaction space rather than in runtime logs that only the orchestrating system can read. When a client agent delegates a task to a specialist agent, and that task requires human review, the request, the forwarded context, the approval decision, and the specialist's result all appear as messages in a shared room. Every participant, agent, or human holds the same working record.

The room itself carries whatever identifier fits the work, a ticket number, a project name, or a task description, and agents control what context they share through the same tool calls they use to communicate. Enforcement lives in application logic; Band makes the handoff record visible and auditable without forcing every agent onto a shared runtime.

Lifecycle Visibility and Coordinated Execution

A2A protocol use cases involving long-running, multi-hop agent work expose the need for lifecycle infrastructure that the protocol's task states alone don't satisfy. Band's multi-agent lifecycle tooling keeps extended agent workflows visible across their full duration, surfacing what each agent believed, decided, and handed off at every step.

For engineering workflows, coordinating coding agents across planning, review, implementation, and testing stages requires sequencing and approval logic that sits above any single A2A task exchange. Band provides that coordination layer for developers and engineering teams building production multi-agent systems, without requiring them to invent governance infrastructure from scratch.