Your AI setup probably already runs more than one agent. A research thread in one tab, a coding agent in another, maybe a scheduling assistant somewhere else. Right now, most of that work still routes through you. You copy an answer out of one chat and paste it into the next. The agent to agent protocol, known as A2A, exists to close that gap by giving one AI agent a standard way to hand a task straight to another agent, no human copy-paste required. If you have already read about MCP and assumed it covers this too, it doesn’t. MCP connects a single agent to your tools and data. A2A is the separate, newer protocol built for agents delegating work to each other.
What this post covers: What the agent to agent protocol (A2A) actually is, and the exact line between it and MCP. You’ll get a side-by-side comparison, a real example of one agent handing a job to another using both protocols at once, and where this is heading as more of the AI stack starts running agent-to-agent instead of human-to-agent.
Table of Contents
What Is the Agent-to-Agent Protocol, in One Sentence
The agent to agent protocol is an open standard that lets one AI agent discover what another agent can do, then hand it a task directly, without a person relaying the message in between.
Google introduced A2A in April 2025 and later moved its governance to the Linux Foundation, where it now sits as its own hosted project rather than a single company’s side effort. The pitch is narrower than it sounds at first. A2A doesn’t try to make any individual agent smarter. It gives agents a shared way to say what they can do, accept a job, and report back, the same way a company directory tells you who to call for a given task instead of you guessing which extension to dial.
That distinction matters once you’re running more than one agent for real work. A planner agent that can only talk to you is limited to whatever you’re willing to relay by hand. A planner agent that can talk to a writer agent, a research agent, and a scheduling agent directly can actually delegate. A2A is the plumbing that makes that delegation possible without a custom integration between every pair of agents you happen to be running.
MCP vs A2A: Two Protocols, Two Different Jobs
MCP and A2A solve different problems, and the confusion between them usually comes down to one word: connect. Both protocols connect things. They just connect different things.
| MCP | A2A | |
|---|---|---|
| Built by | Anthropic, November 2024 | Google, April 2025 |
| Connects | One agent to tools and data | One agent to another agent |
| Direction | Vertical, agent down to a tool | Horizontal, agent across to another agent |
| Core unit | A server exposing tools and resources | An Agent Card describing capabilities, and a Task |
| Typical use | An agent reading a database or calling an API | A planner agent delegating a job to a specialist agent |
| Governed by | Agentic AI Foundation, under the Linux Foundation | A2A project, under the Linux Foundation |
Neither protocol replaces the other, and neither one is optional if you’re building anything past a single chatbot. MCP is what lets an individual agent actually do useful work once it has a task. A2A is what lets that task arrive in the first place, from another agent instead of from you.
How A2A Actually Works: Agent Cards and Task Handoffs
A2A runs on two ideas: an Agent Card that describes what an agent offers, and a Task that tracks a job from request to result.
An Agent Card is a small JSON document an agent publishes, usually at a predictable URL, listing what it can do, what input it expects, and how to reach it. Think of it as a business card with a job description attached. Before one agent can delegate to another, it fetches that card to check whether the other agent can actually do what’s being asked.
Once a client agent decides to delegate, it opens a Task. The remote agent works the job and moves the task through a small set of states: submitted, working, and then either completed, input-required if it needs more from the client mid-task, or failed. The client can poll for updates or receive them as they happen, and the finished work comes back as one or more artifacts (text, a file, structured data) rather than a single plain-text reply.
None of this requires the two agents to share a vendor, a model, or even a codebase. An agent built on Claude can hand a task to an agent built on a completely different model, as long as both speak A2A. That’s the same interoperability promise MCP made for tools, applied one layer up, to agents themselves.
A Real Example: A Planner Agent Hands a Job to a Writer Agent
Here’s where MCP and A2A actually meet in the same workflow, not just on a comparison chart.
Say you’re running a content pipeline with two agents. A planner agent decides what should get written next, based on a content calendar. A separate writer agent specializes in turning a topic into a finished draft. The planner doesn’t write the post itself, and it doesn’t need to know how the writer agent does its job internally. It just needs to hand the work off and get a result back.
Using A2A, the planner fetches the writer agent’s Agent Card, confirms it accepts a “draft blog post” task, and opens a Task with the topic, primary keyword, and deadline. The writer agent picks up the task and, to actually do the work, reaches into an MCP server to pull the relevant content calendar entry, or query a research tool for supporting data. That’s MCP doing its normal job, one agent connecting to a tool. Once the draft is done, the writer agent returns it as an artifact through the same A2A task, and the planner marks the job complete.
From the planner’s point of view, it delegated a task and got a finished piece back. Underneath, two different protocols did two different jobs to make that happen: A2A carried the handoff between agents, MCP carried the agent’s connection to its tools. Neither one could have done the other’s part. For more on the tool-connection half of this pattern, the MCP explainer breaks down the host-client-server model this writer agent is running on.
Why MCP and A2A Need Each Other
Treat A2A and MCP as competing standards and you’ll end up picking the wrong one for half your problems. Treat them as two layers of the same stack, and the choice mostly makes itself.
I think about this the same way I think about the rest of an AI orchestration setup: the value isn’t any single tool, it’s how cleanly the pieces snap together. A single agent with great MCP access can still only do one job at a time. A team of agents with A2A can split a bigger job into pieces, but only if each of those agents actually has something useful to do once it receives its piece, which is exactly what MCP gives it. Skip A2A and you’re stuck relaying tasks between agents by hand. Skip MCP and your agents can talk to each other perfectly well while having nothing real to do.
For a deeper look at what changes once you’re running more than one agent instead of one, Multi-Agent Orchestration: Run AI Like a Small Team covers the coordination side of this in more depth than one blog post on a single protocol can.
Where This Is Heading: The Agentic Web
A2A is a year and a half old and already past the point of being a Google side project. By April 2026, the Linux Foundation reported more than 150 organizations supporting the standard, over 22,000 GitHub stars on the spec, and production SDKs in five languages, with deep integration across Google, Microsoft, and AWS.
The next layer up is discovery at scale, and that’s where MIT’s Project NANDA comes in. NANDA, led by Ramesh Raskar’s team, builds on top of both MCP and A2A rather than replacing them, adding a registry layer so agents can find and verify each other across organizations instead of only within a system someone configured by hand. MIT’s own framing for this is direct: protocols like MCP and A2A are laying the base for what they call the agentic web, an internet where agents, not just people, are doing a growing share of the requesting, discovering, and handing off.
That’s a bigger claim than any one team needs to plan around today. What’s already true, and useful right now, is narrower: if you’re building or using more than one AI agent, you’re going to run into a moment where one needs to hand a task to another. A2A is the standard way that’s supposed to happen, and it’s worth knowing before you end up building your own version of it by accident.
Key Takeaways
- The agent to agent protocol (A2A) is an open standard, introduced by Google in April 2025, that lets one AI agent discover and delegate a task to another agent directly.
- A2A is horizontal (agent to agent). MCP is vertical (agent to tool). They solve different layers of the same problem and are not substitutes for each other.
- A2A runs on two core pieces: the Agent Card, which describes what an agent can do, and the Task, which tracks a job from submission through completion.
- A task moves through defined states, including submitted, working, input-required, completed, and failed, and returns results as artifacts rather than plain text.
- In a real pipeline, a planner agent can use A2A to hand a job to a writer agent, which then uses MCP to pull the data it needs to actually do the work.
- Governance for A2A moved to the Linux Foundation, which reported over 150 supporting organizations and 22,000+ GitHub stars on the spec by April 2026.
- MIT’s Project NANDA builds on both MCP and A2A to add agent discovery and verification, part of what researchers are calling the agentic web.
Frequently Asked Questions
What is the agent to agent protocol used for? It lets one AI agent discover what another agent can do and hand it a task directly, without a person relaying the request between them. It’s used for multi-agent pipelines where different agents specialize in different jobs.
Is A2A a replacement for MCP? No. MCP connects an agent to tools and data. A2A connects one agent to another agent. Most real multi-agent systems need both running at the same time, not one instead of the other.
Who created A2A and when? Google introduced A2A in April 2025. Its governance later moved to the Linux Foundation, which now hosts it as an independent, vendor-neutral project.
What is an Agent Card in A2A? It’s a small JSON document an agent publishes describing what it can do, what input it needs, and how to reach it. Other agents fetch it before deciding whether to delegate a task.
Do I need A2A if I’m only running one AI agent? Not yet. A2A matters once you have two or more agents that need to hand work to each other. A single agent connecting to your tools is still an MCP problem, not an A2A one.
Harshal Saraf is a Creative Director and AI Workflow Consultant based in Indore, India. Under his practice ByHarshal, he sets up AI workflows for founders, agencies, and brands across India. Where Creative Direction Meets AI Orchestration. He has led creative direction for brands and small and medium scale B2B businesses, and currently works as Creative Director and AI Strategist at Square Root SEO. He writes Oh, So AI, a Tuesday and Friday newsletter on AI tools, workflows, and productivity for founders and creatives.
