If you're building an agent and trying to decide which protocol to use for what, here's the decision table.
The two protocols
- MCP (Model Context Protocol, spec) — for tools. The agent's Brain calls an external function. Stateless, typed, vendor-neutral.
- A2A (Agent2Agent, spec) — for agents. One agent delegates a task to another. Stateful task object with state machine, principal identity, report-back channel.
The Pillar P2 essay covers the architectural distinction. This spoke is the rule-of-thumb table for picking which one to use.
The decision table
| Scenario | Protocol | Why |
|---|---|---|
| Read a row from your Postgres database | MCP | It's a function call. No identity needed. |
| Call Stripe to refund a charge | MCP | Same. Function with typed input + output. |
| Ask another agent (yours, intra-firm) to review a case | A2A | The receiver is an agent with its own work queue + budget. |
| Ask another firm's KYC agent to review your customer | A2A | Cross-firm delegation. Identity + audit + billing all matter. |
| Run a complex sub-task in parallel with the parent | A2A | The sub-task is itself agent-shaped (reasoning loop, retries). |
| Send a notification to Slack | MCP | Function call. No conversation needed. |
| Spawn a debugging agent to investigate a failure | A2A | The debugger is itself an agent. |
| Translate a string | MCP | Stateless function. |
| Get a second opinion on a hard reasoning call | A2A | The reviewer is reasoning, not transforming. |
When the call is borderline
Two tells that you've picked the wrong protocol:
- MCP call grows a state machine. If your "tool" is tracking task state across multiple calls, it's actually an agent. Switch to A2A.
- A2A call is just one round-trip. If your "delegation" is request + response with no intermediate state, it's actually a function call. Switch to MCP.
Auth contexts — common confusion
MCP auth is the calling agent's auth: a token scoped to what the agent is permitted to do.
A2A auth is the calling firm's auth: a token attesting which firm is delegating, so the receiver can decide whether to accept.
Confusing the two breaks the audit trail and may trigger SOC 2 access-control findings during attestation.
FAQ
Q: What if the receiving system is human-staffed?
A: A2A handles this too — the receiver can be a "human-as-agent" stub that routes to a real person via Slack or email. The task state machine still applies.
Q: What about systems that speak neither protocol?
A: Wrap them. A legacy SOAP API becomes an MCP server (3-line wrapper). A partner firm's REST endpoint becomes either MCP (if function-shaped) or A2A (if agent-shaped).
Q: Are MCP and A2A actually orthogonal?
A: Yes. They sit at different layers. The Brain talks MCP outbound. The Friends graph talks A2A outbound. Both layers operate concurrently in the same agent.
Want MCP + A2A working in your firm? Start free →
