Stateless, Secure, and Extendable. What the MCP Release Changes for Enterprise Agents.

I spent Wednesday evening at AI House Amsterdam for the MCP Release Party, one of a handful the Agentic AI Foundation ran across London, Seattle, San Francisco and Amsterdam to mark the 2026-07-28 specification. Three talks, one panel, and a room full of the people who maintain this protocol rather than sell it.

Most coverage of this release is a feature list, which is the wrong lens for anyone signing budgets. What changed is what an enterprise can now do with agents that it could not responsibly do a week ago. There are four of those, and each one removes a specific reason your agent program has been stuck in pilot.

I also run ten agents in production, so there is a fifth section on what the spec does not fix. That one comes from my own logs rather than the stage.

You can now scale agent traffic on infrastructure you already own

Sam Morrow, a software engineer at GitHub and an MCP maintainer, opened on the change everyone came for. Sessions are gone.

Think about what containerization did to freight. The standard box was not the innovation. Interchangeability was. Once every load looked identical from the outside, any crane could put any box on any ship at any port, and capacity became something you bought rather than something you engineered.

MCP just did that to the request. Every call now carries its own protocol version, identity and capabilities, so any server instance can answer any request. Morrow was direct about what the old model cost: for anyone hosting other people's MCP servers, horizontal scaling was effectively impossible without forcing customers onto a bespoke architecture, which is not something you ask a paying client to accept.

What you get is unglamorous and immediately bankable. Your MCP layer runs behind ordinary load balancers, on the same infrastructure, the same runbooks and the same on-call rota as everything else you operate. GitHub has been running the new version in production for around three weeks, and Morrow said they had already served on the order of half a million requests from clients on the new protocol before the specification was formally announced. Their session store came out of the critical path entirely, which bought them lower latency and one fewer external dependency between a user and a working answer.

Your security team can finally see agent traffic without opening it

The second change reads as plumbing and behaves like governance. Protocol methods are now duplicated into HTTP headers, which means the address is on the outside of the envelope. Your gateway can route, meter, log and screen agent traffic without parsing the payload, the same way your mail room sorts post without reading letters.

Underneath that, six specification enhancement proposals landed to harden OAuth and OpenID Connect. The one worth understanding at board level requires the client to validate which authorization server actually issued a response, closing off mix-up attacks in environments running more than one identity provider. Until now the equivalent control was trusting the letterhead on a wire instruction, and most large enterprises run several identity providers whether they intended to or not.

Enterprise-Managed Authorization arrives as an official extension and your people will feel it on day one. Your staff do not negotiate access with the receptionist on every floor, because IT issues a badge once. This puts agent access on the same footing, so users log in once and their work MCP servers connect automatically. Consent fatigue has always been a security failure dressed as a user experience complaint, because a person clicking "allow" for the fortieth time this week has stopped reading. Removing that decision from them removes the failure.

Human approval stops being an architecture problem

This is the one I would put in front of a risk committee. Until this release, an agent stopping mid-task to ask a person for a decision required holding a connection open between server and client. That worked on a laptop and fell apart at scale, which is precisely why so many enterprise agents are still restricted to reading things. Approving, transferring, provisioning and purchasing all need a human in the loop, and the loop was the expensive part.

The new pattern is the returned form. The server responds that input is required, the person authorizes in their browser, and the client resubmits the same call with the answer attached. Nothing stays on the line. Peder Holdgaard Pedersen pointed out that the concept is not novel at all, because it is how web applications have worked for twenty years, and that familiarity is exactly the argument. You are not being asked to trust a new idea. You are being asked to stop paying for a workaround.

One related control deserves naming. Because client capabilities now travel in every message, a server can decide what to offer based on what the client can actually handle. Pedersen's example was a bank with a transfer money tool: if the client cannot render a confirmation screen, the server never advertises the tool at all. The guardrail moves out of the policy document and into the protocol.

I built the returned form by hand, and it failed exactly the way the spec predicts

I have ten agents running in production on a refurbished mini PC in my office. They handle content, market intelligence, and operations, and nothing consequential publishes without a human approving it first. Approval runs on Slack emoji reactions, which is the crudest possible version of the pattern Pedersen described from the stage.

Here is what went wrong. The registry that tracked which items were awaiting approval lived in process memory. The service restarts every night at 4am. So every restart quietly emptied the queue, and every reaction that arrived afterward was recorded against nothing at all. I went months believing I had a functioning approval loop. Zero real decisions were ever written down. The registry now persists to SQLite, which is a two-line change I should not have needed a two-month outage to find.

That is a session-state failure. Small, self-inflicted, and structurally identical to the one this release just removed from the protocol. When state about an in-flight human decision lives anywhere ephemeral, restarts eat it and nobody gets an error. The reason to care about statelessness is not elegance. It is that the stateful version fails silently, and silent failure in an approval path is the one failure mode a risk committee cannot accept.

Two things the spec does not fix, and I have the logs to prove it.

The first is throughput. Five drafts have been sitting in my approval queue for months, waiting on me. The returned form removes the architecture cost of a human in the loop. It does not remove the human, and in most agent programs the human is the constraint. If your approval path currently routes every decision to one senior person, statelessness makes that bottleneck cheaper to run and no faster to clear.

The second is that protocol guardrails only catch protocol-level mistakes. My market intelligence agent once published a rate benchmark it attributed to an external source. The number was mine, from an unpublished internal document, laundered back to me as third-party validation because its prompt asked for a benchmark and nothing checked whether one existed. Capability negotiation would not have caught that. No transport change catches that. The protocol can guarantee that a confirmation screen exists before a tool is offered, and it cannot guarantee that the thing on the screen is true.

You can adopt without betting on a frozen standard

Pedersen's framing was the sharpest thing said all evening. A release is not a feature list. It is a snapshot of a metabolism.

Four things happen at once in a healthy standard. The core moves slowly, legacy leaves through deprecation, the SDKs catch up, and new capability enters through extensions that incubate, land, and eventually either settle into the core, stay modular forever, or get abandoned. Interceptors, Skills, and Triggers and Events are incubating now, while MCP Apps and Enterprise-Managed Authorization have landed.

Then Pedersen showed the move that actually matters. Tasks, the mechanism for long-running tool calls, went the other way this release. It came out of the core and into an extension. The framework is not only an on-ramp, it is an off-ramp, which means the core can shrink. Almost no standard in this industry can do that. Most only accrete, get heavier, and eventually collapse under the weight of everything nobody was willing to remove.

For you that translates into a procurement position. There is now a formal twelve month minimum deprecation window on roots, sampling, logging, Dynamic Client Registration and the legacy HTTP and SSE transport. Nothing you run today breaks, because old clients keep speaking the old protocol and servers can support both, and the panel's honest advice was that if you are doing ordinary tool calling and resource serving there is no reason to wait. You have a published timetable instead of a rumour, and you can budget against it.

Scored against five pillars

We assess composable and AI architecture against five pillars: Composable, Connected, Incremental, Open, and Autonomous. This release moves all five, which is rare enough to be worth naming.

Composable. Stripping state out of the server turns a swappable-in-principle agent layer into a swappable-in-practice one. Before this, replacing an MCP server meant inheriting its session assumptions. Now it means changing a hostname.

Connected. Hardened authorization and header-level routing are what let agent traffic cross a real enterprise boundary without a bespoke integration and an act of faith. Your gateway can finally treat agent calls as traffic rather than as an exception.

Incremental. This is the pillar the release serves best and the one most coverage missed. Dual protocol support plus a twelve month deprecation floor means adoption is a sequence of small moves against a published clock, not a cutover you have to defend in a steering committee.

Open. MCP now sits inside the Agentic AI Foundation at the Linux Foundation alongside goose and AGENTS.md, with Anthropic, Block, OpenAI, AWS, Bloomberg, Cloudflare, Google and Microsoft at the same table. Direct competitors co-governing a standard is the least exciting and most durable form of vendor neutrality available to you.

Autonomous. The returned form is what makes it defensible to let an agent do something rather than only read something. Every autonomy argument I have had with a risk committee eventually reduces to who approves the write, and that question now has a protocol-level answer instead of a bespoke one.

What to do this month

Ask your architecture team three questions.

Where are we still pinned to sessions. What on our estate is on the twelve month clock. Who owns the agent traffic our gateway currently cannot see.

If those answers come back quickly, you are ahead of this and I would spend the time on approval throughput instead, because that is where your program will actually stall. If they come back as a project, that project is your next quarter, and the people who wrote all of this will be at AGNTCon + MCPCon Europe at RAI Amsterdam on 17 and 18 September.

If you would rather have the answers than the questions, that is what the Architecture Review is. Two weeks, €7,500, vendor neutral, scored across all five pillars, ending in a prioritized roadmap your team can start on Monday. fidgetlabs.io/how-we-engage

Fidget Labs founder Kerrigan Baron serves as Delivery Lead for the MACH AI Exchange under contract with the MACH Alliance Tech Office.