How does Agent2Agent differ from MCP?
AI Architect
Key takeaways
- The A2A specification defines Agent Cards, task lifecycle objects and message methods for peer agent collaboration.
- The MCP specification defines JSON-RPC requests for tools, resources and prompts inside one host-controlled integration surface.
- A2A discovery starts from an Agent Card, commonly at `/.well-known/agent-card.json`, before any task is opened.
- An A2A task is a stateful remote work unit, while an MCP tool call is a capability invocation within the caller's runtime.
- Teams should default to MCP for internal tool wiring and add A2A only when the remote side is a separately owned agent service.
Agent2Agent is one of the more current protocol conversations in AI engineering, and much of the commentary frames it as a successor to MCP. The current specifications do not support that reading. The A2A docs describe a peer protocol for independent agents. The MCP spec describes a host-mediated integration layer for tools, resources and prompts.
My view is simple. Default to MCP until the thing on the other side is a real agent service with its own task state, auth rules and operators. Wrapping every internal workflow in A2A adds discovery and lifecycle machinery you probably do not need.
What does Agent2Agent standardise that MCP does not?
Agent2Agent standardises the boundary between one agent and another agent. The
current A2A docs describe independent, often opaque agents that discover each
other, negotiate interaction modes, exchange messages, and collaborate on a
shared task. The protocol definition then turns that into concrete methods such
as SendMessage, SendStreamingMessage, GetTask, CancelTask and task push
notification configuration. Those methods assume the remote side owns a task
lifecyle and may need more than one turn to finish the work.
MCP standardises a different surface. The MCP specification defines JSON-RPC communication between a host, its MCP clients and MCP servers, with server features exposed as tools, resources and prompts. That surface is a capability boundary between a host and the things it can use. A tool may be powerful, but the caller still owns the plan. That distinction is the durable finding here: A2A delegates work to another agent service, while MCP extends the current agent’s own reach.
How does Agent2Agent discovery work before a task starts?
A2A begins with discovery. The specification says A2A servers
must make an Agent Card available, and the common path is
https://{server_domain}/.well-known/agent-card.json. That card tells the
caller what the remote agent claims to be, which protocol bindings it supports,
which skills it exposes, and which authentication schemes it expects. The same
document may also advertise optional capabilities such as streaming, push
notifications and an authenticated extended card.
That is a heavier first contact than MCP because the remote side is a service
you may not control. The A2A docs also allow curated registries and direct
configuration, which matters in enterprise settings where a public well-known
URI is the wrong trust model. The practical consequence is that caching belongs
in the client from day one. The spec recommends Cache-Control and ETag, and
clients should revalidate rather than fetch the whole card on every run. If you
skip that work, protocol discovery becomes needless latency on every
delegation.
How does an Agent2Agent task differ from an MCP tool call?
The sharpest difference is state. In the A2A proto, a Task is the core unit
of action, with lifecycle states such as SUBMITTED, WORKING, COMPLETED,
FAILED, INPUT_REQUIRED and AUTH_REQUIRED. A caller can block on
SendMessage, stream progress with SendStreamingMessage, poll with GetTask,
or register push notifications. That is the contract you need when remote work
may span multiple steps, approvals or partial artifacts.
An MCP tool call is much smaller. Modern MCP uses self-contained JSON-RPC requests where the client negotiates version and capabilities per request, then invokes one tool, reads one resource, or loads one prompt. The host keeps control of orchestration, consent and retry policy. Even when the server is complex, the unit exposed to the model is still a capability call inside the current runtime. That is why cloud agent deployment and A2A fit naturally together: a delegated agent behaves more like a remote worker than like a local function.
An A2A delegation with internal MCP work behind it
Show as text
| # | From | To | Message |
|---|---|---|---|
| 1 | Agent A | Agent B | GET /.well-known/agent-card.json. Agent A learns skills, auth and bindings. |
| 2 | Agent A | Agent B | SendMessage. opens or continues a stateful task |
| 3 | Agent B | Agent A | status_update or message. may stream while Agent B uses MCP internally |
| 4 | Agent B | Agent A | artifact or completed task. final result of the delegated work |
When should a team use Agent2Agent instead of MCP?
Use MCP first when the other side is still your own integration problem. If you control the runtime, the approval flow, the credentials and the orchestration, an MCP tool or resource keeps the contract smaller and keeps policy in one place. This is still true when the capability is complicated. Complexity alone does not make something a peer agent. It may only mean you need a better tool description or a stricter execution boundary.
Use A2A when the other side is genuinely another agent service. Signs include a separate operator, a published skill catalog, its own task queue, remote auth requirements, or a need to return progress and artifacts over time. My opinion is that teams should be conservative here. If an internal service could be described honestly as “an API my agent calls”, forcing it through A2A is usually theatre. If the better sentence is “an agent I delegate work to”, A2A is probably the right contract, much like choosing between ADK and LangGraph depends on who owns the runtime burden.
How do Agent2Agent and MCP fit in one production system?
The clean production pattern is layered. An entry agent receives the user goal and decides whether another specialist agent should own a slice of work. If so, it discovers that agent through the Agent Card, opens or continues an A2A task, and tracks the task until it gets a completion state or an interruption that needs human input. Inside the remote agent, the implementation can stay private: it may call MCP tools, attach MCP resources, use direct APIs, or mix all three.
That is why the A2A docs call the remote side opaque. The caller needs a stable peer contract and a clean result surface. The right architecture is therefore A2A outside, MCP inside. Teams that blur the layers end up either publishing too much of their internal topology or hiding a remote workflow behind a tool call that cannot represent progress cleanly. The protocol stack is only simpler once the ownership boundary is made explicit.
Where A2A stops and MCP starts
Show as text
| # | Layer | Note |
|---|---|---|
| 1 | Client agent | Owns the user goal and delegation policy. |
| 2 | A2A task and Agent Card | Discovers peers and tracks delegated work. |
| · | protocol boundary (breakpoint) | |
| 3 | MCP client inside remote agent | Chooses tools, resources and prompts. |
| 4 | MCP servers and external APIs | Hold the data and side effects. |
Do this
Choose between Agent2Agent and MCP without protocol cargo culting
Start from the ownership boundary, because the wrong protocol choice usually comes from pretending a tool is an agent or an agent is a tool.
Identify who owns the logic on the other side
If the remote side has its own planner, memory, operators or SLA, treat it as an agent boundary candidate. If it is a capability inside your runtime, keep it in the tool layer.
Model local capabilities as MCP first
Tools, resources and prompts are the smaller contract. They keep routing, consent and policy in the calling host rather than creating an unnecessary remote task protocol.
Add Agent2Agent only for delegated work
Use A2A when you need skill discovery, multi-turn task progress, remote authentication rules or artifact exchange with a separately owned agent service.
Publish an Agent Card that says exactly what is supported
Declare the binding, protocol version, skills and optional features such as streaming or push notifications. If details are sensitive, move them to an authenticated extended Agent Card.
Decide the task completion path before integration
Pick between blocking `SendMessage`, `SendStreamingMessage`, polling with `GetTask`, or webhook push notifications. The choice affects client complexity more than the choice of SDK.
Log task ids separately from tool calls
Keep A2A task ids, context ids and remote agent identity distinct from internal MCP tool traces. Without that split, a delegated failure looks like a local tool fault.
Frequently asked questions
- Is Agent2Agent a replacement for MCP?
- No. The current A2A documentation says the two are complementary. A2A covers agent-to-agent communication. MCP covers agent-to-tool communication. A remote A2A agent may still use MCP internally to reach its own tools and data.
- Do I need an Agent Card for every internal service?
- Usually no. An Agent Card makes sense when the service is being presented as an autonomous agent with declared skills, auth requirements and protocol bindings. A plain internal API or tool adapter is usually a better fit for MCP or direct application code.
- When should I use SendStreamingMessage instead of polling GetTask?
- Use streaming when the caller benefits from partial progress, intermediate messages or artifact chunks. Use blocking or polling when the task is short, the network path is simple, or your client only needs the final state.
- Can one system expose both Agent2Agent and MCP?
- Yes. That is often the clean design. The system can expose an A2A surface to peer agents while its own runtime uses MCP to reach tools, resources and prompts behind that boundary.
- Does Agent2Agent require public discovery?
- No. The spec allows well-known discovery, curated registries and direct configuration. Public `/.well-known/agent-card.json` is only one discovery path. Private deployments can rely on registries or direct configuration instead.