Microsoft Agent Framework Hits Python 1.22 and .NET 1.25

Microsoft's Agent Framework, the open-source toolkit meant to replace both AutoGen and Semantic Kernel for building AI agents, has reached Python 1.22.0 and .NET 1.25.0, six months after its 1.0 launch. The cadence is fast, roughly a minor release a week, and the latest versions include breaking changes and a data-compatibility warning that teams running the framework in production should read before upgrading.

Where the framework stands

According to a developer-focused changelog analysis, Agent Framework 1.0 shipped on April 3, 2026, for .NET and Python with stable APIs and a long-term-support commitment. The Python package has since moved from 1.0.0 to 1.22.0, which the PyPI listing shows was published on October 15, 2026 under an MIT licence for Python 3.10 and later. On the .NET side, the core packages for agents, workflows and the new harness are at 1.25.0, though the Foundry integration package is still a prerelease, and a Go SDK is in public preview.

The project's GitHub release page shows how quickly it moves: Python 1.22.0 on October 15, 1.21.0 on October 8, 1.20.0 on October 2, and .NET 1.25.0 on October 14, 1.24.0 on October 7, and 1.23.0 on October 1. That is several tagged releases in a single month across two languages.

What is new

The headline addition, per the changelog analysis, is a "harness" agent, exposed as HarnessAgent in .NET and create_harness_agent in Python. Its defaults include todo tracking, plan and execute modes, session file memory, tool-approval rules, OpenTelemetry instrumentation, and context compaction once token limits are set. In Python, the background-agent, file-access, and looping features are still marked experimental, and there is no packaged harness for Go.

Other changes the analysis highlights:

• An experimental, Python-only functional workflow API built on @workflow and @step decorators, which supports pausing and resuming through a request-for-input call. The graph-based WorkflowBuilder remains the stable cross-language option.

• Alpha hosting packages for OpenAI Responses, Telegram, A2A and MCP channels, available only in Python.

• Workflows that can recover from process restarts using checkpoints. The same source cautions that recovery does not guarantee exactly-once execution of external side effects, so tools that write to outside systems need idempotency keys.

• A Cosmos DB memory provider in Python preview, and CodeAct support through Hyperlight, are still pre-release. Microsoft reports about 50 percent lower latency and over 60 percent lower token use on one workload, while saying results vary.

The GitHub release notes list further additions in recent versions, including Python 3.15 support in 1.22.0, an alpha Oracle vector-store connector and a maximum reasoning-effort option for OpenAI models in 1.21.0, and hosting of native workflows over Foundry Responses in 1.20.0.

Breaking changes and upgrade risk

The more consequential material for operators is in the cautions. The GitHub notes say Python 1.22.0 includes breaking changes to content identity and hosted execution, tighter trust boundaries for AG-UI requests, and bounded sizes for declarative HTTP response bodies. They also warn that persisted chat histories, session stores, and workflow checkpoints containing new records cannot be read by runtimes older than 1.22. Teams should not run old and new workers against the same store during a rolling deployment, and should avoid downgrading once 1.22 has written such records unless the state is isolated or migrated.

Earlier releases carried their own breaks. Per the same sources, Python 1.20.0 rebuilt Foundry hosting, Python 1.19.0 required MCP skill archives to be ZIP files and deprecated the MCP sampling callback, .NET 1.23.0 changed how tool changes between runs and approval-response binding are handled, and .NET 1.25.0 now automatically rejects tool-approval requests that never receive a response. For a framework carrying a stable 1.0 label, that is a lot of behavioural change, and it illustrates a recurring tension in agent tooling: the stability promise applies to core APIs, while the surrounding hosting, memory and approval layers are still being worked out.

Migration from AutoGen and Semantic Kernel

The changelog analysis states that the AutoGen repository is archived, with no bug fixes, security fixes, or support, and that its last autogen-agentchat release was 0.7.5 on September 30, 2025. It advises migrating now. Semantic Kernel is not archived: version 1.45.0 shipped on October 6, 2026, and its README names Agent Framework as the successor. An adapter,as_agent_framework_tool(), available from Semantic Kernel 1.38, lets existing Semantic Kernel functions run as Agent Framework tools, which allows an incremental move rather than a rewrite.

Anyone still on AutoGen is in the most exposed position, because an archived repository will not receive security patches. Semantic Kernel users have more time, but the signalling from Microsoft's own documentation points one way.

Gaps that remain

The analysis lists several known gaps. Distributed execution is not yet part of the core framework. The Go SDK lacks the harness, functional workflows, declarative agents, retrieval-augmented generation, and CodeAct. Several of the most attractive features, such as the functional workflow API and the channel packages, are experimental or alpha, and Foundry hosted agents are generally available in Foundry while the SDK packages that talk to them remain prerelease. That mismatch between a generally available service and prerelease client libraries is the sort of detail that matters when planning a production rollout.

What to watch

For teams evaluating the framework, a sensible approach is to pin versions, read the release notes for each minor release, and test checkpoint recovery with real side-effecting tools before relying on it. The weekly pace suggests more breaking changes are likely while hosting and memory features settle. It will also be worth watching whether the experimental Python functional API graduates and whether the Go SDK reaches parity, since cross-language consistency is a large part of the framework's pitch.

More broadly, the project shows how agent tooling is consolidating around a few large, vendor-backed frameworks with built-in observability and approval controls. Whether that consolidation helps developers depends on how quickly the stable core grows relative to the experimental edges, and on how carefully maintainers handle compatibility for stored agent state.