In this blog post Microsoft Agent Framework Python 1.22 and .NET 1.25 Roadmap we will explain what the latest releases mean for your AI plans, which decisions cannot wait, and how to avoid turning a useful pilot into an expensive production problem.
The issue facing many technology leaders is not a lack of AI ideas. It is that experimental agents are reaching business systems faster than organisations can establish ownership, security controls and reliable upgrade processes.
What Microsoft Agent Framework actually does
Microsoft Agent Framework is the control layer around an AI model. The model might come from Azure OpenAI, OpenAI or Anthropic Claude, but the framework manages how the agent remembers conversations, calls approved tools, follows multi-step workflows and asks people for permission before sensitive actions.
Python and .NET are the two main development environments. Python is widely used by AI and data teams, while .NET is common in established Microsoft business applications. They support similar goals, but they have separate release numbers and do not always mature at the same pace.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingPython 1.22 and .NET 1.25 were both released on 15 October 2026. Our earlier production guide to Agent Framework 1.22 and .NET 1.25 examines the immediate deployment risks. Here, we will focus on what the releases mean for your broader roadmap.
The short version for technology leaders
These releases do not mean every organisation should upgrade immediately. They show that Microsoft Agent Framework is becoming more capable while the surrounding hosting, storage and integration options continue to change quickly.
- Treat stored agent conversations as business data. They now require versioning, migration and rollback planning.
- Approve individual packages, not just the headline version. Some core components are stable while certain hosting and integration packages remain in preview.
- Separate your model decision from your framework decision. Changing from one AI model to another should not require rebuilding every workflow.
- Build security reviews into each release. An agent that can call business tools creates more risk than a chatbot that only generates text.
Python 1.22 makes agent state an architecture decision
The most important Python 1.22 change is not a new user-facing feature. It is a compatibility issue involving stored agent state, including certain conversation histories, streamed responses and workflow checkpoints.
Version 1.22 can read older records. However, an older worker may not understand some records written by 1.22 when they contain newly supported fields.
In practical terms, a normal rolling deployment could become unsafe. If old and new application instances share the same database, the new version may save a conversation that the old version cannot continue.
This changes the roadmap conversation. Agent state can no longer be treated as disposable application data. Your team needs to know where it is stored, how long it is retained, who can access it and whether it can be migrated or restored.
The business outcome is resilience. Mapping state before deployment reduces interrupted work, duplicate transactions and the staff time required to reconstruct failed agent sessions.
Python 3.15 support is useful but not universal
Python 1.22 adds Python 3.15 support to the core framework and main package. However, not every optional connector or feature is ready because some third-party components have their own compatibility limits.
This matters because a platform team may approve Python 3.15 while the application relies on an unsupported Redis memory connector, declarative expression feature or secure code execution component. The framework may install successfully while an important part of the solution remains unavailable.
Your roadmap should therefore include a dependency register. This is a plain list of every connector, database, model provider and optional feature an agent needs, along with its tested version.
More connection options require stronger controls
Python 1.22 also allows configurable service addresses for selected OpenAI and Ollama clients. This can help organisations route traffic through approved gateways, private services or controlled internal environments.
That flexibility is valuable, but it should not become a way for teams to bypass normal review. Approved destinations, authentication methods and data-handling rules should be defined centrally rather than left inside individual agent projects.
.NET 1.25 shows why package-level planning matters
The main .NET Agent Framework packages, including the core agent and workflow components, are available as stable 1.25 releases. Some hosting, Agent-to-Agent communication and declarative components still carry preview, alpha or release-candidate labels.
Agent-to-Agent communication, often shortened to A2A, lets separate agents exchange work. Declarative components let teams describe agent behaviour through configuration rather than writing every step in code.
The version number alone does not tell you whether the complete solution is ready for a critical business process. A stable core package combined with a preview hosting package still creates a preview dependency in your production architecture.
This does not mean preview software must never be used. It means the business owner should understand where it is being used, what happens if it changes and whether a manual fallback exists.
For a deeper look at cross-agent connections and tool access, see our A2A and MCP governance guide. MCP, or Model Context Protocol, is a standard method agents use to connect with tools and information sources.
What this means for your AI roadmap
1. Choose a primary development path
Supporting Python and .NET equally from day one can double testing, monitoring and support effort. Most organisations should nominate one as the primary path based on existing staff skills and business applications.
Use shared standards such as APIs, A2A and MCP when the two environments need to work together. Do not force the version numbers to match because their release streams are independent.
2. Separate the model from the business process
The AI model is only one component. Your workflow, permissions, audit history and approval rules should remain under organisational control.
This makes it easier to compare Azure OpenAI, OpenAI and Claude without rebuilding the entire application. It also reduces supplier risk and gives the organisation more control over future costs.
3. Create a supported production baseline
Do not let every project choose its own framework and connector versions. Publish an approved baseline covering packages, models, storage, identity, monitoring and data retention.
A simple release record might look like this:
agent_framework:
python: 1.22.0
dotnet: 1.25.0
state_store: isolated-and-versioned
rollback_tested: true
human_approval_required: financial-and-customer-actions
preview_packages: documented
security_review: completedThis gives management a clear answer when asking what is running, who approved it and whether it can be safely reversed.
4. Apply existing cybersecurity discipline to AI
The Essential Eight is the Australian Government’s baseline cybersecurity framework. It covers controls such as patching, multi-factor authentication, restricting administrator access and maintaining recoverable backups.
Although the Essential Eight does not provide a complete AI governance model, the same discipline applies. Agent components need timely security updates, tool access should follow least privilege, and important state needs tested recovery procedures.
Microsoft Defender can help identify threats across identities, devices and cloud services, while Wiz can show cloud risks and exposed paths across the wider environment. These controls matter because securing the agent code alone does not secure the systems it can reach.
A practical production scenario
Consider a 200-person professional services company using a Python agent to prepare client reports and a .NET agent to retrieve approved information from its customer system.
The Python team upgrades first and allows version 1.22 to write new session data into the shared store. An older worker later receives the same session and cannot continue it. Meanwhile, the .NET team assumes every 1.25 package is stable and deploys a preview hosting component without an agreed fallback.
Neither decision looks serious in isolation. Together, they can leave employees with abandoned reports, repeated work and no clear rollback path.
The safer approach is to isolate new state, test mixed-version behaviour, record every preview dependency and run a controlled pilot with real operational scenarios. That costs less than investigating failures after hundreds of employees have started relying on the agents.
A sensible 90-day plan
- Days 1–30 — Inventory every agent, package, model, tool, state store and business owner. Identify any production process using preview components.
- Days 31–60 — Build automated tests for permissions, approvals, session recovery, model changes and failed tool calls. Test rollback using a copy of real production-shaped data.
- Days 61–90 — Release to a limited user group, monitor cost and failure rates, then expand only when agreed business measures are met.
The measures should be practical: hours saved, requests completed without rework, cost per transaction, approval failures and security exceptions. A newer framework version is not a business outcome.
The roadmap decision is bigger than an upgrade
Python 1.22 and .NET 1.25 make Microsoft Agent Framework more useful, but they also reinforce a larger lesson. Production AI agents need the same change control, security ownership and recovery planning as any other important business system.
CloudProInc brings more than 20 years of enterprise IT experience across Azure, Microsoft 365, Microsoft Intune, Microsoft Defender, OpenAI, Claude and Wiz. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations turn promising agent pilots into controlled, supportable services.
If you are unsure whether these releases fit your roadmap, or whether your current agent setup can be safely upgraded, we are happy to review it with you — no strings attached.