MCP 2026-07-28: Designing Stateless Agent Infrastructure
What MCP’s stateless core, cacheable discovery, explicit routing, and extension model change for teams operating agent tools at production scale.
The 2026-07-28 MCP release moves the protocol toward a stateless request-and-response core. For platform teams, that is more than a transport detail: it changes how tool servers scale, how gateways route traffic, how clients cache discovery, and where workflow state should live.
Keep workflow state where the workflow can own it
A tool server should not need a sticky session simply to understand the next request. Keep durable task state in an explicit application store or task resource, and make each tool call carry enough identity and context to be validated independently. That makes retries, horizontal scaling, and recovery easier to reason about.
- Design every request so any healthy server instance can handle it
- Use explicit state handles for long-running or resumable work
- Treat cache hints and deterministic tool lists as production performance features
- Route and authorize using clear method and tool identity at the gateway
- Plan migrations around the published deprecation window instead of waiting for a breaking deadline
Stateless does not mean context-free
Agents still need plans, artifacts, permissions, and audit history. The improvement is that these concerns become visible resources rather than hidden transport memory. That separation helps teams inspect a task, resume it after failure, and scale the tool layer without coupling business state to one connection.
Adopt the release as an infrastructure change
Inventory session assumptions, discovery behavior, authorization checks, and long-running tasks before upgrading SDKs. Validate one representative workflow end to end, then expand. A protocol upgrade is successful when reliability and operability improve—not merely when the version string changes.
Primary sources
First-party documentation and announcements used to ground this field note.
