Two Wednesdays ago the Model Context Protocol froze its 2026-07-28 spec and made the core stateless: a compliant server stops holding your session between requests, which is exactly why it can now sit behind a plain round-robin load balancer instead of a sticky-session gateway. Two days later, on July 30, Microsoft Agent Framework shipped python-1.13.0 and dotnet-1.16.0 — and the headline feature is reusable session stores plus full persistence of a Foundry Responses session.
Put those two events on the same calendar and the release stops looking like a routine point bump. The protocol set the session down; the framework picked it up.
The one-line read: "stateless protocol" was never "stateless product." Statelessness at the wire just moves the session to your side of the boundary — and 1.13 is Microsoft standardizing the thing that holds it.
The state didn't disappear. It moved.#
This is the point founders keep missing about the stateless MCP core. Making the transport stateless does not make your agent stateless. A support agent still has to remember the last twelve turns; a coding agent still has to remember which files it opened. What changed is who is responsible for that memory. Before, a stateful server could quietly hold it for you. Now the state is an explicit handle you carry — and it has to be persisted somewhere on your side.
"Somewhere on your side" was, until this release, a per-app decision. Every team wired its own context provider, its own session table, its own resume logic. 1.13 replaces that with a reusable session store: a named, configured place you set up once and attach multiple agents or runs to. In Foundry-hosted form the session is a stateful, isolated sandbox whose filesystem — conversation history and uploaded files alike — persists across turns and idle periods, up to 30 days, with a 15-minute idle timeout that saves state and frees the compute until the session is referenced again. The agent resumes where it left off instead of rebuilding context from scratch.
That is the missing half of the 1.12 story. Recall that 1.12 turned your agent into an MCP server, not just a client — it could expose itself as a native MCP tool. Expose a stateless MCP surface, and the session it needs to feel continuous has to come from behind that surface. 1.13 is that "behind": the store that lets a stateless-looking agent still remember you.
The rest is production plumbing, pointed the same way#
Skim past the marquee feature and every other change in 1.13 is about running this thing in production rather than making it smarter:
- Observability that sees the cache. OpenAI cache-write token usage now shows up in the telemetry. If you have been surprised by a prompt-caching bill, this is the line item you could not previously see — the write side of the cache, not just the cheap reads. It pairs with the metric that actually decides an agent's bill: you cannot tune a hit rate you cannot measure.
- Feature-usage telemetry with a User-Agent. The framework now reports process-wide feature usage and identifies itself. For a vendor that is adoption data; for you it is a reminder to check what your runtime phones home before you ship it into a regulated environment.
- Ephemeral per-request instructions. You can attach instructions to a single Responses call without rebuilding the whole system prompt — a cheaper way to nudge one turn than re-sending a 4,000-token preamble.
- .NET: the GitHub Copilot backend graduated to stable. On dotnet-1.16.0 the GitHub Copilot agent moved out of preview, joining the TodoProvider and AgentModeProvider samples. If you wanted to build on Copilot as an agent backend without pinning around a release candidate, that pin is gone.
None of these is a new orchestration trick. All of them are the unglamorous work of making a long-running agent survivable — the same shape as checkpointing an agent to object storage or the broader question of checkpointing versus context management for loops that run for hours.
What to do with it#
If you are already on the Agent Framework 1.x line, take the upgrade — it is additive. But treat the reusable session store as an architecture decision, not a default you flip on:
- Decide where session state physically lives. In-memory is fine for a demo and fatal in production, because it dies with the process. A durable backend (Foundry's hosted sandbox, or your own store) is what survives the restart that a stateless transport makes more frequent, not less.
- Name and reuse one store, don't scatter providers. The whole point of the abstraction is that two agents can attach to the same session. Wiring a fresh provider per app throws that away and leaves you with the bespoke sprawl 1.13 was meant to end.
- Turn the cache-write metric on and watch it. Now that the write side of the prompt cache is visible, look at it before you conclude caching is saving you money — a low reuse rate means you are paying to write a cache nobody reads.
The larger pattern is worth saying plainly, because it will keep repeating as the stack matures. Every time a lower layer goes stateless "for scale," the state does not evaporate — it falls to the next layer up, and someone has to build the thing that catches it. The MCP spec dropped the session on purpose. This week, the framework caught it. Whichever layer you build on, know which one is holding your users' state — because that is the piece that decides whether your agent remembers them tomorrow.
