The Model Context Protocol is moving toward a stateless protocol core.

GitHub's MCP Server added support for the next MCP specification on July 23, 2026, ahead of the July 28 specification release. The upcoming MCP revision removes the protocol-level session and allows requests to be handled more like ordinary HTTP traffic.

For agent builders, this is a serious architecture shift.

A stateless tool protocol can make MCP servers easier to scale, route, cache, and operate. It also forces teams to answer a harder question: if the protocol no longer carries session state, where does workflow state actually live?

1. Stateless MCP Makes the Tool Layer Cleaner

Earlier MCP implementations often depended on session setup, session identifiers, sticky routing, and shared session stores.

The next MCP specification changes that model. The release candidate removes the initialize handshake and the Mcp-Session-Id protocol-level session. It also allows any MCP request to land on any server instance, which reduces the need for sticky routing and shared session storage at the protocol layer.

This is good for infrastructure.

MCP servers can become simpler to scale horizontally. Gateways can route traffic more cleanly. Clients can cache tool lists more predictably. Tool calls become more self-contained.

However, this does not mean the agent experience becomes stateless. It only means the transport layer stops being the place where state is hidden.

Comparison of session-based MCP with sticky routing and stateless MCP where any server can handle self-contained requests
Stateless MCP removes protocol session dependencies, making the tool layer easier to route and scale.

2. Stateless Does Not Mean Contextless

A production SaaS agent still needs memory of the work being done.

It needs to know which user started the task, which account is affected, what records were checked, which tools were called, what approval is pending, and what action should happen next.

The MCP release candidate makes this distinction clear. Removing protocol-level session state does not prevent applications from managing state. It suggests that servers can return explicit handles, such as a basket_id or browser_id, and the model can pass that handle back in later tool calls.

This is useful because state becomes visible.

Instead of hiding workflow continuity inside transport metadata, the architecture can make state explicit, inspectable, and easier to govern. For SaaS teams, that is the important lesson.

The protocol can be stateless. The workflow cannot be careless.

Boundary between stateless MCP communication and stateful business workflow managed by the application layer
The MCP layer can remain stateless while the application layer owns workflow state, continuity, and business outcomes.

3. SaaS Products Need a Workflow State Layer

This is where SaaS architecture becomes important.

An agent working inside a product should not rely on the tool connector to remember business state. The connector should expose capabilities. The product or orchestration layer should manage workflow continuity.

That workflow state layer should track:

  • The active task
  • The user and role
  • The selected customer or record
  • The context used by the agent
  • The tools already called
  • The approvals requested
  • The current workflow status
  • The final action and audit trail

This layer is different from chat memory. It is operational memory.

If an agent is rescheduling an appointment, correcting an invoice, preparing a renewal action, or escalating a support case, the product needs durable state that survives retries, approvals, page refreshes, background jobs, and tool failures.

Without that layer, a stateless protocol may scale well, but the agent workflow may still break in production.

Agentic SaaS architecture with external workflow state layer, stateless MCP tools, governance controls, execution systems, and observability
A dedicated workflow state layer keeps task continuity, approvals, tool history, and audit evidence outside the stateless MCP tool layer.

4. Stateless Tools Make Governance More Important

When tool calls become easier to scale, agents can reach more systems more quickly.

That increases the need for action control.

A SaaS agent architecture should separate four concerns: tool access, workflow state, approval logic, and final execution. MCP can help standardize how agents connect to tools, but it does not decide whether an agent should be allowed to act.

That decision belongs in the product's governed execution layer.

A practical architecture looks like this:

  • The agent interprets the user request
  • The MCP layer exposes available tools
  • The workflow state layer tracks task context
  • The control layer checks permissions and approvals
  • The SaaS product executes the final action
  • The audit layer records what happened

At SaaStoAgent, we pay close attention to shifts like stateless MCP because tool connectivity is only one part of agentic transformation.

The real production challenge is not only whether an agent can call a tool. It is whether the system can preserve workflow state, enforce permissions, request approval, recover from failure, and leave behind a trace that engineering, product, and operations teams can trust.

Governed agentic SaaS architecture with stateless MCP tool layer, stateful workflow layer, governance controls, execution layer, outcome, and audit telemetry
Production agentic SaaS architecture keeps tools stateless, workflows stateful, and actions governed.