Microsoft Agent Framework — the GA successor that folded AutoGen and Semantic Kernel into one supported line — shipped python-1.12.0 and dotnet-1.14.0 today, July 21, 2026, on the near-weekly cadence it's kept all summer. If you skim the release notes looking for a smarter planner or a new orchestration pattern, you'll miss the point. This is a shape release, not a smarts release, and two of the changes quietly redraw where your agent sits in the stack.

The one-line read: 1.12 turns the framework inside-out toward production — your agent becomes an MCP server, and its memory stops dying when the session ends.

1. Your agent is now an MCP server, not just a client#

Until now, a Microsoft Agent Framework agent talked to the outside world as an MCP client: it discovered tools on remote servers and called them. Version 1.12 adds app-owned MCP hosting helpers — a way to expose your own agents and workflows as native MCP tools. That flips the arrow. Any MCP client — Claude, another agent runtime, an IDE — can now call your agent the way it calls any MCP server.

This matters more than it sounds. It means an agent you built for one product can be published as a tool inside someone else's agent without a bespoke API. It's the composability story the whole ecosystem has been circling: agents-as-tools, discovered and called over a standard wire. If you've been following Microsoft's progressive MCP disclosure work — discover, load, unload to fit a tool budget — this is the other half: not just consuming tools frugally, but being one.

2. Memory that outlives the session#

The second headline is an alpha Azure Cosmos DB semantic-memory context provider with fact extraction and user profiles. Instead of memory that lives and dies inside a run, your agent can extract durable facts from a conversation and write them to a Cosmos-backed profile that persists across sessions and machines.

The word to hold onto is alpha. This is a preview provider — pin the version, expect the surface to move, and don't wire it into a load-bearing path yet. But the direction is unmistakable: memory is graduating from a per-session scratchpad to a persistent, queryable profile store. That's the same move MCP itself is making with its 2026-07-28 stateless core — state stops being tied to a connection and moves into an explicit store any instance can read.

3. The unglamorous half: experimental → stable#

Most of the release is a hardening pass, and for anyone already shipping on the 1.x line, that's the part to act on. In Python, declarative workflows, the tool-approval middleware, and the file memory provider graduated from experimental to stable. In .NET, message injection, the todo and agent-mode providers, and HarnessAgent all lost their experimental status.

.NET 1.14 also tightened one safety detail that's easy to get wrong: tool-approval responses now bind to the specific approval request that surfaced them, rather than being loosely matched. If you've built a human-in-the-loop gate where an operator approves a tool call, this closes the window where an approval could land against the wrong request. There are also workflow session and message-ordering fixes, a null-MessageTtlSeconds Cosmos chat-history correction, and Valkey NuGet publishing.

None of that is exciting. All of it is the difference between a demo and a system you can page someone about at 3 a.m.

What a founder should do this week#

The framework didn't get smarter today. It got more hostable and more stateful — and if you're choosing a production runtime, that's the axis that actually decides things. For the head-to-head on where it lands against the alternatives, we keep Microsoft Agent Framework vs LangGraph vs Claude Agent SDK current.