Agent-to-Agent Protocol (A2A)

"Talking to yourself is fine. Talking to another agent requires a protocol."

Pip, Diplomatically Networked AI Agent

27.3.1 The Agent-to-Agent Protocol

While MCP connects agents to tools and data sources, the Agent-to-Agent Protocol (A2A) connects agents to each other. Developed by Google and announced in April 2025, A2A defines a standard for how independently built agents discover each other's capabilities, negotiate task assignments, exchange intermediate results, and coordinate complex workflows. If MCP is USB for AI tools, A2A is the internet protocol for AI agent.

The need for A2A arises from the reality that complex enterprise workflows span multiple systems, each potentially managed by a different agent built by a different team using a different framework. A customer onboarding workflow might involve a document processing agent (built with LangGraph), a compliance checking agent (built with the OpenAI Agents SDK), and an account provisioning agent (a custom Python service). Without a standard protocol, integrating these agents requires brittle point-to-point connections. A2A provides the common language.

A2A is built on three core concepts: Agent Cards (JSON metadata files that describe an agent's capabilities, endpoint, and authentication requirements), Tasks (the unit of work exchanged between agents, with a defined lifecycle), and Messages (the communication medium within a task, supporting text, files, and structured data). The protocol uses standard HTTP/JSON-RPC, making it compatible with existing web infrastructure.

Agent Cards

This snippet defines an A2A (Agent-to-Agent) agent card that advertises capabilities and endpoint information.

{
 "name": "compliance-checker",
 "description": "Validates documents against regulatory requirements for financial services. Supports KYC, AML, and SOX compliance checks.",
 "url": "https://agents.example.com/compliance",
 "version": "2.1.0",
 "capabilities": {
 "streaming": true,
 "pushNotifications": false,
 "stateTransitionHistory": true
 },
 "skills": [
 {
 "id": "kyc_check",
 "name": "KYC Compliance Check",
 "description": "Validates customer identity documents against Know Your Customer regulations. Accepts passport, drivers license, or national ID.",
 "inputModes": ["text", "file"],
 "outputModes": ["text"]
 },
 {
 "id": "aml_screening",
 "name": "AML Screening",
 "description": "Screens individuals and entities against sanctions lists and PEP databases.",
 "inputModes": ["text"],
 "outputModes": ["text"]
 }
 ],
 "authentication": {
 "type": "bearer",
 "tokenUrl": "https://auth.example.com/token"
 }
}

27.3.2 Task Lifecycle

Every A2A interaction revolves around a Task. The client agent creates a task by sending a request to the server agent's endpoint. The task progresses through well-defined states: submitted, working, input-required (when the server agent needs more information), completed, failed, or canceled. This state machine provides clear visibility into where work stands and enables proper error handling at each transition.

The input-required state is particularly important for enterprise workflows. A compliance checking agent might need additional documents, or a clarification about which jurisdiction's regulations apply. Rather than failing or guessing, the agent signals that it needs input, the requesting agent (or a human) provides it, and processing resumes. This turn-based interaction model supports the kind of back-and-forth that complex real-world tasks require.

A2A supports both synchronous and streaming task execution. For quick operations (a lookup, a simple check), the client sends a request and receives a complete response. For long-running operations (document analysis, multi-step processing), the server streams progress updates and partial results. The client can monitor task state, cancel tasks that are taking too long, and handle timeouts gracefully. This flexibility accommodates the wide range of latencies inherent in agentic systems.

The six states form a finite state machine, and treating it as one (rather than as a loose set of status strings) is what makes A2A clients robust. Three of the states are terminal (completed, failed, canceled): once a task enters them no further transition is legal, so a client can safely release any resources it was holding. Two states are active (working, input-required): the task is alive and the client must keep listening. The one initial state (submitted) exists only briefly between the client posting the task and the server picking it up. Algorithm 27.3.1 below makes the legal transitions and their triggering events explicit; the client and server each maintain their own copy of this machine and the protocol's status-update messages are how they keep the two copies in sync.

Input: a task created by the client via tasks/send
Output: a task that ends in exactly one terminal state
States: submitted (initial), working, input-required (active),
        completed, failed, canceled (terminal)

1. start in submitted
   // client has posted the task; server has not yet begun work

2. transitions (current_state --[event]--> next_state):
   submitted      --[server dequeues and begins]--> working
   working        --[server needs a clarification/file]--> input-required
   input-required --[client supplies the requested input]--> working
   working        --[server produces the final artifact]--> completed
   working        --[unrecoverable error]--> failed
   input-required --[input deadline exceeded]--> failed
   any-active     --[client sends tasks/cancel]--> canceled

3. on entering a terminal state:
   a. server emits a final TaskStatusUpdateEvent with final=true
   b. client stops polling/streaming and releases the task handle

Two pieces of structure in Algorithm 27.3.1 are worth dwelling on. First, the only way back into working from input-required is a client-supplied input: the server cannot un-stick itself, which is precisely the property that lets a human or a calling agent stay in the loop on consequential decisions. Second, canceled is reachable from any active state but never from a terminal one, so a late tasks/cancel arriving after completed is a no-op rather than an error. Encoding these rules in the client (rejecting illegal transitions, ignoring post-terminal events) is what separates a robust A2A integration from one that corrupts its own task table when a peer misbehaves.

A Worked JSON-RPC Delegation Trace

To see the lifecycle in motion, consider an Intake Agent (the client) delegating a KYC check to the compliance agent whose Agent Card appears in Code Fragment 27.3.1a. Assumptions: the transport is HTTPS POST to the agent's url with each body a single JSON-RPC 2.0 object; authentication is a bearer token (from the card's authentication.tokenUrl) carried in the Authorization header on every request, so it is omitted from the bodies below for brevity; because the card advertises "streaming": true, the client opens the task with tasks/sendSubscribe and the server pushes status updates over Server-Sent Events rather than making the client poll. The following sequence of JSON-RPC messages walks the task through submitted to working to input-required to working to completed.

The client opens the task. The method is tasks/sendSubscribe; the params carry a client-chosen task id and the first message (role user, a text part naming the document to check):

// 1. Client -> Server: open the task and subscribe to updates
{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "tasks/sendSubscribe",
 "params": {
  "id": "task-kyc-7f3a",
  "message": {
   "role": "user",
   "parts": [{"type": "text", "text": "Run a KYC check on applicant 88412."}]
  }
 }
}

The server acknowledges by returning the task in submitted state, then immediately streams a working update as it dequeues the job. Each streamed event is a JSON-RPC result on the original request id, carrying a status.state field:

// 2. Server -> Client (initial result): task accepted
{"jsonrpc": "2.0", "id": 1,
 "result": {"id": "task-kyc-7f3a", "status": {"state": "submitted"}}}

// 3. Server -> Client (streamed): work has begun
{"jsonrpc": "2.0", "id": 1,
 "result": {"id": "task-kyc-7f3a",
  "status": {"state": "working"}, "final": false}}

Mid-task the server discovers the passport scan is missing, so it transitions to input-required and streams an agent message describing exactly what it needs. The client (or the human behind it) answers by sending a follow-up tasks/send on the same task id, which drives the machine back to working:

// 4. Server -> Client (streamed): more input is needed
{"jsonrpc": "2.0", "id": 1,
 "result": {"id": "task-kyc-7f3a",
  "status": {"state": "input-required",
   "message": {"role": "agent",
    "parts": [{"type": "text", "text": "Provide a passport scan for applicant 88412."}]}},
  "final": false}}

// 5. Client -> Server: supply the requested input on the same task id
{"jsonrpc": "2.0", "id": 2, "method": "tasks/send",
 "params": {"id": "task-kyc-7f3a",
  "message": {"role": "user",
   "parts": [{"type": "file", "file": {"name": "passport.png", "uri": "https://files.example.com/88412/passport.png"}}]}}}

With the passport in hand the server finishes, transitioning working to completed and attaching the result as an artifact. The final event sets final: true, which (per step 3 of Algorithm 27.3.1) tells the client to stop listening and release the handle:

// 6. Server -> Client (streamed, terminal): task done, artifact attached
{"jsonrpc": "2.0", "id": 1,
 "result": {"id": "task-kyc-7f3a",
  "status": {"state": "completed"},
  "artifacts": [{"name": "kyc_result",
    "parts": [{"type": "text", "text": "KYC PASS: identity verified, no sanctions match."}]}],
  "final": true}}

27.3.3 Federation and Discovery

A2A includes mechanisms for agent discovery. Agent Cards can be published to registries where other agents can search for capabilities. A supervisory agent that needs "document processing" capabilities can query a registry, discover agents that offer those skills, evaluate their descriptions and authentication requirements, and dynamically route tasks to the most appropriate agent. This federation model enables ecosystems of agents that can collaborate without being pre-configured to know about each other.

Security in A2A follows standard web patterns: OAuth 2.0 for authentication, TLS for transport security, and capability-based access control defined in the Agent Card. The protocol also supports audit logging of all inter-agent communication, which is essential for compliance-sensitive industries where every decision and data exchange must be traceable.

Exercises