In this blog post Microsoft Agent Framework 1.22 and .NET 1.25 Production Guide we will explain what the latest release notes mean for organisations running AI agents in production, where the upgrade risks sit, and what technology leaders should ask their teams before approving deployment.
The problem is rarely getting an AI agent to work in a demonstration. The real challenge is keeping it reliable when it remembers conversations, calls business systems, requests approval and continues work across application updates.
What Microsoft Agent Framework actually does
Microsoft Agent Framework is a software foundation for building AI agents in Python and .NET. An agent combines an AI model with instructions, business data and tools that let it perform actions rather than simply generate text.
For example, an agent might read a support request, check a customer record, prepare a response and ask an employee for approval before updating the service platform. The framework manages the messages, tools, approvals, stored state and workflows connecting those steps.
Python and .NET are simply two ways for development teams to build on the framework. Python is common in AI and data teams, while .NET is widely used in established Microsoft business applications. They do not need identical version numbers, but organisations should understand how each release affects shared data and integrations.
The biggest Python 1.22 issue is stored-state compatibility
Python 1.22 can read records created by earlier releases. However, older runtimes cannot always read new records containing the newly supported hosted or merge_mode fields.
In plain English, once a new worker saves certain conversation messages, streaming updates or workflow checkpoint data, an older worker may no longer understand it. That makes a normal rolling deployment, where old and new application instances run together temporarily, potentially unsafe.
This does not affect every stored record. Plain session details and checkpoints without serialised messages or response updates are unaffected. The difficulty is proving exactly what your application stores before the upgrade begins.
Why this matters to the business
Suppose a 200-person professional services firm uses an agent to classify requests and prepare client documents. During a gradual rollout, half the workers run Python 1.21 and half run 1.22 while sharing the same session database.
If a 1.22 worker writes new-format state and an older worker later receives that session, the job could fail halfway through. The result may be duplicated work, abandoned requests or employees manually rebuilding the conversation.
This is why the release should be treated as a data migration decision, not just a package update. If you need more detail on managing frequent versions, our Agent Framework release cadence and version governance guide explains how version pinning and controlled promotion reduce this risk.
Python 3.15 support does not mean every component is ready
Python 1.22 adds Python 3.15 support to the core framework and main package. Some optional packages, integrations and features still have dependency limitations, however.
Technology leaders should resist the temptation to combine an Agent Framework upgrade, a Python runtime upgrade and application changes in one deployment. When something fails, the team will struggle to identify which change caused it.
Python 3.10 remains supported and tested in this release but is deprecated. New environments should therefore use Python 3.11 or later, while existing environments should have a planned and separately tested runtime upgrade.
A safer version-pinning approach
agent-framework==1.22.0
agent-framework-core==1.22.0
# Pin every optional connector separately.
# Do not assume all packages share the same maturity level.
Exact version pinning prevents an automated build from silently installing a newer release. It also gives your team a repeatable build for testing, incident investigation and rollback.
Python 1.22 also improves integration control
The release adds configurable service addresses for OpenAI and Ollama chat clients. A service address tells the agent where to send AI requests, which is useful when an organisation routes traffic through an approved gateway, private service or controlled internal endpoint.
The Foundry integration also surfaces OAuth consent requests in non-streaming responses. OAuth consent is the permission screen used when an agent needs delegated access to systems such as Microsoft Graph. Making that request visible helps avoid situations where an agent appears to stop because the user never saw the required approval step.
These may sound like developer conveniences, but they support better security boundaries and fewer failed user interactions. They also make it easier to keep agent traffic inside approved Azure and cybersecurity controls.
What .NET 1.25 changes for production systems
The .NET 1.25 release includes several changes aimed at reducing workflows that wait forever or return incomplete information. One important improvement automatically rejects tool-approval requests that never receive a response.
A tool approval is the human checkpoint before an agent performs a sensitive action. Without a clear rejection path, an abandoned request can leave a workflow open indefinitely, consuming resources and confusing users about whether an action occurred.
The release also adds support for closed-list workflow questions. These let a workflow ask a user to choose from controlled options rather than relying on unrestricted text, which can improve consistency for decisions such as approve, reject or send for review.
Other changes include richer Microsoft Purview results, with citations and error details included in policy checks, an updated Agent-to-Agent package, and fixes for continuation tokens used with OpenTelemetry. OpenTelemetry is the monitoring standard that helps teams trace what an agent did across models, tools and workflows.
Pay attention to the .NET breaking change
.NET 1.25 separates Cosmos chat metadata from the database partition-key strategy. A partition key is the field Azure Cosmos DB uses to distribute and retrieve stored records efficiently.
If your agent stores conversations or session data in Cosmos DB, do not assume the existing configuration will behave identically. Test how records are written, located and isolated between users or customers.
This is especially important for Australian organisations handling personal or commercially sensitive information. A technically successful upgrade is still a failure if it weakens tenant separation, retention controls or audit evidence.
Use a staged production-readiness process
A sensible upgrade does not need months of governance. It does need a documented sequence that prevents one enthusiastic developer from changing production packages without checking stored state and business workflows.
- Inventory the application. Record every Agent Framework package, Python or .NET runtime, model provider, database, tool and preview component.
- Map stored state. Identify where conversations, checkpoints, response updates, approvals and continuation tokens are saved.
- Clone representative data. Test the upgrade against anonymised copies of real session shapes rather than clean demonstration conversations.
- Test interrupted work. Restart workers during tool calls, approval requests and long-running workflows to confirm that jobs recover safely.
- Separate old and new state. For Python 1.22, avoid mixed-version workers writing to the same affected store.
- Confirm rollback limits. Document whether rollback means changing the application version, restoring the database or migrating new records.
- Monitor business outcomes. Track completion rates, approval timeouts, duplicate actions, tool failures and cost per completed request.
Our earlier release and upgrade governance guide provides a broader operating model. Organisations using MCP, which is a standard way for agents to connect to external tools, should also review the A2A and MCP production governance guide.
The decision is not simply whether to upgrade
Python 1.22 and .NET 1.25 contain useful reliability, integration and approval improvements. The Python stored-state change and the .NET Cosmos configuration change mean neither release should be pushed directly into production without targeted testing.
The business outcome should be fewer abandoned workflows, safer approvals, predictable recovery and a lower chance of an AI agent losing or duplicating work. Those outcomes matter far more than having the newest package number.
CloudProInc combines more than 20 years of enterprise IT experience with practical work across Azure, Microsoft 365, Microsoft Defender, OpenAI, Claude and modern agent platforms. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations assess both the application changes and the security controls around them.
If you are unsure whether your Agent Framework upgrade plan protects stored state, approvals and rollback options, we are happy to review it with you before it reaches production — no strings attached.