Agent protocols: MCP, A2A and the interop layer

Two protocols solving adjacent problems. Confusing them is common; distinguishing them cleanly is a quick credibility signal.

The split

MCP is how an agent reaches its tools. A2A is how agents reach each other. They compose: an agent uses MCP for capabilities and A2A to delegate to a peer.

The deeper difference is what’s on the other end. An MCP server is passive — it exposes tools and does what it’s told. An A2A peer is an agent with its own reasoning, its own tools, and possibly its own opinion about your request. That changes the contract: you delegate a task and get back a result, rather than calling a function.

A2A

Verified as of 2026-08: contributed to the Linux Foundation in 2026, 150+ supporting organisations including AWS, Google, Microsoft, Salesforce and SAP — up from 50 at its April 2025 launch. Version 1.0.1 (May 2026) added an extension mechanism. Production integrations exist in Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore Runtime.

Agent Cards

Discovery works through an Agent Card — JSON-LD metadata describing what an agent can do, its skills, and its endpoint.

{
  "name": "invoice-processor",
  "description": "Extracts and validates invoice data",
  "url": "https://agents.example.com/invoice",
  "skills": [{
    "id": "extract_invoice",
    "description": "Extract structured data from an invoice document",
    "inputModes": ["application/pdf", "image/png"],
    "outputModes": ["application/json"]
  }],
  "capabilities": {"streaming": true, "pushNotifications": true}
}

The card is served at a well-known path, so an agent can discover peers at runtime rather than having them hardcoded. Same instinct as OpenAPI discovery.

Task delegation

A2A models interaction as a task with a lifecycle — submitted, working, input-required, completed, failed — rather than a request/response call. That’s the right shape for work that takes minutes, needs clarification mid-flight, or streams partial results.

Note the parallel: MCP’s 2026-07-28 revision added multi-round-trip requests for the same reason. Both protocols converged on “the other side may need to come back and ask you something”.

Status, honestly

Adoption is broad on paper and still maturing in practice. The realistic read for 2026: deployment-grade stability arriving through the second half of the year, with widespread enterprise use following in 2027.

The right interview answer is therefore “know it, watch it, don’t assume it’s load-bearing yet” — enthusiasm about a protocol that isn’t widely deployed reads as poorly as ignorance of it.

The other protocols

MCP and A2A are the two with real traction. Naming the others shows breadth, but don’t oversell them.

What the protocols don’t handle

Worth raising, because it’s the gap current research flags: governance is under-specified. Present protocols express capability and message format well. They express poorly:

• Authorization semantics — who may ask this agent to do what, on whose behalf.
• Delegation limits — you asked A to do X; may A ask B, and may B ask C?
• Accountability — when a chain of agents produces a harmful action, which principal authorised it?
• Cost and resource limits across a delegation chain.

For a system-design conversation, this is the substantive point: the protocol gets messages across, but the trust and authorization model is still your problem. Delegation depth limits, per-agent scoping, and an audit trail carrying the originating principal are things you build, not things you get.

Building on this

If you’re wiring agents together today:

• MCP for capabilities — mature, well-supported, real ecosystem.
• A2A if you must cross an organisational boundary — otherwise direct calls or a queue between your own agents are simpler and you keep full control.
• Don’t adopt a protocol for a problem you don’t have. Two agents inside one codebase don’t need cross-vendor interop; they need a function call and a typed contract. See 04_multi_agent_patterns.md.
• Propagate identity and a trace ID through every hop regardless of protocol.

Interview angle

• “MCP vs A2A?” — MCP connects an agent downward to tools and data; A2A connects agents horizontally as peers. MCP’s other end is a passive server; A2A’s is an autonomous agent, so you delegate a task rather than call a function. They compose.
• “How does agent discovery work in A2A?” — Agent Cards, JSON-LD metadata at a well-known endpoint describing skills, input/output modes and capabilities. Runtime discovery rather than hardcoded peers.
• “Is A2A production-ready?” — broad backing (Linux Foundation, 150+ organisations, cloud integrations shipping) and still maturing in practice. Know it and watch it; don’t design a system that depends on ubiquitous support yet.
• “What don’t these protocols solve?” — governance. Authorization semantics, delegation limits, accountability across a chain, and cost bounds are under-specified. You still build the trust model, depth limits and audit trail yourself.
• “Two of your own agents need to talk. Which protocol?” — probably neither. A typed function call or a queue is simpler and gives you full control. Protocols earn their cost at organisational or vendor boundaries.
• “Why did both MCP and A2A add mid-request round trips?” — real work needs clarification, approval or additional input partway through. A single request/response exchange can’t express that, so both converged on letting the callee come back to the caller.