MCP Went Stateless. Your Agent Architecture Still Has State.

MCP just became much easier to run like ordinary web infrastructure.

The Model Context Protocol 2026-07-28 specification removes protocol-level sessions, retires the initialisation handshake, and turns remote MCP calls into self-contained requests that can land on any server instance behind a standard load balancer.

The announcement became one of the hottest developer-infrastructure discussions on X within hours. That attention is justified. The release addresses real problems that teams encountered when they tried to move MCP servers from local experiments into shared, production-grade services.

But the most important architectural point is easy to miss:

MCP is now stateless. Your agent application is not.

For founders, CTOs, and product teams, this is more than a protocol upgrade. It is an opportunity to decide where workflow state, identity, authorization, recovery, and operational ownership should actually live.

What changed

Previous MCP versions established a session between client and server. The client performed an initialize exchange, the server could issue a session identifier, and some interactions depended on a held-open bidirectional channel.

That model worked, but it complicated remote operation. Session affinity, reconnect behaviour, shared session storage, long-lived connections, and uneven load could all become infrastructure concerns.

The new specification removes that protocol-level session:

every request carries its protocol version, client identity, and capabilities;
a request can be handled by any compatible server instance;
gateways can route and meter calls using method and tool-name headers;
list responses include cache hints and deterministic ordering;
Multi Round-Trip Requests support interactions that need further input without keeping a bidirectional stream open;
a formal extensions framework covers MCP Apps, Tasks, and Enterprise Managed Authorization;
authorization receives several OAuth and issuer-validation improvements;
deprecated features get a minimum twelve-month migration window.

This is a meaningful simplification. Remote MCP servers can fit more naturally behind ordinary load balancers, in serverless platforms, and across horizontally scaled deployments.

It does not remove the hard parts of a production agent system. It makes them more visible.

Stateless transport is not stateless work

An agent that checks an invoice, researches a supplier, changes a repository, or coordinates a support case usually performs a workflow rather than one isolated function call.

That workflow may need to remember:

which customer or tenant owns the operation;
which files or records have already been processed;
which approval is outstanding;
which tools have been called;
which side effects have succeeded;
whether a retry is safe;
where a long-running task should resume;
who can inspect, cancel, or take over the work.

Removing an implicit transport session does not remove any of this state.

The specification explicitly allows a tool to return a handle that the model supplies in later calls. That is useful, but the handle is only a reference. The application still needs a durable, authorised state model behind it.

This is good architecture. Hidden session state is convenient until a server restarts, a request reaches another instance, or an operator needs to reconstruct what happened. Explicit state can be stored, inspected, migrated, expired, and recovered deliberately.

The danger is treating a visible handle as an architecture by itself.

Decide where state belongs

Before upgrading, inventory every place the current system relies on continuity.

Some state belongs in the agent orchestrator: the current plan, conversation context, tool results, and model-facing progress. Some belongs in the business system: an order status, approval record, support ticket, or deployment request. Some belongs in durable workflow infrastructure: retry counters, leases, deadlines, checkpoints, and cancellation state.

Avoid creating a second, shadow copy of business truth inside the MCP server.

If an invoice is approved, the accounting or workflow system should own that fact. If a deployment requires authorisation, the delivery platform should own the approval. The MCP server should expose a controlled capability, not become an undocumented system of record simply because the agent needs continuity.

A practical design separates three concerns:

Agent context — information the model needs to choose the next action.
Workflow state — durable progress, retries, ownership, and recovery.
Business state — authoritative records and consequential decisions.

They may interact, but they should not be collapsed into one opaque session object.

Gateways can see more, but tools still own authorization

The new Mcp-Method and Mcp-Name headers allow a gateway to identify a call such as tools/call for a particular tool without parsing the JSON body.

That is valuable for:

routing;
rate limits;
coarse access policies;
cost attribution;
observability;
blocking disallowed tool categories.

It is not sufficient for resource-level authorization.

A gateway may know that a user can call get_customer_record. It usually cannot decide whether that user may access customer 4817, whether the requested fields contain sensitive data, or whether the operation crosses a tenant boundary. Those decisions require the tool to validate the authenticated principal against the requested object and the current business policy.

Production architecture therefore needs both layers:

the gateway decides whether this identity may reach this capability under these operational limits;
the tool decides whether the identity may perform this exact action on this exact resource.

Do not trust a client-supplied identity field merely because every request is self-describing. Identity must be bound to authenticated credentials and propagated through a verifiable chain.

Long-running Tasks are business operations

Moving Tasks into a formal extension is one of the release’s most useful changes.

Long-running agent work is common: analyse a codebase, generate a report, reconcile a dataset, prepare a migration, or wait for human approval. A task abstraction gives these operations a cleaner lifecycle than one long connection.

However, a production Task needs more than a status endpoint.

Define:

a stable task identifier;
tenant and owner;
idempotency rules;
allowed state transitions;
progress and last heartbeat;
cancellation semantics;
retry and timeout policy;
resulting artefacts;
human approvals;
audit history;
retention and deletion rules.

If the same request arrives twice, the system must know whether to resume, return the existing result, or start a new operation. If a worker dies, another worker should be able to continue safely. If an operator cancels a task, the cancellation must propagate to downstream work rather than merely changing a database label.

This is workflow engineering, not protocol plumbing.

Migration should be parallel and observable

The new release includes breaking changes. Teams that depend on session identifiers, server-initiated calls, legacy HTTP+SSE, Roots, Sampling, or Logging need a deliberate migration.

Do not upgrade every client and server in one coordinated jump.

A safer path is:

Inventory clients, servers, SDK versions, transports, and deprecated capabilities.
Add protocol-version telemetry so you can see which paths are actually in use.
Make session-dependent state explicit and durable.
Test replay, duplicate delivery, instance changes, and worker restarts.
Run old and new protocol versions side by side where the implementation permits it.
Migrate low-risk consumers first.
Compare error rates, latency, cache behaviour, authorization decisions, and task recovery.
Remove legacy paths only after real traffic proves they are unused.

The twelve-month minimum deprecation window is breathing room, not a reason to postpone discovery. The first step is understanding which assumptions your current integration makes.

What to ask before adopting MCP 2026-07-28

For a production review, ask:

Which state currently depends on an MCP session identifier?
Which system is authoritative for each business decision?
Can any compatible instance handle the next request safely?
Are retries and duplicate calls idempotent?
Is identity cryptographically bound to each request?
Which policies live at the gateway, and which must remain inside the tool?
Can long-running tasks survive restarts and operator handover?
Can we reconstruct every consequential action across instances?
Which deprecated capabilities are still in use?
Can clients and servers migrate independently?

If these questions have clear answers, the new specification should reduce infrastructure complexity.

If they do not, the upgrade has already delivered value: it has exposed architecture that was previously hidden inside a session.

The real benefit is operational clarity

MCP 2026-07-28 is not important because “stateless” is fashionable. It is important because the protocol is moving closer to established web and distributed-systems patterns: explicit requests, ordinary routing, cacheable discovery, formal extensions, and planned deprecation.

That creates a better foundation for production agents.

The teams that benefit most will not simply update an SDK and declare the work complete. They will use the change to make state explicit, keep business truth in the right system, separate gateway policy from resource authorization, and give long-running work a durable operational model.

Stateless infrastructure scales more easily.

Explicit architecture is what makes it trustworthy.

McDougall Digital helps teams design and operate AI-supported software systems beyond the prototype stage. If your MCP integration is moving from local tools to shared production infrastructure, we can review the state model, authorization boundaries, migration path, and operating model before they become expensive constraints.