MCP, A2A and AGNTCY are not competitors — they occupy different layers of the same stack. Here is which layer is load-bearing today, which to defer, and what a reversal costs per integration.
Last Updated: September 22, 2026
MCP, A2A and AGNTCY solve different layers: tool and data access, agent-to-agent delegation, and identity/discovery/observability respectively. For a mid-market build in Q4 2026, only MCP is load-bearing — hard-code against the 2026-07-28 spec, put A2A behind a thin adapter you only activate when you cross an organisational trust boundary, and defer AGNTCY until you have agents you did not build yourself. Standardise observability on OpenTelemetry, not on any protocol's telemetry story.
Three protocols, four layers: only one is load-bearing
The comparison everyone publishes — MCP versus A2A versus AGNTCY, pick a winner — is the wrong frame, and it produces bad architecture. These three things do not overlap enough to compete for the same slot in your stack. They overlap just enough that if you wire all three in at once you will pay for the same capability three times.
Map them to layers instead. Layer 1, tool and data access: how a model reaches a CRM, a database, a file store. That is MCP. Layer 2, inter-agent messaging: how one agent hands a unit of work to another agent it does not own and cannot introspect. That is A2A. Layer 3, identity and discovery: how an agent finds and cryptographically trusts an agent it has never seen. That is what AGNTCY is building, and it explicitly sits above the other two — Cisco describes it as providing discovery, identity and trust, a messaging layer supporting MCP, A2A and other protocols, and observability tooling. Layer 4, observability: not a protocol decision at all, and treating it as one is the most common planning error I see.
Governance consolidated fast. The Agentic AI Foundation launched on 9 December 2025 with MCP and OpenAI's AGENTS.md among its anchor contributions; AGNTCY had already entered the Linux Foundation on 29 July 2025 with Cisco, Dell, Google Cloud, Oracle and Red Hat as formative members; Google had donated A2A to the Linux Foundation on 23 June 2025, a year after announcing it. Neutral stewardship is now the norm across all three. That settles who owns the specs. It does not settle which ones you should hold a dependency on.
What MCP 2026-07-28 actually changed
This release is the reason the protocol conversation is live again in Q4, and it is a genuinely large break. MCP removed protocol-level sessions and the Mcp-Session-Id header from the Streamable HTTP transport, and removed the initialize/notifications/initialized handshake entirely. Every request now carries its own protocol version and client capabilities in _meta. Servers that need cross-call state mint explicit handles and pass them as ordinary tool arguments. A new server/discover RPC, which servers MUST implement, advertises supported versions and capabilities up front.
The motivation is unglamorous and correct. The March 2026 roadmap named the problem plainly: stateful sessions fight with load balancers and horizontal scaling requires workarounds. Anyone who has run a remote MCP server behind more than one pod knows the shape of that bug — sticky routing, session affinity hacks, a tools/list that silently differs per connection. That class of failure is now gone by construction.
What went with it matters for your migration plan. Server-initiated requests — roots/list, sampling/createMessage, elicitation/create — were replaced by the Multi Round-Trip Requests pattern, where the server returns an InputRequiredResult and the client retries the original request with its responses. Roots, Sampling and Logging are now formally deprecated, with the suggested migrations being tool parameters or resource URIs instead of Roots, direct provider APIs instead of Sampling, and stderr or OpenTelemetry instead of Logging. SSE stream resumability is gone: a broken response stream loses the in-flight request and the client must re-issue it with a new request ID. Tasks moved out of the core and into an official extension.
Two changes are quietly the most useful in production. First, the spec now documents OpenTelemetry trace context propagation conventions for _meta keys — traceparent, tracestate, baggage. That is your cross-layer correlation ID, and it is the single thing that makes a multi-protocol agent debuggable. Second, list and read results now carry ttlMs and cacheScope, which turns tool-catalogue polling from a per-turn cost into a cacheable one.
On the authorization side, Dynamic Client Registration (RFC 7591) is deprecated in favour of Client ID Metadata Documents, clients must key persisted credentials by issuer and re-register when the authorization server changes, and RFC 9207 iss validation is expected. The current roadmap also confirms Enterprise-Managed Authorization is stable as an extension, and that a Server Card working group is defining .well-known metadata so a server can be discovered and reasoned about without connecting to it.
Why the deprecation policy is the real headline
The 2026-07-28 release adopted a feature lifecycle with Active, Deprecated and Removed states and a minimum twelve-month deprecation window, plus a public registry of deprecated features. For a buyer, that is worth more than any single technical change: it converts "the spec might break my integration" from an unbounded risk into a scheduled maintenance item you can budget for once a year.
A2A: real, but only at a trust boundary
A2A is not vapour. The Linux Foundation reports growth from more than 50 supporting organisations at launch to over 150, with the Agent Payments Protocol extension drawing 60+ payments and financial-services organisations. The spec has reached v1.0 under Apache 2.0 with official SDKs in Python, JavaScript, Java, C# and Go. IBM folded its competing ACP work into it. Read the adoption counts with the caveat that they are foundation and vendor tallies rather than independent measurement — direction, not market share.
The question is not whether A2A works. It is whether you need it. A2A's value proposition is delegation across a boundary where you cannot see inside the other agent: different vendor, different company, different security domain. Inside one organisation, where you wrote both agents and they share a runtime, A2A buys you an agent card, a task lifecycle and a message envelope you could have got from a queue and a JSON schema — at the cost of a second protocol surface, a second auth model and a second place where state lives.
There is also a live overlap worth naming. "Agent communication" was one of the four priority areas in MCP's own roadmap, and the stateless MCP core plus MRTR now handles long-running, human-in-the-loop work that used to be an argument for reaching for A2A. The boundary between the two specs is real but it is moving, which is precisely why A2A belongs behind an adapter in your code rather than threaded through your business logic.
AGNTCY: the layer to watch, not wire in
AGNTCY is the most architecturally ambitious of the three and the least urgent for most buyers. It is not one protocol; it is a stack — a federated registry for cross-framework agent discovery, SLIM for network-level secure messaging, an identity service, a secure agent runtime, and telemetry collectors for multi-agent observability. The Linux Foundation's framing is that AGNTCY makes A2A agents and MCP servers discoverable through its directories, using the Open Agent Schema Framework for capability description. It is a superset layer, not a rival.
How agents from different vendors and companies can find, verify and collaborate openly with each other.
— Vijoy Pandey, SVP/GM, Outshift by Cisco, CIO
That is a real problem. It is not yet your problem if you are running eleven agents you built, on infrastructure you control, against systems you already have credentials for. Discovery only pays when the set of counterparties is open and changing. Identity federation only pays when you must accept an assertion minted by someone else's issuer. The AGNTCY identity framework is being developed with partners including Cisco Duo, Skyfire and Permit.io, which tells you where it is heading — cross-organisational trust — and how far that is from a single-tenant internal automation estate.
The honest recommendation: track it, attend the working groups if agent-to-agent commerce is in your two-year plan, and do not put it on the critical path for a Q4 build. Model your agent identities as service principals in the IdP you already run, and keep the mapping thin enough to replace.
| Layer | Protocol | Status in Q4 2026 | What to do now |
|---|---|---|---|
| Tool & data access | MCP (2026-07-28) | Production-ready; largest revision since launch, formal deprecation policy in place | Hard-code against it. Target the stateless core, implement server/discover, skip Roots/Sampling/Logging. |
| Inter-agent messaging | A2A v1.0 | Production-ready at v1.0, 150+ supporting orgs, but scope overlaps a moving MCP boundary | Abstract behind an adapter. Activate only where a task crosses a vendor or org boundary. |
| Identity & discovery | AGNTCY (OASF, Identity, Directory, SLIM) | Components shipping, governance young, value concentrated in open cross-org networks | Defer. Use your existing IdP for agent identity; keep an OASF-shaped description of each agent so you can register later. |
| Observability | OpenTelemetry | Stable; MCP now documents traceparent/baggage propagation in _meta | Standardise here first. It is the cheapest decision on this table and the only one that pays regardless of which protocols win. |
What a protocol reversal actually costs
Budget conversations get vague here, so let me make the arithmetic explicit. These are the planning figures we use on our own internal n8n and MCP builds — engineering estimates, not measured outcomes from any client engagement, and you should re-derive them against your own team's velocity.
A thin MCP server wrapping an existing REST API — auth, three to six tools, input schemas, error mapping — lands around 6–16 hours if the upstream API is sane. Migrating that same server from the 2025-11-25 shape to 2026-07-28 is a different number depending entirely on one decision you made months earlier: did you put transport and protocol handling in a shared internal library, or did each server carry its own? With a shared layer, migration is roughly 2–6 hours per server, most of it re-testing. Without one, you are re-touching the handshake removal, session-ID removal, the MRTR rewrite of every elicitation path and the error-code renumbering in each repo separately — realistically one to three days per server.
Ten integrations, no shared transport layer: that is a two-to-six week engineering month you did not plan, for zero new functionality. With the shared layer it is under a week. The abstraction is not architectural elegance; it is the entire delta.
The bigger cost is the one that does not appear in a transport migration. Your real lock-in is not the wire format — it is tool semantics: the names, argument schemas, idempotency guarantees and side-effect boundaries your agents have been prompted and evaluated against. Swapping MCP for something else is a week of plumbing. Re-teaching an agent estate that crm.update_deal is now three calls with different failure modes invalidates your eval suite, your prompt library and your regression baseline. Price the semantics, not the protocol. We sequence builds this way deliberately on our automation work — one tool contract, many transports.
Where to put the seam
A plain internal function with a typed contract and explicit side-effect semantics. No protocol types in this layer, ever.
One shared package exposes capabilities as MCP tools and, where needed, as A2A skills. Spec churn is absorbed here and nowhere else.
Streamable HTTP with stateless request handling; server-minted handles for anything that needs continuity across calls.
One token broker, one OTel trace. Agent identities live in your existing IdP until a federation requirement forces the change.
The failure mode nobody prices in: duplicated auth and context
Run an agent that is simultaneously an MCP client, an A2A server and an A2A client, and you have three identity contexts that nothing joins up. MCP authorization is OAuth against a resource server, with credentials now bound to the issuing authorization server and required to be re-registered when that server changes. A2A carries its own declared auth schemes on the agent card. Your own platform has a user session. Nothing in any spec obliges these to agree on who the acting principal is, and by default they will not.
The symptom is not an outage. It is an audit that cannot answer "which human authorised this write?" because the consent was captured at the platform boundary, the token that performed the write was minted for the MCP resource server, and the delegation hop in between was an A2A task with its own credentials. You discover this during a security review, months after go-live, and the fix is structural.
Letting each protocol layer carry its own auth and its own copy of context
It happens because each SDK ships a working auth path and each one is easy to accept. You then get the same context twice on the wire: the delegating agent packs task state into A2A message parts, and the receiving agent re-fetches the same records through MCP resources because that is the interface it trusts. Token spend roughly doubles on the handoff, and the two copies diverge the moment anything mutates between them.
_meta using the documented traceparent/baggage conventions so the MCP call, the A2A task and the platform request appear on the same span tree.
A decision rule for Q4 2026
If your agents only touch systems you already own, build MCP and nothing else. Standardise on 2026-07-28, write stateless servers, implement server/discover, do not adopt Roots, Sampling or Logging in anything new, and put every server behind one shared transport package. That covers the overwhelming majority of mid-market automation work, and the twelve-month deprecation window means your next forced migration is a scheduled item rather than a surprise.
Add A2A when a task genuinely leaves your trust domain — a partner's agent, a marketplace, a vendor platform exposing A2A endpoints — and add it as an adapter over capabilities you already expose, not as a parallel implementation. Keep an OASF-shaped capability description for each agent even if you never register it anywhere; that is the cheap option on AGNTCY, and it costs a YAML file rather than an integration.
Do not adopt AGNTCY's identity or directory services as your primary agent identity layer this quarter unless you are specifically building an open, cross-organisational agent network. And whatever you do, wire OpenTelemetry through everything from day one. It is the only layer on the table that survives every plausible protocol reversal. If you want a second opinion on where the seams should sit in a specific stack, that is the kind of thing we work through in an integration review — or see how model choice interacts with these layers on our model coverage page, and get in touch if you are sequencing a build for Q1.
Frequently Asked Questions
Is MCP vs A2A vs AGNTCY actually a choice?
Not in the way most comparisons imply. MCP standardises how a model reaches tools and data. A2A standardises how one agent delegates work to another. AGNTCY provides the discovery, identity, messaging and observability infrastructure above both, and explicitly supports MCP and A2A rather than replacing them. You can adopt all three, but for most builds only MCP is required in Q4 2026.
What breaks if I upgrade to the MCP 2026-07-28 spec?
Quite a lot, deliberately. The initialize handshake and protocol-level sessions are gone, the Mcp-Session-Id header is removed, server-initiated requests are replaced by the Multi Round-Trip Requests pattern, SSE resumability is removed, Tasks moved to an extension, and several error codes were renumbered. Roots, Sampling and Logging are deprecated. Plan a re-test of every server, and expect the work to be concentrated in your transport layer if you have one.
When does A2A become worth the extra surface area?
When a task crosses a boundary you do not control: another company's agent, a vendor platform, a marketplace. Inside a single organisation with agents you wrote, A2A mostly duplicates what a queue plus a schema already gives you while adding a second auth model and a second place state lives. Build the adapter early, activate it late.
Does the Agentic AI Foundation make these specs safe to build on?
It reduces one specific risk — a single vendor unilaterally changing or withdrawing a spec — and it does not reduce the others. Foundation membership counts are self-reported and are a signal of direction, not of production maturity. What actually protects your build is MCP's published feature lifecycle with a twelve-month minimum deprecation window and a registry of deprecated features. Governance is necessary; a deprecation policy is what you can plan against.
How should I handle agent identity if I skip AGNTCY?
Model each agent as a service principal in the identity provider you already operate, mint short-lived per-layer credentials from one broker, and record human consent once at the platform boundary rather than per protocol. Keep the mapping between agent and principal thin and declarative so you can swap in a federated identity layer later without touching agent logic.
What is the cheapest decision I can make this quarter?
Standardise on OpenTelemetry and propagate one trace context across every layer. MCP now documents traceparent, tracestate and baggage conventions in the _meta field, so cross-layer correlation is a configuration decision rather than a custom build. It survives any protocol reversal, and it is what makes multi-agent incidents diagnosable rather than archaeological.
Should I wait for the specs to settle before building?
No — but build so that churn is cheap. Put domain capabilities behind a protocol-free contract, expose them through one shared adapter package, and keep tool semantics stable even when the wire format changes. The cost of waiting is a year of compounding integration debt. The cost of building without the seam is re-touching every repository each time the spec moves.
Research digest
AI Research Briefing
Honest insights on AI agents, Small Language Models, and local RAG. No hype. Only when we have something worth sending.
- No hype, just measurable outcomes
- Read by 2,400+ engineers
- Unsubscribe anytime