Agent-to-Agent Protocol (A2A)

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

Pip, Diplomatically Networked AI Agent

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 agents.

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"
 }
}

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.

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