Stateless MCP: payback is deleted infrastructure

Something counterintuitive is happening in agent infrastructure: a protocol upgrade whose payoff is the things you delete. The MCP specification revision published on July 28, 2026 — the largest since launch — made the protocol core stateless. Clients no longer handshake or get pinned to a server instance by a session ID; any instance can answer any request. For architects, this means an entire category of infrastructure built to compensate for protocol flaws — sticky routing, session stores, handshake compatibility layers — flips from “required” to “deletable.” Put plainly: this is the first time a protocol upgrade pays you in deletions rather than additions.

What the stateless change actually did

The fact list (sources: official MCP changelog — https://modelcontextprotocol.io/specification/2026-07-28/changelog ; AWS architecture blog — https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/ ):

The initialize handshake and the Mcp-Session-Id header are gone. Every request carries its own protocol version and client context; the first message can be the actual tool call. A new server/discover method returns supported protocol versions, capabilities, and identity in one response — clients may call it or not. Tool-list caching fields ttlMs and cacheScope are built in, so clients stop refetching the catalog on every run. W3C Trace Context (traceparent, tracestate) rides in request _meta, making distributed tracing protocol-native; MCP’s proprietary protocol logging is deprecated in favor of stderr or OpenTelemetry.

One warning that must be read: the backward-compatible lane preserves session semantics for older clients. Deployments still serving 2025-era clients must keep sticky routing and their session store. Stateless describes the protocol, not your application — use cases that need continuity across calls pass a server-minted identifier as a tool argument and keep the state in your datastore. That is ordinary REST discipline, with one advantage: the identifier lives in the model’s context, so the model can reason about it and thread it across tools.

The payoff is underestimated because it is not on the invoice

AWS offers an arithmetic that looks too small to justify migration: a two-node ElastiCache cache.t4g.micro session store, roughly $23/month. Measuring this upgrade by that number is deciding with the wrong unit. The same AWS post concedes the point itself: sticky routing costs capacity too — it distributes load unevenly, and the savings scale with the size of your fleet. The real payoff is not the $23 you stop paying. It is the operational mindshare of sticky sessions, the patch and scale windows of a session store, and an entire troubleshooting category of handshake failures (source: https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/ ).

The LangChain team’s September 3 refactor note says it most plainly: with a stateless core, a redeploy no longer kills live sessions, because there are none (source: https://www.langchain.com/blog/mcp-in-langchain-stateless-protocol-elicitation-and-more ). The deletion list = session stores (DynamoDB/ElastiCache), ALB sticky rules, handshake infrastructure. Every deletion removes one “2 a.m. failure surface.”

Gateways turn from stateful proxies into pure routers

Statelessness changes what a gateway can do. Previously a gateway parsed the request body to route and throttle by method; now the Mcp-Method and Mcp-Name headers expose the operation type on every POST, and every response carries resultType (complete or input_required) — routing, throttling, and observability can all happen at the header level without touching the body. Observability shifts from “each implementation wires its own” to protocol-native: W3C Trace Context in _meta plugs straight into OpenTelemetry and CloudWatch (source: https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/ ).

Our judgment: this validates the control-plane architecture direction, and the industry has confirmed it with action. Five vendors — Broadcom, Citrix, CrowdStrike, ServiceNow, and Genesys — independently converged on the same three-layer agent infrastructure stack within two weeks: a connectivity layer (MCP), a security and governance layer, and an observability layer (source: https://forkast.news/five-enterprise-vendors-just-shipped-the-same-three-layer-agent-infrastructure-stack-and-none-of-them-coordinated/ ). Stateless MCP is precisely the step that commoditizes the connectivity layer: when connection itself becomes a standard part, the gateway degrades to a pure router and governance plus observability become the differentiating layers. Whoever makes governance and observability measurable and vendor-neutral is standing where the value is being created.

Where lock-in moved

The protocol is open; the ecosystem is hardening. Forkast’s observation deserves a second read from every architect: the protocol stays open under Linux Foundation governance, but value is migrating into proprietary implementation-layer artifacts — security primitives (fingerprintTools, detectToolDrift), workflow-scoped credentials, skills libraries. An agent optimized for the CIQ compute environment, with its credentials and security policy, cannot simply be dropped into a Vercel-managed deployment surface. Protocol neutrality is not ecosystem neutrality (source: https://forkast.news/mcp-is-becoming-the-universal-interface-layer-and-the-lock-in-is-happening-at-the-ecosystem-level/ ).

Our judgment: teams that treat “protocol-neutral” as the endpoint of procurement will discover, about 18 months in, that they swapped one form of vendor dependency for another. When evaluating MCP servers and gateway vendors, the question is not “does it support MCP” — that is the starting point — but “what did it put into the implementation layer.” That is your real migration bill later.

The migration window has a clock, but now is the audit moment

Migration is not due today, but the window has a clock. The 2025-11-25 protocol version is frozen; new capabilities only land on 2026-07-28 and later. Deprecated features (Roots, Sampling, Logging, HTTP+SSE) carry a 12-month floor, earliest removal July 2027; Tasks moved from an experimental API to an official extension with a redesigned interface. AWS’s migration order is four steps: ① upgrade the SDK and opt in — speaking the new revision is never automatic; ② audit session assumptions and migrate off Tasks; ③ plan the deprecation exits and change the resource-not-found error code from -32002 to -32602; ④ collect the infrastructure savings — delete session stores, sticky rules, handshake logic (source: https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/ ).

Our judgment: the backward-compatible lane is not a “we can wait another year” license; it is a buffer designed for paced migration. The single most valuable action right now is the audit: how many session assumptions does your server carry, how many clients still speak 2025, how much infrastructure exists purely for sessions. Until the audit is done, any “we will migrate when we have time” decision is a decision made without information.

Our judgment

First, measuring this upgrade with the wrong unit produces the wrong migration decision. $23/month is a decoy; complexity, capacity unevenness, and failure surfaces are the real invoice. Second, statelessness commoditizes the connectivity layer and turns gateways into pure routers — which validates, rather than refutes, the judgment that governance and observability are the differentiating layers of agent infrastructure. Third, lock-in moves from the protocol layer to the implementation layer: protocol neutrality is the starting point, not the endpoint. Fourth, the migration window is twelve months, but the only correct action right now is the session-dependency audit — not “wait,” and not “migrate everything today.”

A buyer’s action list

First, inventory client protocol versions. How many clients still run 2025-11-25 or earlier? That decides how long your compatibility lane has to live. Second, find the infrastructure that exists for sessions. Session stores, sticky routing, handshake layers — attach an owner and a deletion date to each. Third, target 2026-07-28 for every new server. SDK opt-in, server/discover, W3C Trace Context — write against the new spec from day one. Fourth, plan the deprecation exits. Roots, Sampling, Logging, and HTTP+SSE exit before July 2027; move Tasks to the official extension. Fifth, put header-level routing and tracing policy on the gateway. Mcp-Method throttling, W3C Trace Context propagation — set the policy before the first MCP app ships, in AWS’s own words: set a policy for MCP Apps before the first server in your fleet ships one.

The decision question left for you: how many lines of code in your MCP server exist only because “the protocol used to require a handshake”?

References: MCP official changelog (2026-07-28) — https://modelcontextprotocol.io/specification/2026-07-28/changelog ; MCP official announcement — https://blog.modelcontextprotocol.io/posts/2026-07-28/ ; AWS “MCP went stateless: Is your AWS MCP server deployment well-architected?” (2026-09-01) — https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/ ; LangChain “MCP in LangChain: Stateless Protocol, Elicitation, and More!” (2026-09-03) — https://www.langchain.com/blog/mcp-in-langchain-stateless-protocol-elicitation-and-more ; Forkast “Five Enterprise Vendors Just Shipped the Same Three-Layer Agent Infrastructure Stack” (2026-09) — https://forkast.news/five-enterprise-vendors-just-shipped-the-same-three-layer-agent-infrastructure-stack-and-none-of-them-coordinated/ ; Forkast “MCP Is Becoming the Universal Interface Layer” (2026-09) — https://forkast.news/mcp-is-becoming-the-universal-interface-layer-and-the-lock-in-is-happening-at-the-ecosystem-level/