Microsoft Agent Framework Version 1.0

Microsoft has moved Agent Framework to version 1.0 for both .NET and Python. This is the first release the team is calling production ready, with stable APIs and a formal commitment to backward compatibility. If you have been waiting on the sidelines during the preview and release candidate phases, this is the signal that the framework is ready for real workloads.

The project started last October as an effort to merge two separate lineages, Semantic Kernel and AutoGen, into one SDK. Semantic Kernel brought the enterprise plumbing, things like connectors, memory, and orchestration primitives that large teams needed. AutoGen brought the research driven multi-agent patterns, group chat and handoff orchestration among them, that came out of Microsoft Research. Folding both into a single framework means .NET and Python developers no longer have to pick a lineage and hope it survives.

Creating Your First Agent

The quickstart is straightforward. You install the package, authenticate with Azure CLI or an API key, and wire up a chat client pointing at a model deployment. Here is the Python version that creates a single agent and asks it to write a haiku.

# pip install agent-framework
# Use `az login` to authenticate with Azure CLI
 
import asyncio
 
from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential
 
agent = Agent(
    client= FoundryChatClient(
      project_endpoint="https://your-project.services.ai.azure.com",
      model="gpt-5.3",
      credential=AzureCliCredential(),
    ),
    name="HelloAgent",
    instructions="You are a friendly assistant."
)
 
print(asyncio.run(agent.run("Write a haiku about shipping 1.0.")))

Running this script prints a haiku generated by the gpt-5.3 deployment you pointed the agent at. Nothing unusual here if you have used Semantic Kernel before, the pattern of a client plus an agent wrapper is familiar. One thing worth flagging: the sample authenticates with AzureCliCredential, which is fine for local development, but you will want a managed identity or a service principal once this moves into a pipeline or a hosted service, since az login sessions do not exist on build agents.

The .NET equivalent follows the same shape, just with an AIProjectClient and an AsAIAgent extension method instead of a constructor.

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry
using Azure.Identity;
 
// Replace the <apikey> with your OpenAI API key.
var agent = new AIProjectClient(endpoint:"https://your-project.services.ai.azure.com")
    .GetResponsesClient("gpt-5.3")
    .AsAIAgent(
        name: "HaikuBot", 
        instructions: "You are an upbeat assistant that writes beautifully."
    );
 
Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

The .NET sample builds an AI agent from a Foundry responses client and runs it with RunAsync. If you have worked with the Semantic Kernel Agent SDK before, this feels close to a chat completion agent, except the surface area is smaller and there is no separate kernel object to configure first. A common mistake here is missing the –prerelease flag on transitively referenced packages, particularly if your NuGet feed also carries an older stable Microsoft.SemanticKernel package that can collide on namespaces.

Building Multi-Agent Workflows

A single agent only gets you so far. Most production scenarios need more than one specialised agent cooperating, so Agent Framework ships orchestration builders for common patterns. The example below wires up a two agent sequential workflow, a writer that drafts a tagline and a reviewer that critiques it, streaming results as the workflow runs.

import asyncio
 
from agent_framework import Agent, Message
from agent_framework.foundry import FoundryChatClient
from agent_framework.orchestrations import SequentialBuilder
from azure.identity import AzureCliCredential
 
 
async def main() -> None:
    # credentials read from .env
    client = FoundryChatClient(credential=AzureCliCredential())
 
    writer = Agent(
        client=client,
        instructions="You are a concise copywriter. Provide a single, punchy marketing sentence.",
        name="writer",
    )
 
    reviewer = Agent(
        client=client,
        instructions="You are a thoughtful reviewer. Give brief feedback on the previous message.",
        name="reviewer",
    )
 
 
    workflow = SequentialBuilder(participants=[writer, reviewer]).build()
    outputs: list[list[Message]] = []
    async for event in workflow.run("Write a tagline for Microsoft Agent Framework 1.0.", stream=True):
        if event.type == "output":
            outputs.append(cast(list[Message], event.data))
    if outputs:
        for msg in outputs[-1]:
            print(f"[{msg.author_name or 'user'}]: {msg.text}")
 
if __name__ == "__main__":
    asyncio.run(main())

The SequentialBuilder chains participants in order and streams events as the workflow executes, so you can update a UI in real time instead of waiting for the whole chain to finish. Watch the output filtering logic closely: the sample only keeps the last set of messages from the outputs list, which works for a two-step chain but gets awkward once you have four or five agents in sequence and want intermediate results too. For anything beyond a linear chain, look at the concurrent, handoff, and group chat orchestration patterns instead of trying to force everything through SequentialBuilder.

What’s Actually Stable in Version 1.0

The team is explicit that 1.0 only covers the pieces they have hardened and are committing to support with backward compatibility. That list is worth reading carefully before you commit production code to a particular API, because plenty of interesting capability still lives in preview.

• Core agent abstraction with first-party connectors for Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama
• Middleware pipeline for intercepting and extending agent behaviour, useful for content safety filters, logging, and compliance checks without touching prompts
• Pluggable memory and context providers, with backends including Foundry Agent Service memory, Mem0, Redis, and Neo4j
• Graph based workflow engine with checkpointing, so long running processes survive interruptions and restarts
• Multi-agent orchestration patterns from Microsoft Research and AutoGen, covering sequential, concurrent, handoff, group chat, and Magentic-One, all with streaming and human-in-the-loop support
• Declarative YAML definitions for agents and workflows, so orchestration topology can live in version control instead of code
• MCP support for dynamic tool discovery, with A2A cross-runtime collaboration arriving separately
• Migration assistants that analyse existing Semantic Kernel or AutoGen code and generate a step by step migration plan

This is a fairly wide stable surface for a first major release, wider than what most SDKs ship at 1.0. That is partly because the release candidate phase ran since February, which gave the team several months of real usage before locking the API.

Preview Features Worth Watching, Not Betting Production On Yet

Alongside the stable core, the release ships a second set of features still in preview. The team is upfront that these APIs can change based on feedback before graduating, so treat them as things to prototype with rather than build a critical path around.

• DevUI, a browser based local debugger that visualises agent execution, message flow, and tool calls in real time
• Hosted agent integration on Microsoft Foundry or Azure Durable Functions, for running agents as managed services
• Deeper Foundry integration covering tools, memory, and OpenTelemetry based observability and evaluation dashboards
• Frontend adapters for CopilotKit and ChatKit, including tool execution status and human approval flows
• Skills, packaged bundles of instructions, scripts, and resources that give an agent a capability out of the box
• GitHub Copilot SDK and Claude Code SDK support, letting you wrap a coding capable agent inside a larger multi-agent workflow
• A customisable agent harness with shell and file system access, aimed at coding agents and automation scenarios

DevUI is probably the most immediately useful of this group for day to day debugging, since tracing why a multi-agent workflow picked a particular handoff is otherwise a log-reading exercise. The Copilot SDK and Claude Code SDK wrapping is interesting too. It lets you treat a coding agent as one participant inside a larger orchestration rather than a standalone tool, though I would want more clarity on cost and rate limit behaviour before wiring that into anything customer facing.

A Look at DevUI

This is what the preview debugger looks like while a workflow runs. Being able to see message flow and tool invocations without instrumenting your own logging saves real time during development, particularly when an orchestration pattern like handoff or group chat is not behaving the way you expect.

Migrating From Semantic Kernel or AutoGen

If your team already has a Semantic Kernel or AutoGen codebase, this is a reasonable point to start planning the move rather than staying on the older frameworks indefinitely. Both are effectively feeding into Agent Framework going forward, and the migration assistants analyse your existing agent and orchestration code to produce a step by step plan rather than leaving you to reverse engineer the mapping yourself. Budget real time for this though. Migration assistants are a starting point for the mechanical parts, not a substitute for testing orchestration behaviour after the move, particularly around memory and session handling, which do not map one to one between the frameworks.

Installing and Getting Started

If you were already running the release candidate packages, moving to 1.0 is just a version bump, nothing structural changes. For a fresh start, Python developers install with pip install agent-framework, and .NET developers add the Microsoft.Agents.AI NuGet package. The quickstart guide covers both languages, and the GitHub samples repository is the fastest way to see complete, runnable examples rather than fragments.

Is It Worth Adopting Now

For new projects, yes. There is little reason to start fresh on Semantic Kernel or AutoGen individually when Agent Framework consolidates both into one supported SDK with a wider set of first-party connectors. For teams already deep into Semantic Kernel in production, the calculus is different. The stable API surface covers the core agent and orchestration patterns you are likely using already, so the migration cost is mostly mechanical, but I would still pilot it on one workflow before moving everything over, since memory provider behaviour and streaming semantics are exactly the kind of subtle differences that surface only under production load.

One limitation worth calling out: A2A support is listed as coming soon rather than fully available in 1.0, so if cross-runtime agent collaboration with non-Microsoft frameworks is central to your architecture, check the current state of that protocol support before committing to a timeline. Preview features are also explicitly not covered by the backward compatibility guarantee, so anything you build on DevUI, the Copilot SDK wrapper, or the agent harness today may need rework when those graduate to stable.