The surprising part of A2A vs MCP is that the protocols are the easy side. Both specifications read in an afternoon. Most failures come from boundaries: wrapping a deterministic API as an agent, granting tools wider rights than the requesting user, and treating a multi-minute delegation as a quick request.
Part 2 of a series, after A2A vs MCP: Which Agent Protocol You Need.
Two protocols, two different problems
The comparison only makes sense once you stop treating A2A and MCP as rivals. The Model Context Protocol (MCP) is how one agent reaches its tools, data and prompts. The Agent2Agent protocol (A2A) is how separate agents, often from different teams on different stacks, find each other and hand off work. They solve different problems at different layers, and most real systems end up using both.
A2A vs MCP: The Direction Tells You the Layer
A2A vs MCP is a difference in direction, not a rivalry. MCP, the Model Context Protocol introduced by Anthropic November 2024, is how one agent reaches its tools, data and prompts. A2A, the Agent2Agent protocol announced by Google in April 2025 and now stewarded by the Linux Foundation, is how separate agents find each other and hand off work.
The video's framing is a useful shorthand: MCP runs down from an agent to what it uses, while A2A runs across between agents that each reason for themselves. One exchange over MCP is typically a single call you control at both ends. One exchange over A2A is a task that moves through stages, often with another team on a different stack.
Neither protocol replaces the other, and the source material says most real systems end up using both. The layer you sit at decides which one you need, and picking the wrong layer is where most of the reported pain begins.
The two layers differ in almost every practical dimension:
| Dimension | MCP (down) | A2A (across) |
|---|---|---|
| Direction | Agent to its tools, data and prompts | Agent to another agent |
| Typical exchange | One call, both ends usually yours | A task moving through states |
| Far side reasons? | No, it executes operations | Yes, it plans its own steps |
| Who controls it | Usually you | Often another team on another stack |
| Standard failure | Catch-all tool called with wrong arguments | Delegation treated as a quick call |
| Main risk | Tools with more rights than the requesting user | Promises to other teams that cannot be kept |
Both specifications are short enough to read directly. The MCP specification and the A2A protocol documentation are the primary references; second-hand summaries tend to blur the line the video is drawing.
Does the Far Side Reason? The Only Test That Matters
Whether the far side reasons for itself decides almost every A2A vs MCP question. A database, an API and a file store run operations; none of them plan their own steps, so they are capabilities, not peers. They belong behind a tool interface with defined inputs.
Ownership does not change that shape. A tool another team runs is still a tool. If the far side executes deterministic work and returns a result, wrapping it as an agent adds latency and variance without adding decisions. The video calls wrapping a plain API as an agent the commonest mistake.
An open-ended job for another team's agent is different. That agent plans its own steps, so you hand over a task instead of calling a function. Long-running work that reports progress, or stops so a person can decide, also belongs on the A2A side.
The two-question summary the video gives is reasoning plus control: does the far side reason, and do you control it? Your own database fails the first question. A colleague's agent passes both. A partner's agent passes the first and fails the second.
Two concrete cases make the split clear:
- One model wired by hand into fifteen internal systems is exactly the sprawl MCP exists to collapse. Fifteen integrations become one protocol surface.
- A marketplace of agents run by different operators needs those agents to advertise and be found across organisations. That is A2A.
Where Each Protocol Actually Gets Used
MCP's job is to give a model a stable way to call external tools and read data, and the MCP overview describes that vertical relationship directly. A2A's job is to let agents advertise what they do, be found by other agents, and receive delegated work, which the A2A project on GitHub documents as cross-agent collaboration.
The decision rarely comes out as one or the other. A customer-facing agent that looks up orders through MCP and then hands a refund dispute to a partner's agent over A2A is a normal shape, not an exotic one.
The choice often reduces to whether the integration is inward-facing or outward-facing. Internal systems, databases and internal APIs are usually MCP territory. Cross-organisation agents, partner services and agent marketplaces are A2A territory. When a system is both, split it: deterministic operations behind MCP, delegated open-ended work over A2A.
Six Boundary Rules Before You Ship Either Protocol
Adoption is straightforward for both protocols, and so is adopting them badly. The video's six steps focus on the boundaries around the messages rather than the message formats themselves, because that is where the reported failures cluster.
Before those steps, name the layer for every integration: does it decide anything, or just run an operation?
- Classify each integration by whether it reasons. Wrapping a deterministic API as an agent trades speed and predictability for latency and variance. Write the classification down before any code.
2. Expose a few precise tools, each with strictly defined inputs and a description of when to use it. The video's claim is that ten precise tools beat forty vague ones, because model selection degrades as the list grows and blurs.
3. Authorise every tool call as the end user, never a shared service account with wider rights. Otherwise a plain-language request can reach something the requester was never allowed to do.
4. Publish an honest agent card: what your agent does, what it needs, and what it cannot do. Other agents choose yours from that card alone, so an overpromise surfaces far from its cause.
5. Model a delegation as a task with states, not a call and a reply. It may pause for a person, and work between agents routinely takes minutes. Treat it as a quick call and you manufacture your own timeouts, retries and duplicated work.
6. Pass one trace through every tool call and every delegation. From separate logs, a failure across agents is almost impossible to diagnose; one connected trace shows the step that broke.
The Failure Pattern Behind All Six Rules
Each rule in the previous section removes a failure that looks like a protocol problem but is a layer problem. The video lists the same symptoms repeatedly: an agent wrapped around something that never needed to reason, a catch-all tool called with the wrong arguments, tools holding more rights than the person behind them.
The remaining symptoms follow the same pattern. Delegation treated as a quick call produces timeouts the caller created by assumption. Promises to other teams that cannot be kept produce failures blamed on the protocol. Missing traces leave nobody able to see where a cross-agent request broke.
This is why summaries are risky for this pair. The line between a tool and a peer is exactly what a compressed explanation tends to flatten, and the flattening is what leads teams to pick the wrong layer. Reading the A2A specification alongside the MCP specification is a few hours of work for a decision that shapes the architecture.
Treat both protocols as young. The video, published in September 2026, says as much, and it came out just over a year after A2A was announced. Design for change at the edges where other teams connect, and keep the deterministic parts behind tool interfaces that survive protocol revisions.
Frequently Asked Questions
- Is A2A a replacement for MCP? No. MCP connects one agent to its tools and data, while A2A connects agents that reason for themselves. The source material says most real systems use both, because they operate at different layers.
- When should an internal API be exposed as an MCP tool rather than an agent? When the far side only executes operations and returns a result. A database or REST API does not plan steps, so wrapping it as an agent adds latency and variance without adding decisions.
- Why model an A2A delegation as a task rather than a request? Because delegated work can take minutes and may pause for a human decision. A task with states lets progress be reported; a request-and-reply model produces timeouts, retries and duplicated work.
- What is an agent card? An agent card is the published description of what an agent does, what it needs and what it cannot do. Other agents select it from that card alone, which is why overpromising pushes failures far from their cause.
- Who stewards A2A now? Google announced A2A in April 2025 and transferred the project to the Linux Foundation in June 2025. The A2A announcement is the primary record of the original launch.
Turning a Five-Minute Explainer Into a Publishable Article
The hard part of this topic is keeping two protocols at the right layer, and the same discipline applies to writing about them. A spoken explanation carries the boundary once, in order, with the caveats attached. A written article has to hold that line across headings, tables and FAQ answers without letting a summary flatten it. This article was built from a five-minute video explainer, and the table above was added precisely because prose alone kept blurring the MCP-down versus A2A-across distinction.
If you already have knowledge like this inside a YouTube video, an interview or a recorded walkthrough, Skalablog can carry it into written form. Paste the video URL, let the transcript come through, and generate a draft you can edit and check against primary sources before publishing.
Gustavo dev doido made a similar point about how the layer you choose matters before any code is written. If you have comparable knowledge sitting in a video, the same path applies.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits