In this blog post Microsoft Agent Framework Production Release and Pinning Guide we will explain how to keep business-critical AI agents stable when framework updates are arriving faster than your normal change process can comfortably handle.
The problem usually appears after a successful pilot. An agent moves into production, starts accessing company data and becomes part of a real workflow. Then an automatic package update changes how it calls tools, stores conversations or resumes unfinished work.
What looked like a routine software update can suddenly interrupt customer service, finance approvals or employee onboarding. The goal is not to avoid updates. It is to decide what changes, when it changes and how quickly you can recover.
What Microsoft Agent Framework actually does
Microsoft Agent Framework is the software layer used to build AI agents and multi-agent workflows in Python and .NET. In plain English, it connects an AI model to instructions, business data, software tools, memory, approval steps and other agents.
The model provides the reasoning, while the framework controls how work gets done. It can allow an agent to search an approved knowledge base, update a business system, pause for human approval or hand a task to another specialised agent.
This makes the framework more than a developer library. Once an agent reaches production, it becomes part of the organisation’s operational control environment.
A fast release cadence is not an upgrade schedule
As at 19 October 2026, Microsoft Agent Framework has separate Python and .NET release streams. Python 1.22 and .NET 1.25 were released on 15 October, only a week after Python 1.21 and .NET 1.24.
This recent pace shows why technology leaders should not assume releases will follow a predictable monthly calendar. Teams should monitor each release, but that does not mean every release should immediately enter production.
A practical approach is to use three lanes:
- Emergency lane: Critical security and reliability fixes receive immediate review and accelerated testing.
- Standard lane: Useful fixes and supported features enter a planned monthly upgrade window.
- Deferred lane: Experimental connectors, preview features and changes without a clear business benefit remain outside production.
This extends the process covered in our Agent Framework release cadence and version governance guide. The important next step is pinning the complete production configuration, rather than recording only the headline framework version.
What your production team should pin
1. Framework packages and dependencies
Pin the exact Agent Framework version instead of accepting “latest” or a version range. Also create a lock file, which records the precise versions of supporting software packages installed with it.
A basic Python input file may look like this:
agent-framework==1.22.0Your delivery pipeline should then generate and retain a full dependency lock file. For .NET environments, use central package management or an equivalent method to record the exact approved package versions.
This prevents a rebuild from quietly installing a newer supporting component than the one your team tested.
2. Model deployment and configuration
Pinning the framework while leaving the AI model unspecified only solves half the problem. Record the model deployment, model version where available, response settings, safety controls and maximum processing limits.
A different model can select tools differently, produce longer answers or interpret an approval instruction in another way. These changes may affect cost, accuracy and risk even when the application code remains untouched.
3. Prompts, instructions and approval rules
An agent’s system instructions should be treated like application code. Store them in version control, require review and connect each production release to the exact instruction set it passed testing with.
The same applies to human approval rules. Record which actions require approval, who can approve them and what happens when nobody responds.
4. Tools, APIs and MCP servers
AI agents often use MCP, or Model Context Protocol, which is a standard way for an agent to connect with approved tools and data sources. They may also communicate with other agents using A2A, meaning agent-to-agent communication.
Pin the version of every tool definition, MCP server, API contract and authentication scope. A framework upgrade may be safe by itself but fail when paired with an untested tool change.
For more detail on controlling those connections, see our production guide for A2A and MCP governance.
5. Stored state and checkpoint formats
This is the item most likely to be missed. Agent state can include conversation history, unfinished workflows, tool results and checkpoints used to restart long-running work.
Python 1.22 introduced an important compatibility consideration. The newer runtime can read relevant records created by earlier releases, but older workers may not understand some records written by 1.22.
That means running old and new workers against the same production state store during a gradual deployment can create rollback problems. Before upgrading, identify which data is stored, take a recoverable backup and test whether both forward migration and rollback are safe.
6. Infrastructure, identity and permissions
Record the container image, operating system, cloud configuration, service identities and access permissions used by each agent. Do not give an agent broad access simply because that makes the pilot easier.
Microsoft Defender and Wiz can help identify exposed workloads, excessive cloud permissions and configuration risks. However, monitoring tools cannot replace a clear decision about what each production agent is permitted to read or change.
Test business behaviour, not just whether the agent starts
A successful deployment test often proves only that the agent can launch and return an answer. Production testing must go further.
Build a repeatable evaluation set covering the tasks that matter to the business:
- Does the agent choose the correct tool?
- Does it refuse actions outside its authority?
- Does it request approval at the right point?
- Can it resume interrupted work without repeating transactions?
- Does it protect personal, financial and confidential information?
- Are response time and processing costs still acceptable?
- Can the previous version be restored without losing active work?
Keep the results with the release record. This gives the CIO, risk team and auditors evidence that an upgrade was assessed rather than simply installed.
A practical production scenario
Consider a 200-person professional services firm using an agent to prepare new client files. The agent collects information, searches internal policies, creates tasks and pauses while a manager approves higher-risk engagements.
A framework upgrade changes how stored workflow messages are represented. The application starts normally, but existing cases cannot resume after approval. Operations staff must manually inspect each case and recreate missing tasks.
The technical outage may last only two hours, yet the business impact includes delayed onboarding, duplicated work and uncertainty about whether every compliance check was completed.
With versioned state, a pre-upgrade replay test and isolated deployment storage, the problem would likely have been found before release. The business outcome is not simply cleaner engineering. It is fewer interruptions and a defensible record of completed controls.
Connect AI release governance with Australian obligations
The Essential Eight is the Australian Government’s cybersecurity framework that many organisations use or are required to follow. Its patching principles support timely updates, but timely does not mean uncontrolled.
Your organisation needs a documented process for assessing vulnerabilities, testing changes and deploying urgent fixes without introducing a different operational risk.
Agent histories may also contain personal information covered by Australian privacy requirements. Include privacy and records-management owners when upgrades change memory, logging, retention or data location.
The production rule to remember
Monitor every release, test the releases you need and pin everything that can change agent behaviour. That includes the framework, model, instructions, tools, permissions, infrastructure and stored-state format.
CloudPro Inc brings more than 20 years of enterprise IT experience to this work. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations turn promising Azure and AI pilots into governed production services without the overhead of a giant, faceless provider.
If you are unsure whether your production agents are genuinely pinned and recoverable, we are happy to review the setup and highlight the practical gaps — no strings attached.