Microsoft reached general availability for multi-agent orchestration patterns in the Agent Framework this week, including the Magentic pattern that lets agents dynamically coordinate around complex tasks. The release consolidates routing, delegation, and swarm patterns into a single SDK, meaning developers no longer need to choose between AutoGen, Semantic Kernel, or a third-party framework to build multi-agent systems.
Three orchestration patterns, one runtime
The Agent Framework now supports three orchestration patterns out of the box, all running on the same Agent Harness runtime:
Routing. A router agent forwards incoming requests to the most appropriate specialist agent based on the task description. This is the simplest pattern. It works well when you have well-defined domains where each agent handles a specific capability and you know in advance which agent does what. Think of it as a smart load balancer for agents.
Delegation. An orchestrator agent assigns subtasks to worker agents and collects their results. Workers can delegate further, creating a hierarchy of agents. This is the pattern that maps most closely to the Magentic architecture. The orchestrator holds the plan, tracks progress, and re-routes when workers fail or return unexpected results. For complex tasks that require multiple specialized capabilities, delegation is usually the right starting point.
Swarm. Agents discover each other dynamically and negotiate task assignments without a central coordinator. The swarm pattern is useful for open-ended problems where the set of agents and their capabilities may change at runtime. It is also the most complex to debug, since there is no single point of control to inspect.
The key design decision here is that these patterns share a common runtime. You are not switching frameworks when you move from routing to delegation. The same Agent Harness, the same tool system, the same tracing. Only the agent topology configuration changes.
Magentic and the benchmarks
Microsoft first introduced the Magentic pattern as Magentic-One in November 2024, publishing it as research from the company’s AI labs. The architecture uses an Orchestrator agent that creates a plan, tracks progress against it, and delegates to four specialist agents: a WebSurfer for browser navigation, a FileSurfer for local file operations, a Coder for writing and executing code, and a ComputerTerminal for shell access.
The Orchestrator monitors progress and adjusts the plan when agents get stuck. If the WebSurfer cannot find information on a page, the Orchestrator might route the request to the Coder to scrape it programmatically. If the Coder’s output has errors, the Orchestrator retries with corrected instructions. This dynamic handoff between specialists is what gives the pattern its flexibility.
In published evaluations, Magentic-One achieved 38 percent on the GAIA benchmark, which tests general AI assistant capability across research, reasoning, and tool use tasks. It also posted competitive results on AssistantBench and WebArena, two benchmarks that evaluate agentic task completion across web browsing, coding, and multi-step tool use.
What is new here is that this pattern is now a first-class production capability in the GA Agent Framework rather than an experimental research project. The pattern is documented, supported, and configurable through the Agent Harness. Enterprises that were running proof-of-concept multi-agent systems on the preview can now move those workloads to production with confidence.
What this means for developers building multi-agent systems
The GA milestone matters for a practical reason. Multi-agent orchestration has been possible with AutoGen and Semantic Kernel for over a year, but both required significant manual configuration. You had to define agent topologies, message passing protocols, failure handling, and state management yourself. The Agent Framework abstracts those decisions into declarative configuration. You declare the pattern and the participating agents, and the framework handles the coordination.
There is a trade-off worth discussing. A managed orchestration layer is convenient, but it constrains what you can express. If your architecture requires a custom coordination protocol that does not fit routing, delegation, or swarm, you may need to implement that logic outside the framework. The framework is opinionated by design. For the majority of multi-agent use cases, the three patterns cover the landscape. For the edge cases, the framework’s tool system is extensible enough that you can build custom coordination on top of the agent harness.
The tracing and observability capabilities that reached public preview alongside the orchestration patterns are worth mentioning here. Debugging multi-agent systems is notoriously difficult because agent interactions are non-deterministic and context-dependent. The Agent Framework’s tracing captures inter-agent messages, tool calls, and decision points. This makes it possible to replay a multi-agent session and understand why agents made the choices they did.
Getting started
The multi-agent orchestration SDK ships with Microsoft Agent Framework version 1.0 for .NET and Python. The Magentic pattern is available as a preconfigured orchestration template. A natural progression path is to start with the routing pattern for a simple multi-agent setup, then move to delegation as your agent topology grows more complex, and experiment with swarm for advanced use cases where agent roles are not fixed.
Microsoft has published documentation and sample code on Microsoft Learn under the Agent Framework orchestration section.