Quick answer: The Agent2Agent (A2A) protocol is the open standard — originally published by Google and now stewarded with the broader agent community — for one AI agent delegating work to another over HTTP. One agent publishes a signed Agent Card describing its skills; a peer fetches that card, posts a JSON-RPC task, and follows the task's lifecycle to a result. A2A's job is agent-talks-to-agent; the Model Context Protocol (MCP)'s job is agent-reaches-tools-and-data. Multi-agent squads are the orchestration layer that decides which agent receives the next turn — and on Devotel Orbit all three are shipped surfaces, so the question below is where each one lives, not whether it exists.
What A2A actually specifies
Strip the marketing away and A2A is four concrete things:
- A discovery document. Every A2A-capable agent publishes an Agent Card at a well-known URL (
/.well-known/agent.json) — a JSON document naming the agent, describing its declared skills (a tag, a name, and an input/output shape each), and declaring its authentication scheme. On Orbit the card can optionally be cryptographically signed, so a peer can verify the card really came from the tenant it claims. - A JSON-RPC task envelope. Delegation is a
Task— a structured envelope with an id, a status (submitted,working,input-required,completed,failed,canceled), and Message parts (text, file, or data). Peers poll or stream the task to a terminal state instead of blocking on an open socket. - A status contract, not a free-for-all. Because A2A fixes the task lifecycle vocabulary, a client library can generic-program against any compliant agent: submit, watch
working, resolve when the agent asks for clarification (input-required), and read the result artifacts atcompleted. The status machine is the interoperability. - Optional extensions. A2A's extension mechanism is how paid delegation works: Orbit ships the x402 payment extension as pure codecs, so an agent can declare in its card that it charges per task and a peer can settle that before the work begins.
None of that is opinion about models or prompts. A2A deliberately stops at the wire between agents, which is why it composes with whatever runtime each agent happens to run.
Where MCP fits: tools are not peers
The most common confusion in the agent stack is conflating these two protocols because both are "how an AI talks to the outside." The distinction is load-bearing:
- MCP (Model Context Protocol) connects an agent to tools, data sources, and resources — "list the available sales-invoice tools", "read this file system", "call the CRM lookup". The agent remains the principal; MCP endpoints answer to it.
- A2A connects an agent to a peer agent — another principal with its own skills, its own guardrails, and its own identity. The requester delegates a goal, not a function call.
A well-designed agent uses both at once: it reaches its own tools over MCP, and it delegates to foreign agents over A2A. Orbit runs both in production — a hosted MCP endpoint for tool access for its agents, and a full A2A federation surface (Agent Card discovery, HMAC-signed inbound envelopes, and outbound delegation to registered peers) for peer-to-peer traffic. Which wire a given hop should take is an architectural decision with real consequences, covered below.
Where squads fit: orchestration is not federation
An agent squad is intra-tenant orchestration: a classifier agent reads the inbound message and routes the turn to a specialist member (say billing or refunds) inside one shared conversation, with an optional fallback and an optional cost cap on the routing classifier. Squads answer which agent owns this turn — a routing question.
A2A answers the federation question — how one agent, wherever it runs, delegates to another agent across trust boundaries. A squad classifier and an A2A peer delegation are both "handoffs," but they live at different layers: the squad handoff happens inside one tenant with shared identity; an A2A task crosses to a peer that must authenticate, so the exchange carries an explicitly authenticated envelope (Orbit signs inbound envelopes with HMAC and can require a verified token when the peer is outside the platform entirely).
That layering is the takeaway for architects: MCP for tools, squads for routing, A2A for federation. You need all three as soon as your agents stop being a single prompt, and you need them to be separable precisely so a squad route and an A2A delegation don't get conflated in the same "handoff" log line.
Why A2A's task model beats a chat-shaped delegation
Two tempting alternatives show up in every agent roadmap before A2A enters the picture — and each loses cleanly:
- A raw OpenAI-style chat call to the peer. Quick, but the peer has to be a prompt interface; there's no discovery, no task state, no way to ask "what can you do?" before you ask it to do it. A2A's Agent Card plus the fixed status machine is the difference between "POST a completion and hope" and "run a protocol."
- A queue/Redis handoff internal to your stack. Fine inside one tenancy, wrong across trust boundaries; the peer has to share your broker topology and the envelope carries no authentication signal it can verify. A2A's signed card and signed envelope give the peer something it can cryptographically check, which a raw queue payload never will.
The third pattern that actually belongs — MCP tool invocation — stays cheap exactly because it doesn't carry task state. Use it where a structured tool call is all you need; escalate to A2A the moment the callee needs to own a multi-step goal.
What Orbit actually ships for A2A
Orbit's A2A surface is not a veneer on the spec — it is the same set of primitives the spec names, hardened for tenant production:
- Agent Cards at
/.well-known/agent.json, optionally signed, with per-agent discovery modes (disabledby default,tenant, orpublic) so a card is never exposed to the open internet by accident. - Federation gates a registered peer has to survive: peer registration requires a public FQDN, inbound envelopes are HMAC-signed and verified before any skill runs, and outbound delegation failures surface as explicit peer errors rather than silent drops.
- The x402 payment extension so a paid agent can declare pricing in its card and request settlement before it does the work.
- Squad routing for the intra-tenant classifier→specialists orchestration layer, kept deliberately separate from the federation surface so each layer's failure modes stay readable.
The end state is an agent team where a squad answers the routing question in milliseconds, an MCP endpoint answers the tool question with least-privilege scoping, and an A2A peer delegation crosses to foreign agents only when the goal really needs one — with each delegation auditable at the protocol layer it actually used.
Frequently asked questions
Is A2A a Google-only spec now?
No. Google authored the original draft and published it openly; the current spec evolves with a wider community, and implementations exist from multiple vendors. Orbit's client and server implement the published A2A spec, so they interoperate with any compliant peer, not just one vendor's agents.
If I already use MCP, do I need A2A?
Almost certainly yes as soon as you have more than one agent. MCP reaches your agent's tools and data; it doesn't model other agents as peers. A2A is the missing wire for that — and the two run side by side in production, one for tools, one for peers.
Why not just chain LLM calls internally?
Because the moment a task crosses a trust boundary — to your customer's bot, to a partner's agent — "sent the whole prompt to the next endpoint" stops being acceptable. A2A gives you a state machine, a discovery document, and an authenticated envelope; three things a raw chain of completions never has.
How do squads and A2A interact on Orbit?
Squads route the turn inside your tenant. If the routed specialist then needs to delegate a goal outside — a supplier's inventory agent, a partner's booking agent, a customer's own assistant — that second hop goes out as an A2A task to a registered peer, not as another squad hop. Two protocols, two layers, one coherent flow.
The takeaway
A2A is not a competitor to MCP or to multi-agent orchestration — it's the third leg of a stool most agent stacks need once they grow past one prompt. MCP for tools, squads for intra-tenant routing, A2A for peer federation. The Orbit agents stack ships all three today as separate, composable surfaces, which is the only configuration that keeps both the trust boundaries and the debuggability intact.