What is the A2A protocol?
Imagine you run a team of AI agents: a research agent that scours the web, a coding agent that writes pull requests, a data analyst that crunches spreadsheets, and a customer support agent that answers tickets. Each agent is built on a different framework, from a different vendor, running in a different environment. Now imagine you want the research agent to hand off findings to the coding agent, or the support agent to escalate a billing question to the data analyst. Without a common language, those agents are islands: they cannot talk to each other.
That is the problem the Agent2Agent (A2A) protocol solves.
A2A is an open communication standard that lets AI agents discover each other, exchange capabilities, delegate tasks, and coordinate work, regardless of which framework they were built on or which vendor provides them. Launched by Google in April 2025 with over 50 technology partners, and now hosted by the Linux Foundation as an open-source project, A2A is the missing piece that turns a collection of individual agents into a genuine agent team.
Why A2A matters now
The AI agent landscape has crossed a threshold. Gartner reports that 80 percent of enterprise applications shipped or updated in Q1 2026 now embed at least one AI agent. PwC's 2026 AI Agent Survey finds that 79 percent of companies say AI agents are already being adopted, and 66 percent of those report measurable productivity gains.
But here is the catch: most of those agents are siloed. A Salesforce agent cannot talk to a ServiceNow agent. A custom LangChain agent cannot delegate to a vendor-built agent running on Vertex AI. Teams are building agent after agent, each powerful in isolation, and then discovering that coordination between them requires custom integrations, brittle API contracts, and months of engineering work.
A2A changes that. It provides a standard, open protocol for agent-to-agent communication, analogous to what HTTP did for web services or what SMTP did for email. Before HTTP, every web client and server needed custom integration. After HTTP, any browser could talk to any server. A2A aims to do the same for AI agents.
How the A2A protocol works
A2A is built on a few core concepts that are simple to understand but powerful in combination.
Agent Cards: the agent's business card
Every A2A-compatible agent publishes an Agent Card, a JSON document hosted at a well-known endpoint that describes what the agent can do. The card includes:
- The agent's name and description
- Its capabilities: what kinds of tasks it can handle
- Its input and output schemas: what data formats it accepts and returns
- Authentication requirements: OAuth 2.0 scopes or API key expectations
- Its endpoint URL: where to send task requests
When an orchestrator agent needs to delegate a task, it first discovers available agents by reading their Agent Cards. It matches the task requirements against the capabilities declared in each card, then routes the work to the best-fit agent. This discovery mechanism is what makes A2A suitable for enterprise environments where new specialized agents are deployed regularly: you add an agent, publish its card, and the rest of the system discovers it automatically.
Task lifecycle: request, execute, return
A2A communication follows a structured task lifecycle. One agent (the client) sends a task request to another agent (the server). The task includes:
- A task ID for tracking
- The task description and parameters
- The expected output format
The receiving agent can respond in three modes:
- Synchronous: The agent processes the task immediately and returns the result in the same HTTP response. Best for short, deterministic tasks.
- Streaming: The agent returns results progressively as they become available, using server-sent events. Best for tasks where the user wants to see progress in real time.
- Asynchronous: The agent acknowledges the task, processes it in the background, and notifies the client when complete. Best for long-running or batch tasks.
This flexibility means A2A works for everything from a quick fact-check delegation (sub-second synchronous) to a multi-hour research report (asynchronous with notification).
The A2A communication flow
Here is a simplified view of a typical A2A interaction:
- An orchestrator agent receives a complex user request: "Analyze our Q2 sales data, identify the top three underperforming regions, and draft a strategy memo for each."
- The orchestrator reads the Agent Cards of available agents: a data analyst agent, a strategy writer agent, and a formatting agent.
- The orchestrator delegates the data analysis task to the data analyst agent via A2A, specifying the input (sales database connection) and expected output (a structured report of underperforming regions).
- The data analyst agent processes the request using its own tools (MCP-connected databases, statistical libraries) and returns the structured report.
- The orchestrator delegates the strategy writing task to the strategy writer agent, passing the analysis as input.
- The strategy writer agent drafts three memos and returns them.
- The orchestrator delegates the formatting task to the formatting agent.
- The orchestrator assembles the final response for the user.
At no point did any agent need to know the internal workings of any other agent. They communicated entirely through A2A's structured task interface.
A2A vs MCP: two protocols, one stack
One of the most common questions about A2A is how it relates to the Model Context Protocol (MCP), the other major open protocol in the agent ecosystem. The distinction is clean:
| MCP (Model Context Protocol) | A2A (Agent2Agent) | |
|---|---|---|
| Connects | Agent to tools and data | Agent to agent |
| Purpose | Give agents access to external resources | Enable agents to delegate work to each other |
| Analogy | A universal USB port for tools | A universal language for inter-agent delegation |
| Created by | Anthropic | |
| Launched | November 2024 | April 2025 |
The two protocols are designed to work together, not compete. An A2A orchestrator delegates tasks to specialist agents. Each specialist agent uses MCP to connect to the tools and data sources it needs to execute those tasks. The protocol boundary is clean: inter-agent communication is A2A, tool invocation is MCP.
Think of it this way: MCP is how an agent reaches out to the world. A2A is how an agent reaches out to another agent.
A2A in the broader protocol ecosystem
A2A is not the only protocol in the agent communication space. IBM introduced the Agent Communication Protocol (ACP) as part of its BeeAI platform. The Agent Protocol Working Group at the Linux Foundation is working on broader standardization. Several frameworks (LangGraph, CrewAI, AutoGen) have their own internal coordination mechanisms.
What makes A2A stand out is the breadth of its industry backing. At launch, Google brought together over 50 partners from across the enterprise software landscape: Atlassian, Box, Cohere, Intuit, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UKG, and Workday among the technology partners, plus Accenture, BCG, Capgemini, Cognizant, Deloitte, HCLTech, Infosys, KPMG, McKinsey, PwC, TCS, and Wipro among the service providers.
This level of cross-industry commitment signals that A2A is not a single-vendor play. It is an attempt to build the shared infrastructure that the entire agent ecosystem needs.
When to use A2A and when to keep it simple
A2A is powerful, but it adds complexity. Not every agent setup needs it. Here is a practical guide:
Use A2A when:
- You have agents built on different frameworks (LangChain agent, CrewAI agent, custom agent) that need to coordinate
- You use agents from multiple vendors (Salesforce agent, ServiceNow agent, custom internal agent)
- You deploy new specialized agents regularly and need automatic discovery
- You want your agent ecosystem to survive vendor changes without rewriting integration code
Skip A2A when:
- You only run a single agent or a small team of agents all built on the same framework
- Your framework's internal coordination (LangGraph supervisor, CrewAI sequential process) is sufficient
- The overhead of maintaining an A2A infrastructure outweighs the coordination benefit
The rule of thumb: start simple. When your agent team grows to the point where coordination friction becomes the bottleneck, A2A is the right tool.
Human approval and the blast radius
An agent that can delegate tasks to other agents is powerful. It is also dangerous. A2A does not include built-in human-in-the-loop approval, which means every delegation carries a blast radius. If an orchestrator agent delegates a high-stakes action (sending a customer email, modifying a production database, approving a purchase order) to a specialist agent, and that specialist agent executes without human review, the error propagates instantly. The solution is not to avoid A2A. It is to layer human approval gates at the points where delegation crosses a risk threshold. In an Upchat team, you can configure role agents to require explicit human approval before executing high-blast actions, regardless of whether the request came from a user directly or from another agent via A2A-style delegation.
This is where the concept of team design becomes critical. An agent team with A2A-style delegation is not a fire-and-forget system. It is a workplace where agents have defined roles, clear scopes, and escalation paths. A support agent can delegate a billing question to a finance agent. A finance agent should not be able to delegate a wire transfer without human approval. The protocol enables the communication; the team design enforces the guardrails.
Team patterns for agent-to-agent collaboration
When you design an agent team with A2A-style delegation, several patterns emerge that mirror how human teams work:
The specialist pool
You maintain a pool of specialist agents (researcher, writer, coder, analyst, reviewer) and an orchestrator agent that routes incoming work to the right specialist. The orchestrator reads Agent Cards, matches tasks to capabilities, and assembles results. This is the most common pattern and works well for knowledge work.
The sequential pipeline
Tasks flow through a fixed sequence of agents: research, then draft, then review, then publish. Each agent in the chain receives the output of the previous agent and adds its own contribution. The pipeline is deterministic and easy to debug, but less flexible than the specialist pool.
The reviewer pattern
Every output that crosses a risk threshold goes through a reviewer agent before execution. The reviewer agent checks for policy compliance, accuracy, and appropriateness. This pattern is especially useful for customer-facing outputs, code deployments, and financial actions.
The escalation chain
When an agent encounters a task it cannot handle, it escalates to a more capable agent. A tier-1 support agent handles common questions and escalates complex cases to a tier-2 specialist. The escalation chain is a natural fit for customer service, IT operations, and any domain with a clear complexity gradient.
These patterns are not mutually exclusive. A real agent team often combines several of them: a specialist pool for routine work, a reviewer pattern for high-stakes outputs, and an escalation chain for edge cases.
Start this week: building your first agent team
If you want to experiment with agent-to-agent collaboration, here is a practical starting point:
Step 1: Define two agents with clear boundaries. Create a research agent that can search the web and summarize findings, and a writing agent that can draft documents from structured briefs. Give each agent a clear, non-overlapping role.
Step 2: Define the handoff contract. Decide what format the research agent's output should take so the writing agent can consume it without additional parsing. A simple structured brief (topic, key findings, sources, target audience) works well.
Step 3: Add human approval at the right point. Before the writing agent publishes anything externally, route the draft through a human reviewer. This is the simplest form of human-in-the-loop and prevents the most common failure mode: agents producing confident-looking but incorrect content.
Step 4: Observe and iterate. Track how often the handoff succeeds, how often the human reviewer needs to correct the output, and where the pipeline breaks. Use those observations to refine the agent instructions, the handoff contract, and the approval placement.
Step 5: Scale the pattern. Once the two-agent pipeline works reliably, add a third agent (a fact-checker, a code reviewer, a data analyst) and repeat the process. The pattern scales: clear roles, structured handoffs, human approval at risk points.
Where Upchat fits
A2A is a protocol standard. Upchat is a platform where you put that standard into practice. In Upchat, you create role agents: a content writer, a senior developer, a QA lead, a support specialist. Each agent has a defined role, connected tools, and configurable permissions. You can share those agents with your team as "AI employees" that anyone can task.
When you design an Upchat team with A2A-style delegation, the platform handles the protocol-layer concerns so you can focus on the team design: which roles do you need? What are the handoff contracts? Where do human approvals go? What is the blast radius of each delegation?
The result is not a chatbot. It is a team of specialized agents that work together, with humans in the loop at the right moments, on real work.
If you are ready to build your first agent team, start by creating your first role agents on Upchat. Define their roles, connect their tools, and invite your team to collaborate with them. No waitlists, no infrastructure setup, just agents that work together.
Closing thoughts
A2A is one of those rare protocols that arrives at exactly the right moment. The agent ecosystem has reached the point where individual agents are powerful enough to be useful, but the coordination layer between them is still held together with custom integrations and brittle API contracts. A2A provides the standard that lets the ecosystem grow beyond single-agent demos into genuine multi-agent teams.
The organizations that pull ahead in the next two years will not be the ones with the most agents. They will be the ones whose agents know exactly where their own job ends and the next one begins. A2A is the protocol that makes that boundary explicit.
Explore more about building AI agent teams:
