MCP’s new stateless core removes a scaling burden from the protocol. It does not remove state from the business process.
That distinction matters for enterprises adopting the Model Context Protocol’s July 2026 specification. Requests no longer depend on a transport session connecting a particular client and server. Gateways can route and meter calls using standard headers, and long-running operations can use explicit task handles.
All of this makes MCP easier to scale. But it also makes one architectural responsibility harder to ignore: the application still needs to know what operation is underway, who authorized it, what has already happened and what to do when something fails.
My argument is that consequential MCP workflows need a durable execution record outside both the model context and the transport. Otherwise, removing protocol state can make the connection more scalable without making the underlying workflow any more reliable.
An onboarding agent makes the missing state visible
Consider an employee-onboarding agent. It reads an approved hiring record, creates the employee’s identity, assigns a laptop, requests application licences and starts payroll enrollment. The identity provider succeeds, but the licence service times out. Before the workflow resumes, the hiring manager changes the employee’s start date and the original approval expires.
A stateless tool protocol handles the next request cleanly. The harder question is what that request means. Is the next licence call a retry, or a new order? Did the first request fail, or did the service accept it before the timeout? Is the manager’s original approval still valid after the start-date change? If the agent reconstructs the workflow from its conversation history, how does it distinguish something it never observed from something that never happened?
None of the obvious artifacts solves this on its own. The model transcript tells you what the agent saw. An OAuth token tells you something about delegated access. An MCP task ID identifies a piece of asynchronous work. What is still missing is the business transaction: what was approved, under which policy, which side effects are known to have completed, which remain uncertain, and what should happen next.
What the stateless core actually changes
The July 28 release removes the protocol-level initialization exchange and session identifier. Each request now carries the context it needs, and clients that want to inspect server capabilities first can use the optional server/discover call. Streamable HTTP requests also expose method and resource names in headers, allowing gateways and rate limiters to make routing decisions without parsing the JSON-RPC body.
Operationally, this is a substantial simplification. A basic MCP request no longer needs sticky sessions or a shared protocol-session store just to reach the right server instance. More importantly for this argument, workflow state can no longer disappear quite so easily into the transport layer.
The Tasks extension shows the other half of the design. Long-running operations can have explicit task IDs and observable states such as working, input_required, completed, failed and cancelled. The server must create the task before returning its handle, and the specification recommends that clients persist task IDs so polling can resume after a crash or restart. Tasks therefore reintroduce state where state is actually needed, but as an explicit protocol object rather than an implicit client-server session.
A task record still isn’t a business transaction record. Knowing that a task is working or completed does not tell you whether a manager’s approval is still valid, whether a timed-out downstream API actually performed the operation, or whether a later business change requires compensation.
Authority must survive a retry without becoming permanent
The July release also strengthens MCP’s authorization model, including issuer validation and issuer-bound client credentials. The current roadmap describes authorization as a major part of the protocol’s recent enterprise-readiness work.
RFC 9207 addresses one specific OAuth problem: authorization-server mix-up attacks. When a client works with multiple authorization servers, it needs to verify which issuer produced an authorization response before proceeding.
That still answers only part of the enterprise authorization question. A valid credential can establish where the authorization came from and what resource access it permits. The onboarding workflow must separately decide whether this actor may perform this action now, with these parameters, under the current business policy.
That decision belongs in deterministic policy enforcement around the tool, not in the model’s reasoning. OWASP’s Excessive Agency guidance points in the same direction: constrain tool functionality and downstream permissions, execute actions in the user’s context where appropriate, and require human approval for high-impact operations.
A gateway can be one enforcement point, but it needs structured evidence about the workflow and its authority. It should not have to infer either from the agent’s explanation of what it thinks it is doing.
The execution record should carry four kinds of evidence
I would put four things in that record:
- Intent: a stable operation ID, the requested outcome and the permitted scope.
- Authority: who or what approved the operation, the policy decision behind that approval and when it expires.
- Effects: idempotency keys, attempted tool calls and confirmed changes in systems of record.
- Recovery: retry rules, compensation steps, escalation ownership and terminal conditions.
This is more than observability. A trace helps explain what happened. The execution record also helps decide what is allowed to happen next.
On a license retry, for example, the workflow can reuse the original idempotency key, determine whether the first request succeeded where possible, and revalidate the approval before making another change. If the start date has changed, it can stop and request a new decision instead of carrying stale authority forward.
None of this is free. Durable workflow records require storage, schemas and ownership. Idempotent tool contracts require cooperation from application teams. Compensation is difficult when several SaaS products participate in a process that none of them sees as a single transaction. Approval expiry can also slow automation. But those are engineering costs you can reason about. A model’s reconstruction of what probably happened is not an equivalent control.
Stateless infrastructure does not mean simpler workflows
Managed runtimes and stateless protocols remove real infrastructure work. They can make compute replaceable, eliminate transport-session affinity and give tools stable interfaces. But none of that simplifies the business transaction itself. If an onboarding workflow touches identity, hardware, licensing and payroll, those systems still have independent failure modes and different notions of completion.
The same limit applies to the control plane. Centralized discovery, policy and audit are useful, but a gateway cannot make a downstream API idempotent. Nor can it decide, in the abstract, how to unwind a laptop order after payroll enrollment has already started. Those behaviours have to be designed with the applications that own the underlying business state.
Run the kill-and-resume test
There is a simple production-readiness test for this architecture: kill it between two consequential tool calls. Terminate every replaceable compute component—the client process, model session, gateway worker and MCP server instance—and resume using only durable records.
A successful recovery should be able to identify the original operation, revalidate its authority, determine which effects definitely happened and which remain uncertain, avoid duplicate side effects, obtain fresh approval where necessary, and either complete or compensate the workflow. The same record should give an auditor enough information to reconstruct why those decisions were made.
If the workflow needs a surviving chat session, an operator’s memory or the model’s interpretation of old prose to recover safely, the architecture is not ready. Stateless MCP removes transport state that enterprises no longer need. It doesn’t remove the state inherent in the business process. Production systems need to make that state just as explicit as the protocol has made its own.