A2A (agent-to-agent) is the open protocol for one AI agent to discover, converse with, and hand work to another agent — including an agent owned by a different team or vendor. Where MCP standardizes how an agent calls tools, A2A standardizes how agents talk to each other: an Agent Card describes what the remote agent does, a Task carries the work, and Messages stream progress back. If you run a communications stack, the question is not "A2A or MCP?" — it is how the two compose. This explainer covers what A2A actually specifies, how it relates to MCP, and where intra-account multi-agent squads (the routing layer we ship in Devotel Orbit) fit in the picture.
What A2A specifies
The protocol has three core objects, and most of the spec is their lifecycle:
- Agent Card. A JSON document the serving agent publishes (conventionally at
/.well-known/agent-card.json) describing its name, capabilities, supported interaction modes, and the authentication schemes it accepts. A client agent reads the card before it talks — no guessing, no hard-coded endpoint assumptions. - Task. A stateful unit of work with an id and a lifecycle (submitted, working, input-required, completed, failed, canceled). Long-running work is a Task, not a chat message; the server pushes state updates until the task terminates or produces artifacts.
- Message and Artifact. Messages carry the conversational content (role-tagged parts: text, files, structured data). Artifacts are the durable outputs of a Task — a generated document, a compiled report — separate from the conversational transcript.
Transports are HTTP with JSON-RPC, with optional Server-Sent Events for streaming tasks and webhook push notifications for long-haul updates. The important property: agents interact as peers over a stable contract, not via bespoke vendor SDKs.
Why the industry needed a second protocol beside MCP
MCP (Model Context Protocol) solved agent-to-tool: a client enumerates a server as typed tools (tools/list, tools/call) with input schemas. That is exactly the boundary it should own — tool surfaces are capability descriptions, and tool calls are deterministic invocations.
Agent-to-agent is a different problem shape. The "other side" is a peer agent with its own model, memory, and multi-turn state, not a deterministic function you invoke once. It needs discovery (Agent Cards), multi-turn state (Tasks, not single calls), negotiated content (Message parts, not fixed schemas), and a conversation-vs-work distinction (Messages vs Artifacts). Retrofitting that into tools/call would have frozen an interaction model that cares about sessions, streaming, and nested delegation into a one-shot invocation.
The two protocols compose cleanly: an A2A client agent orchestrates a peer-to-peer Task; inside its task handler it calls MCP tools to act on systems (query a CRM, send a message, charge a payment). A2A governs the conversation; MCP governs the actions. The Devotel Orbit platform ships the MCP side of that pair natively — a hosted MCP server that exposes the tenant's communications surface as typed tools — so an A2A-speaking peer agent has an action layer to call once the conversation starts.
Where intra-account squads fit — the layer A2A does not specify
Neither A2A nor MCP answers "which of my own agents handles this inbound turn?" That is a separate, intra-tenant orchestration question. Orbit's agent squads solve it the way an IVR front door solves routing: one classifier reads the inbound message, resolves an intent label, and hands the turn to whichever specialist owns it — all inside one conversation record.
Squads are deliberately internal: no Agent Card is published, no cross-organization trust boundary is crossed. The classifier and specialists share the tenant's knowledge bases, per-contact memory, model presets, and cost caps. A2A is the inter-organization contract; squads are the intra-organization router; MCP is the tool surface. You can, today, compose all three: an external partner agent reaches you over A2A, your classifier routes internally, and the chosen specialist executes with MCP tools.
A worked end-to-end example
Imagine a logistics partner's agent needs to escalate a delayed-shipment case to your support organization.
- Discovery. The partner agent reads your serving agent's Agent Card, confirms it supports
message/sendwith streaming, and authenticates per the card's security schemes. - Task open. It opens a Task titled "escalate shipment 8842 for contact ct_9182" and streams a Message with the case context.
- Intra-account routing. Your A2A-facing endpoint hands the Message to the squad classifier; the classifier returns
shipping-delay, and the router hands the turn to the Logistics specialist. - Action via MCP. The Logistics specialist calls MCP tools — lookup the contact, query the shipment, send the customer a WhatsApp status update — and emits an Artifact (the resolution summary) back into the Task.
- Completion. The Task reaches a terminal state; the partner agent receives the Artifact and updates its own case record.
Every layer of that flow is a named protocol shape: discovery and work over A2A, routing over the squad, action over MCP. Nothing has to infer a bespoke API.
What to look for when adopting A2A
Because the protocol is young, a pragmatic adoption checklist matters more than the spec's existence:
- Card hygiene. Publish one canonical Agent Card and keep it versioned. A stale card that advertises a capability you turned off is worse than none.
- Task timeouts. Decide how long a Task may stay in
workingbefore you fail it, and push state updates on a schedule, not at termination. - Message content types. Constrain the part types you accept (text, structured JSON, file references) — arbitrary bytes make moderation impossible.
- Authentication scope. Treat the peer's credential as narrowly as a tool credential: a partner agent with
shipping-delayintent should not be able to open billing work. The same scoped-credential principle Orbit applies at the MCP token-exchange boundary applies at the A2A boundary. - Fallback for unmatched intent. A well-formed A2A Task can still land on no specialist; without a fallback agent the turn stops at the classifier. Squads enforce the fallback explicitly.
Frequently asked questions
Is A2A a replacement for MCP?
No. MCP standardizes agent-to-tool invocation; A2A standardizes agent-to-agent conversation. A peer agent uses A2A to hold the conversation and MCP to execute actions, and Orbit's hosted MCP server is the action layer a peer ends up calling.
Does Orbit serve an A2A endpoint today?
Orbit's shipped agent-interop surface is the MCP server with scoped OAuth credentials, plus intra-account squads for routing. A2A describes how a cross-organization lane would slot in — the Agent Card, Task, and Message shapes — without changing the squad or MCP layers you already run.
Why not run agent-to-agent over plain REST?
Plain REST carries the bytes but not the interaction model: no discovery card, no lifecycle for long work, no distinction between chat content and produced artifacts. A2A standardizes the parts everyone re-implements badly the second time.
How should I choose between a squad and an A2A peer?
Squads when both agents are yours and share tenant state (memory, knowledge bases, cost caps). A2A when the other agent belongs to a partner or vendor and needs an explicit trust boundary. The two happily chain: an A2A front door handing to a squad classifier.
What stops a partner agent from drifting into dangerous work?
The same three layers that gate tool clients: the peer authenticates with a scoped credential, the squad classifier resolves its intent to a bounded specialist, and the specialist only calls tools its credential was scoped to hold. A2A does not add authority; it adds a conversation shape.
The takeaway
MCP settled how agents touch tools; A2A is settling how they touch each other. For a communications platform the two are complements, not rivals — and the third layer, intra-account routing, stays a platform-level concern. Devotel Orbit ships MCP and squads today; an A2A-speaking partner lane lands on the same routing and action layers without re-architecting either. For the MCP layer, see MCP for communications: what the Orbit MCP server enables; for the routing layer, see Agent squads — multi-agent orchestration for one conversation.