Microsoft Agent Framework 1.0 Unifies AutoGen and Semantic Kernel and Ships the Stable APIs Enterprises Have Been Waiting For
Microsoft shipped Agent Framework 1.0 this week, and the version number is doing real work here. This is not a preview with asterisks. It is the completion of a unification project that merged two distinct agent frameworks — Semantic Kernel and AutoGen — into a single open-source SDK under the Microsoft.Agents.AI package. The stable APIs come with a long-term support commitment, which is the part that matters most for production adoption. Preview churn has been the silent enemy of enterprise agent adoption for the past two years: every time a major framework shipped a new version, teams that had bet on the previous API surface had to choose between staying frozen on an outdated version or rewriting their integration code. 1.0 means the API surface is done moving. The foundation is stable enough to bet a production system on.
The headline feature is cross-runtime interoperability. Agent Framework 1.0 ships with full MCP (Model Context Protocol) support for tool discovery and invocation, and A2A 1.0 support for cross-framework agent collaboration is arriving shortly. MCP gives you a standard way for agents to find and call tools — think of it as the USB of agent toolchains, letting you plug different tools into different agent runtimes without custom integration work for each pair. A2A gives you a standard way for agents from different vendors or different runtimes to talk to each other, negotiate capability, and coordinate action. The fact that Microsoft is baking both into 1.0 simultaneously is a signal that the enterprise agent story has moved past the single-agent demo stage. Real deployments need multi-agent workflows, which means you need both tool interoperability and agent-to-agent communication baked into the base layer, not bolted on as an afterthought.
OpenTelemetry integration is built in by default via UseOpenTelemetry(). That is a detail that sounds boring until you are debugging a production agent flow that touched eight tools across three services and you cannot figure out where it failed. Telemetry is not optional in production systems. The fact that it is on by default rather than a configure-it-if-you-remember option is a sign that the framework is being designed for production use from the start, not retrofitted for observability after the fact. In practice, this means your agent traces, tool call timings, and session metadata will flow into whatever observability stack your team already uses without additional instrumentation work.
The underlying dependencies have also moved to stable releases: Microsoft.Extensions.AI upgraded to 10.4.1, Azure.AI.OpenAI to 2.1.0. These are not glamorous version bumps. They are the foundation that production operations teams need before they will sign off on a framework for mission-critical workflows. When you are deciding whether to build on a framework, the stability of the dependency chain matters as much as the feature list. Stable dependencies means the risk of an upstream change silently breaking your agent logic is dramatically reduced. Teams running production workloads on preview frameworks have been burned before. The upgrade path is rarely as smooth as the release notes promise.
The breaking changes from preview are documented, which is the right behavior. ChatClientAgentOptions.Instructions was removed and the thread parameter was renamed to session. Any team that has been running a preview version will need to update their code, but the migration path is documented rather than left as an archaeology exercise. The travel-planner sample app has been rebuilt on the stable API surface, which means there is a concrete reference implementation rather than just release notes telling you to "port your code." That reference app also serves as a integration test of sorts — if the sample app works end to end on the new API, it is a signal that the basic patterns hold.
For enterprises that have been waiting on the sidelines, 1.0 is the signal to evaluate seriously. The AutoGen and Semantic Kernel ecosystems were always closely related — both Microsoft projects, both targeting agent orchestration, both converging on similar concepts around tool use and conversation flow. The unification removes the decision paralysis that comes from choosing between two preview frameworks that might both change. Now there is one framework, one package, one LTS commitment. The question is no longer "which preview should we build on?" It is "are we ready to build on Microsoft's agent stack?" For teams already in the Microsoft ecosystem — using Azure, Teams, Copilot, and the broader Microsoft 365 surface — the answer is probably yes. The integration points with existing Microsoft tooling are simply stronger, and the governance, compliance, and procurement relationships already exist.
The broader implication is that the enterprise agent infrastructure market is consolidating around first-party platforms. The long tail of experimental agent frameworks — every team that spun up their own agent harness in 2023 and 2024 — is giving way to a smaller number of supported, LTS-backed platforms that enterprise IT will actually sign off on. That is healthy for production adoption and slightly boring for the innovation frontier. The interesting new work will happen at higher layers — orchestration patterns, agent governance, multi-agent coordination, domain-specific agent recipes — rather than at the framework infrastructure level. The base layer is stabilizing. The next competition is about what you build on top of it.
Sources: Microsoft Tech Community, Microsoft Agent Framework Blog