Enterprise MCP Architecture After the Stateless Spec: The Four Homes Your Agent State Needs Now

The July 28 MCP spec goes stateless. Enterprise MCP architecture now has to rehome four kinds of state. Here is the CITE model for where each one lives.

On July 28, 2026, the Model Context Protocol becomes stateless. The Mcp-Session-Id header is gone, the protocol-level session is gone, and with them the assumption most teams quietly built their integrations on: that the connection remembers who you are, what you were doing, and what you are allowed to do. The security press is reading this as a hardening story, and it is one. But for anyone responsible for enterprise MCP architecture, the harder change is subtler. Going stateless does not delete state. It evicts state from the protocol and makes rehoming it your problem.

I work with Fortune-level enterprise clients architecting and building agentic frameworks, and MCP has quietly become load-bearing inside most of them. The number of teams that have mapped where their agent state will live after the session disappears is much smaller than the number who have MCP servers in production. That gap is the whole story. This is a migration with a date on it, and the work is architectural, not a version bump you take on a Tuesday.

What actually changes in the enterprise MCP architecture

Strip the release notes down and the 2026-07-28 specification does four things that matter to an architect. The core goes stateless, so any request can land on any server instance and you can run MCP behind a plain round-robin load balancer with no sticky sessions and no shared session store at the protocol layer. Authorization aligns much more closely with OAuth and OpenID Connect, moving identity out of ad hoc per-server handling. A new Tasks extension gives long-running work a first-class home instead of a held-open connection. And the roadmap and Dev Summit put observability and audit integration front and center, because a protocol that large organizations depend on has to be traceable.

Every one of those is an improvement. Together they describe a single move: the protocol is handing four kinds of state back to you and telling you to put them somewhere on purpose. The question is no longer whether MCP can scale. It is whether you have decided where each kind of state now lives, and who owns it.

The CITE model: four homes for evicted state

When a session goes away, four categories of state that used to ride inside it need explicit new homes. I use a simple map I call CITE: Connection, Identity, Task, Evidence. It is not a product and it is not in the spec. It is a checklist for the four decisions the stateless move forces, so none of them get made by accident three weeks after you ship.

Connection: where does session affinity go?

Under the old model, a session tied a client to a server instance, and long-lived work leaned on that stickiness. Stateless MCP removes it. The good news is horizontal scale gets trivially easier, because requests fan out across instances behind ordinary HTTP infrastructure. The trap is any hidden assumption that "the same server handles the next call." Connection state now lives in your gateway and load-balancing layer, and anything that was implicitly per-connection — rate limits, in-flight context, partial results — has to move to a shared store you control or be redesigned to be genuinely stateless. Teams that skip this find their servers scale beautifully and their workflows break the moment a second replica comes online.

Identity: where is the agent's authority proven?

The spec's authorization hardening is the part everyone applauds and the part most likely to be under-implemented. Aligning with OAuth and OIDC means identity and authorization stop being a property of a warm session and become a property of every request. That is strictly better for security, but it relocates real work: you now need an identity provider in the request path, per-request token validation, and a policy layer that decides what this agent, acting for this principal, is allowed to call right now. This is exactly the runtime enforcement point the major platforms converged on earlier this year. If you have not decided whether that authority lives in a gateway, in a policy engine like a Cedar-based check, or scattered across each server, the stateless spec will make that indecision visible fast.

Task: where does long-running work persist?

The Tasks extension exists because a stateless protocol cannot hold a connection open for an eight-hour job. Long-running and asynchronous work now needs a durable task record — an identifier, a status, a result location — that survives across requests and instances. Practically, that means a store you own: a queue, a database, a workflow engine. The spec gives you the handoff shape; it does not give you the persistence. Task state is the category teams most often assume the protocol still handles, because it used to be invisible. It is now an explicit design decision with a schema attached.

Evidence: where do you prove what happened?

The fourth home is the one audits care about and pilots ignore. Once every call is an independent, stateless request flowing through a gateway, you have a natural chokepoint to emit trace-native, tool-call-granular records: who invoked what, on whose authority, with what arguments, and what came back. If you do not capture it there, a stateless architecture actually makes reconstruction harder, because there is no session narrative to replay. Evidence state belongs in your observability layer, ideally on OpenTelemetry conventions, wired from day one rather than retrofitted the week before a compliance review.

Why the obvious approach fails

The obvious approach is to treat July 28 as an SDK upgrade: bump the version, run the tests, move on. That works right up until the first thing that depended on a session — sticky routing, an implicit auth context, a held-open long task, a session-scoped log — quietly stops behaving. None of those show up in a unit test. They show up in production, under load, or in front of an auditor. The stateless spec is not hard because the protocol got complicated. It is hard because it made four previously implicit decisions explicit, and implicit decisions are the ones that rot.

There is also a real deadline shape here. Legacy versions get a formal deprecation window, roughly twelve months, so nothing breaks on the 28th. That is a gift and a hazard: the runway removes urgency, and the teams that use it well are the ones who do the state-rehoming now, while the ones who treat the window as permission to wait will do the same work later with less time and more production traffic riding on it.

What I'd actually do

Before touching an SDK, run the CITE map against every MCP server you operate. For each one, write a single sentence answering four questions. Where does connection state go once there is no sticky session? Where is identity proven on every request, and what enforces authorization there? Where does long-running task state persist across instances? Where is evidence captured, and is it granular enough to answer "was this action allowed" after the fact? If any of those four sentences is missing, that server is not ready for the stateless spec, regardless of whether the code compiles against the release candidate.

Then sequence the work behind a gateway. A thin control point in front of your MCP servers is where three of the four homes naturally live — connection routing, identity and authorization enforcement, and evidence capture — which is why the gateway-plus-registry pattern keeps forming across the ecosystem. Get that layer in place first, migrate servers behind it, and use the twelve-month window to move deliberately instead of all at once. The spec did the hard part of making the protocol enterprise-ready. The part it left to you is deciding where your state lives before it decides for you.

If you want the one-line version to take into your next architecture review: stateless MCP does not remove state, it relocates it, and Connection, Identity, Task, and Evidence each need an owner before July 28.

I write about enterprise agentic AI architecture — orchestration, decisioning, and the unglamorous infrastructure that gets agents from pilot to production. If that is your world, subscribe to the newsletter for one practitioner-grade breakdown a week.

Primary source: the MCP 2026-07-28 release candidate on the official Model Context Protocol blog.