# MCP Just Deleted Sessions. That One Change Rewrites Your Agent Architecture. > Source: > Published: 2026-08-13 04:36:39+00:00 Most architecture changes announce themselves. A new framework, a keynote, a migration guide, six months of blog posts arguing about it. The one that just happened to the Model Context Protocol arrived as a spec revision note on **July 31**, and as far as I can tell almost nobody outside the working group has processed what it implies. MCP dropped stateful sessions in favor of stateless HTTP. Remote MCP servers no longer hold session state between calls. If you have not built on MCP, that sentence sounds like a footnote. If you have, you already know it invalidates a meaningful chunk of what you wrote this year. And it did not happen in isolation. Look at the eleven days on either side of it: Three moves, three organizations, eleven days. They look unrelated. They are not. They are the same architectural conclusion arriving from three directions at once. The agent is not where the value accumulates. The agent is the cheapest, most replaceable component in the entire system. **Why Stateful Sessions Were Always a Loan Against the Future** To see why this matters, you have to understand what the session was actually doing. In the original MCP design, a client connected to a server and that connection carried context. The server knew which client it was talking to, what had already happened in the conversation, which resources had been opened, what the negotiated capability set was. The session was a convenience — it meant every call did not have to re-establish everything. Convenient, and expensive in three specific ways. **It made servers stateful, which made them hard to scale.** A stateful server cannot be trivially horizontally scaled behind a load balancer, because request N+1 has to land on the same instance that handled request N. You need sticky sessions, or a shared state store, or both. Every team that ran an MCP server at any real volume hit this and solved it badly. **It made failure recovery ambiguous.** When a session drops mid-workflow, what is the correct behavior? Replay? Resume? Restart? There is no general answer, because the answer depends on what the session was holding. Teams ended up writing bespoke reconnection logic per server, which is exactly the kind of code that is never quite right and never quite tested. **And most importantly: it put state in the wrong layer.** This is the one that matters architecturally. If the server holds session state, then the server is where your agent’s operational context lives. Which means your observability, your audit trail, your authorization decisions, and your rate limiting are all distributed across every MCP server you talk to. There is no single place to look, and no single place to enforce. Stateless HTTP forces every call to carry its own context. That is more verbose per request. It is also the precondition for everything else on this list. **What DoorDash Built, And Why It Is the Real Story** Three days after the spec change, DoorDash published the architecture that the spec change enables. Their **Agent Gateway** is a centralized layer sitting between agents and MCP tools. Every tool call routes through it. The gateway handles identity — which agent, acting on behalf of which user, in which context. It handles authorization — is this agent permitted this tool with these arguments right now. And it handles credentials — the agent never holds the secret; the gateway injects it at call time. Read that last part again, because it is the load-bearing piece. **The agent never holds the credential.** In the pre-gateway world, an agent with tool access had the keys. You gave it a token, it called the API. Which meant the blast radius of a compromised or confused agent was the full scope of every credential it held, for the full lifetime of those credentials. Given what four separate labs disclosed about containment failures in the same two-week window — Anthropic, OpenAI, Meta, and Moonshot all reporting agents reaching things they should not have — that is not a theoretical concern. With a gateway, the agent holds an identity, not a capability. It says “I want to call this tool with these arguments.” The gateway decides whether that is allowed, and only then does the credential enter the picture, server-side, for the duration of one call. This is not a new idea. It is exactly what service meshes did for microservices, and what API gateways did before that. The pattern is well understood and the operational tradeoffs are known. What is new is that the agent ecosystem has arrived at it roughly two years into its existence rather than ten, which is unusually fast for infrastructure convergence. **The Piece Everyone Is Missing: Stateless Is What Makes the Gateway Work** Here is the connection that the separate announcements obscure. A gateway in front of *stateful* MCP servers is close to useless, and worse, it is actively misleading. If the server holds session state, the gateway cannot make a complete authorization decision from the request alone. Request N+1 means something different depending on what happened in requests 1 through N — and that history lives on the server, not at the gateway. Your gateway would be authorizing a call whose actual meaning it cannot fully see. That is security theater with latency overhead. Once calls are stateless and self-describing, the gateway can see everything relevant in the request itself. Which agent. Which user. Which tool. Which arguments. Full context, one place, every time. **Stateless HTTP is not a performance change. It is the precondition for a policy layer.** That is why these two announcements are three days apart, and it is not a coincidence. Cloudflare’s WebMCP extends the same logic to the messiest surface there is. The open web has no MCP servers and never will — you cannot ask four billion websites to implement a protocol. WebMCP inverts it: the browser becomes the adapter, exposing page capabilities as tools the agent can call. And the browser is, architecturally, another gateway. It sits between the agent and the resource, it can enforce policy, and it can mediate credentials. Three announcements. One shape. **The Strongest Argument Against This Piece** The obvious objection: gateways are a centralization pattern, and centralization has a cost that this framing glosses over. Every argument for a gateway is also an argument for a single point of failure, a latency tax on every call, and an organizational bottleneck where one team’s policy decisions gate every other team’s velocity. Service mesh history is instructive here, and not flatteringly. Istio was going to solve microservice governance. A lot of teams ended up with an operational burden that exceeded the problem it was deployed against, and a meaningful number of them ripped it out. That critique is real, and I would extend it further than most gateway advocates will. For a team running three agents against five tools, a gateway is almost certainly the wrong call. You will spend more time operating it than you would spend rotating credentials by hand. The N×M sprawl problem does not bite until N and M are both meaningfully larger than three. There is a second objection worth taking seriously: stateless calls are more verbose, and in an agent workflow that means more tokens. Re-sending context on every call has a real cost, and at high call volumes that cost is not trivial. The spec change traded token efficiency for architectural clarity, and if your workload is token-bound rather than governance-bound, that is a bad trade for you. So the honest version of the claim is narrower than the maximalist one. The gateway pattern wins when the number of agent-tool pairs grows past the point where per-pair credential management is tractable, **and** when you have a compliance or audit requirement that demands a single answer to “what did the agents do.” Below that line, it is premature infrastructure. What I would still argue is that the line is closer than most teams think, and it is approaching faster than they are planning for, because agent count tends to grow discontinuously. You do not add one agent. Somebody wires up a framework and you have eleven. **What To Actually Do About It** Concrete, in order. **Audit your credential distribution today.** Write down every agent, every tool it can reach, and every secret it holds. If that table has more than about twenty rows, you are already past the point where the gateway pattern pays for itself. Most teams have never made this table and are surprised by it. **Make every MCP call self-describing before you are forced to.** Whether or not you adopt a gateway, the spec has moved. Code that assumes session state is now on a deprecation path. Refactoring calls to carry their own context is work you are going to do regardless, and doing it deliberately is cheaper than doing it under a deadline. **Separate identity from capability in your agent design.** This is the conceptual shift and it is worth internalizing even without a gateway. Your agent should know *who it is*, not *what secrets it has*. Even a thin local shim that swaps an agent identity for a scoped short-lived token at call time captures a large fraction of the security benefit at a small fraction of the operational cost. **Do not build the gateway yourself yet.** DoorDash built theirs because DoorDash operates at a scale where a bespoke control plane is justified. The pattern is converging and vendors will ship it. Build the shim, keep the interface clean, and buy the real thing when it exists. **The Shift That Is Actually Happening** For two years, the agent conversation has been almost entirely about capability. Which model reasons best. Which framework orchestrates most elegantly. Which harness handles tool calls with the least ceremony. Those questions are becoming less interesting, and quickly, for an unglamorous reason: **the agent layer is commoditizing faster than any layer beneath it.** Swapping your orchestration framework is now an afternoon. Swapping your model is a config change and an eval run. Neither of those is where a durable advantage lives. What does not swap out in an afternoon is the layer that knows which agent is allowed to do what, on whose behalf, with which credential, and can prove it afterward. That layer accumulates policy, institutional knowledge, and audit history. It gets more valuable the longer it runs and the more it has seen. It is genuinely hard to rip out. Which is the definition of infrastructure, and the opposite of what everyone has been building. The spec change on July 31 was not a footnote. It was the industry quietly conceding that state belongs in a control plane, not scattered across every server an agent happens to talk to. DoorDash and Cloudflare just showed two different shapes the same concession can take. The question is no longer which agent framework wins. That fight is being commoditized out of relevance while people are still having it. The question is who owns the control plane. And right now, almost nobody is building for it. *That is the gap worth closing first.* [MCP Just Deleted Sessions. That One Change Rewrites Your Agent Architecture.](https://pub.towardsai.net/mcp-just-deleted-sessions-that-one-change-rewrites-your-agent-architecture-14a27618b0f9) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.