Microsoft Agent Framework 1.22.0: a persistent memory provider and a trust boundary you can't bypass

What it is

Microsoft Agent Framework is an open-source Python/.NET SDK for building agents and multi-step workflows. The 1.22.0 Python release, dated October 15, 2026, ships two things that matter for anyone running an agent loop in production: a dedicated Azure Cosmos DB memory provider package, and a hardened AG-UI trust model that fails closed when a caller is misconfigured.

The next-work-session test

Concrete scenario: you have a chat-style agent behind an AG-UI endpoint, and users complain it forgets everything between sessions. Today you probably bolt on Redis or a vector store yourself, and your "isolation key" is a header the client sends.

After upgrading, two things change in that session. First, you can drop in CosmosMemoryContextProvider instead of writing your own persistence layer. Second, your scope resolver has to return a real string — None, an empty string, or another type fails with an HTTP 500 configuration error before the endpoint accesses snapshots, approval state, or context providers. That's the change: a class of "user A sees user B's thread" bugs becomes a loud startup failure instead of a silent prod incident.

Pricing

The framework itself is open source (MIT) on GitHub. The Cosmos memory provider depends on Azure Cosmos DB, which Microsoft bills separately — autoscale, provisioned, and serverless modes are all documented on the Cosmos DB pricing page. The Cosmos-backed memory itself is a new preview integration that gives Microsoft Agent Framework agents durable, cross-session memory backed by Azure Cosmos DB, so expect the usual preview caveats on SLA. Pricing for your workload: unverified until you model RU/s against your actual turn volume and embedding size.

What we'd actually use it for

Narrower than the pitch. We'd use it for:

• A single production agent that needs per-user long-term memory and already lives in Azure.
• Replacing a hand-rolled "store the last N turns in Postgres" hack.
• Getting AG-UI's scope resolver wired up correctly on a greenfield service, where failing closed is a feature, not a migration tax.

We would not rip out an existing Redis or pgvector memory layer just to adopt this. The ROI isn't there yet.

Limits

A few things to know before you commit:

• It's a breaking release. The 1.22.0 notes flag breaking changes, and warns about persisted-state compatibility. If you already persist AG-UI thread state, read the migration notes before upgrading in place.
• The memory provider has known rough edges. An open bug reports that CosmosMemoryContextProvider forwards its two retrieval parameters, top_k and min_confidence, to the memory toolkit on every turn without validating either one. Out-of-range values can silently disable retrieval — validate your config in your own eval harness, don't trust the defaults.
• AG-UI accepts a lot of client-controlled input. The hardening PR itself notes that AG-UI accepts client-controlled thread state, protocol events, A2UI context, approval identities, and multimodal inputs across several server-authority boundaries. The new trust model helps, but you still own threat-modeling your tool calls and approvals.
• Cosmos lock-in. This provider is Azure-only. If you're multi-cloud or on AWS, use the Redis provider or roll your own against the memory interface.
• Preview status. Memory APIs are still shifting — a separate issue tracker shows ongoing work on episodic and procedural retrieval APIs lagging the Memory Toolkit, so expect churn.

Try it if

• You're building on Azure and want managed, durable agent memory without writing the persistence layer.
• You run an AG-UI frontend and want client-supplied scopes enforced at the framework layer, not in your handlers.
• You already pinned to agent-framework 1.21.x and have a changelog-reading habit.
• You have evals wired up and can catch a regression from the breaking changes before it reaches users.

Skip it if

• You're happy with your current memory store (Redis, pgvector, Mem0) and don't need Azure-native.
• You're on .NET only — this release's headline additions are Python-side; check the .NET release notes separately.
• You can't absorb breaking changes to persisted state in the next sprint.
• You're pre-production and still iterating on the agent's prompt — memory and strict trust boundaries are a step-two problem.

For the full changelog and the exact list of packages that moved, read the 1.22.0 release notes on GitHub.