Nine days after 1.12 turned a Microsoft Agent Framework agent into an MCP server with persistent memory, the project shipped python-1.13.0 and the aligned dotnet-1.16.0 on July 30, 2026. If 1.12 was a shape release — where your agent sits in the stack — 1.13 is a recoverability release. It answers a plainer question: when a run that's been going for an hour falls over, what happens next?
The one-line read: 1.13 makes a long agent run survivable — reusable session stores hold the whole session, and checkpoints now replay from the original input and the human approvals, so a restart doesn't re-ask your operator to sign off on tool calls they already approved.
1. Reusable session stores that hold the whole session#
The first change is quiet and load-bearing: reusable session stores that persist complete Foundry Responses sessions. Until now, keeping a session alive across process boundaries meant stitching together your own persistence around the Responses API. 1.13 gives you a store you can hand a session to and get it back — the full session, not a reconstructed approximation.
That's the difference between "we log enough to debug" and "we can rehydrate this run on a different box." For anyone running agents behind a queue, on spot instances, or through a deploy that cycles pods, it's the piece that lets a session outlive the machine it started on.
2. Checkpoints that replay through the human, not around it#
The headline is the workflow change: checkpoints are now fully replayable from the initial input and the human-in-the-loop responses. Read that twice, because the second half is the interesting part.
Plenty of frameworks can checkpoint a workflow. The trap in a human-in-the-loop system is what happens on replay: if the recovered run can't reproduce the approvals a human already gave, it either stalls waiting for input that will never come, or — worse — re-issues the approval prompts and asks a person to sign off a second time on tool calls they already authorized. 1.13 closes that gap. Approval decisions are preserved across Responses API continuations, so a replay carries the human's earlier "yes" forward instead of stopping to ask again.
A checkpoint that can't reproduce a human's approval isn't a recovery point — it's a second interruption. 1.13 makes the approval part of the replay.
If you've built anything with a gate — spend approvals, "confirm before you email the customer," a review step before a deploy — this is the release that makes those gates survive a restart. It's the operational half of the handle-every-stop-reason discipline that keeps a loop from silently dropping work.
3. The supporting cast, all pointed the same way#
The rest of the release reinforces the same axis:
- Process-wide feature-usage telemetry with first-party User-Agent reporting, plus OpenAI cache-write token usage now exposed in observability — so you can see what a long run actually costs, cache writes included, instead of guessing.
- Ephemeral per-request instructions in the Responses API — inject a one-off instruction for a single turn without polluting the persistent session.
- A core fix that improves message ordering and function-call atomicity during compaction — the failure mode where trimming context mid-run scrambles the tool-call record. This is the same hazard the context-editing vs compaction tradeoff keeps surfacing: compaction is only safe if it doesn't tear a function call in half.
What a founder should do this week#
- Run agents measured in minutes, not seconds? Upgrade. The value here is that a restart stops being a data-loss event. Wire the reusable session store into your run before you wire anything else.
- Have a human-in-the-loop gate? This is the release that makes your approvals durable. Test the crash-and-replay path explicitly: kill the process after an approval and confirm the replay doesn't re-prompt.
- On the fence about the framework? 1.12 and 1.13 read as one arc — hostable, stateful, now recoverable. That's the production checklist for long-running agents that run long enough to crash, and it's the same direction the MCP stateless core is pushing the whole ecosystem.
The framework didn't get smarter on July 30. It got harder to lose — and for anyone whose agent does real work over real time, that's the property that decides whether it's a demo or a system. For where it lands against the alternatives, we keep Microsoft Agent Framework vs LangGraph vs Claude Agent SDK current.
