Microsoft Agent Framework 1.0: A Developer's Guide to Multi-Agent Apps

Building a single AI agent that answers questions is now table stakes. The interesting work happens when multiple agents work together — one researches, another writes code, a third checks the results, and a manager keeps the whole team on track. Until recently, wiring that kind of coordination together meant writing a lot of boilerplate: message routing, state management, stall detection, and handoff logic. This week, Microsoft made that substantially easier. Microsoft Agent Framework's orchestration patterns have reached 1.0 across Python and .NET, and Agent Skills for .NET has graduated from experimental preview to a stable, production-ready API.

If you are building agentic applications on Azure AI, this is a milestone worth paying attention to. It means you can choose a coordination pattern that fits your problem, compose reusable domain expertise, and deploy with the governance controls enterprises expect — all on a stable surface.

What Is Microsoft Agent Framework?

Microsoft Agent Framework is Microsoft's open-source agent framework, designed to bring together the enterprise foundations of Semantic Kernel with the multi-agent orchestration strengths of AutoGen. It gives you a unified way to build agents in Python or .NET, ground them in enterprise data, add skills and memory, and run them locally, in Azure AI Foundry, or inside Microsoft 365 Copilot.

At Build 2026, Microsoft positioned the framework as the build layer of a broader Microsoft Agent Platform: build in the framework you prefer, run in Foundry Agent Service, and reach users in Teams and Microsoft 365 Copilot. The framework is the on-ramp. The recent 1.0 releases mean that on-ramp is now stable enough for production planning.

Orchestration Patterns Are Now Stable

The headline this week is that the Python agent-framework-orchestrations package hit 1.0.0, matching the .NET SDK's existing stable orchestration layer. That means five coordination patterns are now fully supported in both languages:

Sequential — agents run one after another, like a pipeline. Great for extract → summarize → review workflows.
Concurrent — agents fan out in parallel and their results fan back in. Useful when multiple perspectives can answer the same question independently.
Group chat — agents collaborate in a moderated conversation. Good for brainstorming or design sessions where several specialists need to converge on an answer.
Handoff — a router agent delegates to the right specialist. Perfect for support triage or multi-domain assistants.
Magentic — a manager agent turns a goal into a plan, assigns specialists, checks progress, and replans when the team stalls.

The key design win is that all of these patterns compile down to the same workflow primitives in Agent Framework: executors do the work, edges route messages, and the workflow emits events as it runs. The orchestration builders sit on top of those primitives, so you get a convenient API without losing the ability to drop down to the lower level when you need a custom shape.

Why Magentic Matters Most

If you are new to multi-agent orchestration, Magentic is the pattern to try first. It is the least prescriptive: you define a goal, a manager agent, and a set of specialist agents, and the manager decides how the team should work through the task.

Here is a concise example based on the official samples. A manager coordinates a researcher and a coder to compare the energy use of several AI models:

import os
from agent_framework import Agent, AgentResponseUpdate
from agent_framework.foundry import FoundryChatClient
from agent_framework.orchestrations import MagenticBuilder
from azure.identity import AzureCliCredential

client = FoundryChatClient(
    project_endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
    model=os.environ["FOUNDRY_MODEL"],
    credential=AzureCliCredential(),
)

researcher = Agent(
    name="Researcher",
    description="Finds and gathers information",
    instructions="You research. You do not do quantitative analysis.",
    client=client,
)

coder = Agent(
    name="Coder",
    description="Writes and runs code to analyze data",
    instructions="You answer quantitative questions by writing and running code.",
    client=client,
    tools=client.get_code_interpreter_tool(),
)

manager = Agent(
    name="Manager",
    description="Coordinates the team",
    instructions="You coordinate the team to finish complex tasks.",
    client=client,
)

workflow = MagenticBuilder(
    participants=[researcher, coder],
    manager_agent=manager,
    max_round_count=10,
    max_stall_count=3,
    max_reset_count=2,
).build()

task = (
    "Compare the training and inference energy use of ResNet-50, BERT-base, "
    "and GPT-2, estimate the CO2 for each, and recommend the most efficient "
    "model per task type."
)

async for event in workflow.run(task, stream=True):
    if event.type == "output" and isinstance(event.data, AgentResponseUpdate):
        print(event.data.text)

The manager decides the researcher should gather numbers first, hands the math to the coder, checks a progress ledger after each round, and synthesizes the final answer. If the team stalls, the manager can reset and replan. The max_* parameters are your guardrails; everything between the goal and the answer is the manager's responsibility.

This is a big productivity boost because you do not have to hand-wire every possible conversation path. You describe the team and the guardrails, and the framework handles the coordination loop.

Agent Skills for .NET Is Now Production-Ready

Announced alongside the orchestration milestone, Agent Skills for .NET has moved out of experimental preview. The API is stable, which means teams can ship skills as reusable packages of domain expertise without worrying that the contract will change underneath them.

A skill is simply a bundle of instructions, reference documents, and optional scripts that an agent discovers and loads only when a task needs it. The format uses a four-stage progressive disclosure pattern: the skill advertises its name, the agent loads its instructions, reads bundled resources if needed, and runs bundled scripts only when necessary. That keeps the context window lean and the agent's core instructions focused.

Why Skills Change the Game

The real benefit is reuse. Instead of stuffing every policy, playbook, and process document into an agent's system prompt, you package each domain as a skill and let the agent pull in the right one at runtime.

Enterprise policy. Package HR policies, expense rules, or IT security guidelines as skills. An employee-facing agent loads the relevant skill when someone asks, "Can I expense a co-working space?" and answers from the policy itself. Every employee gets the same grounded, auditable response.
Support playbooks. Turn troubleshooting guides into skills. When a customer reports an issue, the agent loads the matching playbook and follows the documented steps, so resolution is consistent no matter which agent instance handles the request.
Cross-team composition. Different teams author and maintain skills independently — as file directories, NuGet packages, or code-defined objects — and you combine them into one agent without writing routing logic. The agent decides which skill to use based on each skill's description.

Three Ways to Author Skills

The .NET release supports three authoring styles, all backed by the same runtime provider:

File-based skills — a directory with a SKILL.md, optional scripts, and reference documents. Best for teams that want to maintain skills in a shared repo without everyone being a developer.
Class-based skills — C# classes that package instructions, resources, and scripts for distribution through normal .NET workflows, including internal NuGet feeds.
Code-defined skills — skills created directly in application code. Useful when a skill needs to be generated dynamically or close over application state.

Built for Production Governance

Giving an agent the ability to load external instructions and run scripts requires guardrails, and this release includes them:

Human-in-the-loop approval is on by default for loading skills, reading resources, and running scripts. You can relax it selectively for trusted operations.
Controlled script execution lets you provide your own runner for file-based scripts, so you own sandboxing, resource limits, and audit logging.
Skill filtering lets you expose only a curated subset of a shared library to a given agent, with predicates that can consider the requesting agent or tenant.
Caching reuses resolved skills, with optional per-key isolation so one provider can serve different skill sets to different agents or tenants.

That is the kind of enterprise hygiene that turns a cool prototype into something you can actually run in production.

Getting Started: A Practical Path

If you want to try this out today, here is a sensible order of operations:

Pick one real task that currently involves more than one mental mode — for example, researching a topic, analyzing data, and writing a summary. That is a natural multi-agent fit.
Start with Magentic using the official Python or .NET samples. Define a manager and two or three specialists, set tight guardrails, and watch how the manager delegates.
Extract one piece of domain knowledge into a skill once you see where the agent needs consistent grounding. A file-based skill is the lowest-friction starting point.
Run it in Foundry Agent Service when you are ready to move from your laptop to a managed runtime. The same workflow code can transition across environments.
Add observability early. Agent Framework emits events as it runs, and Foundry provides tracing and evaluation for hosted agents. The sooner you can see what your agents are doing, the sooner you can improve them.

Why This Matters for the Microsoft Ecosystem

For developers already invested in Azure, .NET, Python, and Microsoft 365, these releases mean you do not have to stitch together a fragmented set of libraries to build agentic applications. Microsoft Agent Framework, Azure AI Foundry, and Microsoft 365 Copilot are becoming a coherent platform: build agents in the languages and tools you already use, ground them in the enterprise data you already trust, and deliver them inside the applications your users already open.

The 1.0 orchestration milestone and the stable Agent Skills API are not just version bumps. They are signals that Microsoft is serious about making agentic development a first-class, production-ready experience on Azure AI. If you have been waiting for the right moment to move from a single-agent prototype to a coordinated team of agents, that moment just arrived.

Useful links: