Magentic-One
Last reviewed
May 20, 2026
Sources
No citations yet
Review status
Needs citations
Revision
v1 · 4,983 words
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation.
Suggest edit
CtrlK
Last reviewed
May 20, 2026
Sources
No citations yet
Review status
Needs citations
Revision
v1 · 4,983 words
Add missing citations, update stale details, or suggest a clearer explanation.
Magentic-One is a generalist multi-agent system released by Microsoft Research's AI Frontiers lab in November 2024 to autonomously solve complex, multi-step tasks across the open web, local file systems, and command-line environments.[^1][^2] The system uses a centralized control architecture in which a single Orchestrator agent plans, delegates, and tracks progress while four specialist agents (WebSurfer, FileSurfer, Coder, and ComputerTerminal) carry out tool-using sub-tasks. Built on top of AutoGen, Microsoft's open-source multi-agent framework, Magentic-One was the first widely circulated public reference design from Microsoft Research for an end-to-end agentic team capable of completing real-world workflows such as web research, data analysis, and code-driven automation without per-benchmark prompt tuning.[^1][^2]
Magentic-One reported task completion rates of 38% on the GAIA test set, 27.7% accuracy on AssistantBench, and 32.8% on WebArena, placing it in a statistically competitive position with state-of-the-art baselines as of October 2024.[^2] Its lasting influence has been less the raw scores than the Task Ledger / Progress Ledger orchestration pattern, which has since been adopted in numerous downstream frameworks, and the demonstration that a small, fixed roster of tool-centric agents could match purpose-built systems across heterogeneous benchmarks. In May 2025 Microsoft Research released Magentic-UI, a human-in-the-loop variant that builds directly on Magentic-One and runs on top of AutoGen v0.4.[^3][^4] The original Magentic-One code, released under the MIT license through the autogen GitHub repository, was subsequently re-implemented as MagenticOneGroupChat inside the autogen-agentchat package, where it remains the canonical reference orchestration team for AutoGen.[^5][^6]
Magentic-One originated inside Microsoft Research's AI Frontiers organization, the same group responsible for AutoGen and a long line of intelligent-agent research projects.[^1] The accompanying technical report, "Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks," was posted to arXiv on November 7, 2024 as arXiv:2411.04468, with a companion Microsoft Research blog post and a public release on GitHub timed for the same week.[^2][^1] The paper's author list begins with research leads Adam Fourney, Gagan Bansal, Hussein Mozannar, and Cheng Tan, followed by core contributors Eduardo Salinas, Erkang (Eric) Zhu, Friederike Niedtner, Grace Proebsting, Griffin Bassman, Jack Gerrits, Jacob Alber, Peter Chang, Ricky Loynd, Robert West, and Victor Dibia, and program leads Ahmed Awadallah, Ece Kamar, Rafah Hosn, and Saleema Amershi.[^2] Many of the same authors had also contributed to AutoGen itself, giving Magentic-One unusually deep integration with its underlying framework from the day of release.[^2][^5]
The name "Magentic-One" is, per the authors, a contraction of "multi" and "agentic," reflecting the fact that the system is designed to compose specialized agents into a single team rather than to ship a single, monolithic agent.[^2] The "-One" suffix is also load-bearing: although the team was capable of being extended, the authors deliberately fixed the released team to one Orchestrator plus four specialists in order to evaluate generality without per-benchmark tuning.[^2]
Beyond the system itself, the Microsoft Research team made two parallel contributions. The first was an open-source reference implementation, originally shipped as the autogen-magentic-one package within the AutoGen monorepo and subsequently absorbed into autogen-agentchat as MagenticOneGroupChat.[^5][^6] The second was AutoGenBench, a stand-alone harness for running agentic benchmarks with isolated Docker containers, fresh initial conditions, and repeated trials to estimate variance.[^2] AutoGenBench addresses the fact that, because agents take real actions in stateful environments (writing files, installing libraries, posting comments), naive evaluation harnesses give later-run systems an unfair advantage by inheriting installed dependencies, or unfairly penalize them by inheriting damage from earlier runs.[^2]
Magentic-One implements a centralized, hierarchical control flow: a single Orchestrator agent owns the global plan and decides at each step which specialist agent should act next.[^2] The four specialist agents do not communicate with each other directly; all messages flow through the Orchestrator, which is the only agent that maintains long-running state across the task.[^2] This stands in contrast to peer-to-peer multi-agent designs (where any agent may speak next) and to fully scripted designs (where the control flow is encoded as a program). The Orchestrator's plan exists primarily as natural-language chain-of-thought guidance and is not strictly executed; agents are free to deviate, and the plan can be revised when progress stalls.[^2]
The Orchestrator's distinguishing feature is its two-ledger design, organized into an outer and an inner loop.[^2] Figure 2 of the paper formalizes this as nested control loops; the same diagram is used throughout the AutoGen documentation.[^2][^6]
The outer loop maintains the Task Ledger, which serves as the Orchestrator's structured working memory for the duration of the task. When a new task arrives, the Orchestrator populates the Task Ledger with four explicit fields:[^2]
After the ledger is populated, the Orchestrator surveys the available team, then drafts a step-by-step natural-language plan that assigns sub-tasks to specific agents. The plan is treated as chain-of-thought guidance rather than as a binding script; neither the Orchestrator nor the specialist agents are required to follow it exactly.[^2] When the outer loop revises the plan (after a stall, for example), all agents are forced to clear their contexts and reset their states so that no stale assumptions persist across plan boundaries.[^2]
The inner loop maintains the Progress Ledger, which directs the moment-to-moment execution of the plan. On each iteration, the Orchestrator answers five structured questions:[^2]
The Orchestrator also maintains a stall counter. If a loop is detected, or if forward progress is judged absent, the counter increments. While the counter remains at or below two, the Orchestrator continues to dispatch new sub-tasks; once it exceeds the threshold, the inner loop terminates and control returns to the outer loop for reflection and self-refinement, after which the plan is revised and a new inner loop begins.[^2] This nested-loop pattern continues until the task is judged complete or until a configurable termination condition is reached (maximum attempts, maximum elapsed time, etc.). At termination, the Orchestrator reviews the full transcript and the ledger and reports either a verified final answer or its best educated guess.[^2]
The two-ledger design addresses three coupled problems that simpler agent loops typically conflate. The Task Ledger gives the Orchestrator a persistent, structured world model that survives across iterations of the inner loop. The Progress Ledger gives the Orchestrator an explicit reflection step that runs every turn, increasing the chance that loops, dead-ends, and false completions are detected. The stall counter and outer-loop reset together implement a bounded recovery strategy: agents have a fixed budget to push through temporary uncertainty before the system pays the higher cost of plan revision.[^2]
The four specialist agents in Magentic-One are organized by tool or capability rather than by professional role. The authors explicitly contrast this design with role-based teams (planner, researcher, analyst, critic), arguing that tool-centric agents avoid the redundancy that arises when each role independently needs to browse the web or write code.[^2]
| Agent | Role | Action space | LLM-based? |
|---|---|---|---|
| Orchestrator | Plans, tracks progress via Task/Progress Ledgers, selects next speaker, reflects and re-plans on stall | Issues natural-language instructions to specialists | Yes (multimodal in default config) |
| WebSurfer | Drives a Chromium browser to navigate pages, click elements, type, summarize, and answer questions about content | Navigation, page actions, reading actions; uses set-of-marks prompting for grounding | Yes (multimodal) |
| FileSurfer | Browses the local file system and previews documents through a markdown-based read-only viewer supporting PDFs, Office documents, images, audio, and video | List directories, open files, paginate, summarize | Yes |
| Coder | Writes new Python programs and debugs prior programs given console output; analyzes information collected from other agents | Emits new standalone Python source per request | Yes |
| ComputerTerminal | Provides a shell for executing Python code and running shell commands (e.g. installing libraries) | Deterministic execution of code or shell commands | No (deterministic) |
WebSurfer. A specialized LLM-based agent that commands a Chromium-based web browser. On each call from the Orchestrator, WebSurfer maps a natural-language instruction to a single action in its action space, takes the action, and reports both a screenshot and a written description of the new page state.[^2] The paper compares the arrangement to a telephone tech-support call: the Orchestrator knows what needs to happen but cannot directly act on the page, and so relays instructions to WebSurfer, which carries them out and reports back. WebSurfer's action space spans navigation (visiting URLs, performing searches, scrolling), web-page actions (clicking, typing), and reading actions (summarizing or answering questions about a page). The reading actions allow WebSurfer to perform document Q&A inline rather than returning to the Orchestrator for additional scrolling instructions, saving round-trips on long pages.[^2] WebSurfer grounds clicks and typed input to specific page elements using set-of-marks prompting, similar to WebVoyager, and extends the technique with textual descriptions of content outside the active viewport.[^2] In the modern autogen-agentchat implementation, this agent is exposed as MultimodalWebSurfer.[^6]
FileSurfer. Structurally similar to WebSurfer, but drives a custom markdown-based file preview application instead of a browser.[^2] The viewer is read-only but supports PDFs, Office documents, images, audio, and video, and FileSurfer can also list directories and traverse folder structures. Because the viewer converts everything to markdown, FileSurfer cannot directly answer questions about visual layout or non-speech audio content; the report identifies this as a notable limitation.[^2] The successor codebase uses Microsoft's MarkItDown library for the underlying file-to-markdown conversion.[^4]
Coder. An LLM-based agent specialized through its system prompt for writing code, analyzing information collected from the other agents, and synthesizing new artifacts.[^2] In its November 2024 design, the Coder always emits a fresh, standalone Python program in response to each coding request, even when debugging a prior failure; the authors flag this as a simplification that hurts performance on multi-file code bases and on tasks that depend on previously defined functions.[^2] In the autogen-agentchat rebuild, this agent is exposed as MagenticOneCoderAgent.[^6]
ComputerTerminal. A deterministic, non-LLM agent that executes Python programs and shell commands on the team's behalf.[^2] Splitting execution out of the Coder, rather than collapsing them into a single REPL-like agent, gives the Orchestrator a cleaner separation between code authorship and code execution. ComputerTerminal can also install new libraries via shell commands, allowing the team to expand its own programming toolset mid-task.[^2]
The five-agent decomposition produces what the authors describe as a hierarchy over tool usage: the Orchestrator chooses among a small handful of broad capabilities (browse, read a file, write code, run code), and the chosen agent then chooses among a small set of agent-specific actions (click, scroll, paginate). Compared to a single agent with dozens of tools, this hierarchy is hypothesized to be easier for current LLMs to reason about, and the ablations support that view.[^2]
In the released configuration, all LLM-based agents use gpt-4o-2024-05-13 as the default multimodal model, with the ComputerTerminal running deterministically.[^2] An alternative configuration substitutes OpenAI's o1-preview for the Orchestrator's outer loop and for the Coder while keeping GPT-4o for the multimodal agents (WebSurfer and FileSurfer), because o1-preview is text-only.[^2] This heterogeneous-model setup foreshadowed what later became a common pattern in agentic systems: a strong reasoning model where reasoning dominates (planning, code) and a fast multimodal model where perception dominates (browser, file viewer).
Magentic-One was implemented and released as part of AutoGen version 0.4, the event-driven rewrite of Microsoft's multi-agent framework.[^2][^6] When the paper was posted in November 2024, AutoGen v0.4 was still a relatively new code base, and Magentic-One was simultaneously its flagship demonstration and a forcing function for its API design. The original implementation lived as the autogen-magentic-one package inside the AutoGen monorepo, sitting directly on top of the lower-level autogen-core library.[^5]
In subsequent releases, Microsoft ported Magentic-One to the higher-level autogen-agentchat package, where it became MagenticOneGroupChat, an AgentChat team that can be instantiated like any other AutoGen team.[^6] The original autogen-magentic-one package was deprecated and pinned to AutoGen v0.4.4 for historical reference, with new development concentrated in autogen-agentchat and autogen-ext.[^5] The modern public surface area exposes MagenticOneGroupChat (the orchestrator team), MultimodalWebSurfer, FileSurfer, MagenticOneCoderAgent, and CodeExecutorAgent (the role previously called ComputerTerminal), along with a MagenticOne helper class that bundles all of the above with sensible defaults.[^6] Installing the system in its modern form requires both autogen-agentchat and autogen-ext[magentic-one,openai], plus Playwright for browser automation.[^6] Because MagenticOneGroupChat is a standard AgentChat team, it accepts arbitrary additional AssistantAgent participants, so the original fixed five-agent team can be extended without modifying the orchestrator itself.[^2][^6]
The relationship between Magentic-One and AutoGen is bidirectional. Magentic-One is one of AutoGen's reference designs and a major driver of its multi-agent semantics, while AutoGen provides the substrate (event-driven message passing, code-execution sandboxes, model adapters) on which Magentic-One actually runs.[^2][^6]
The Magentic-One paper evaluates the system on three agentic benchmarks of differing character: GAIA, AssistantBench, and WebArena.[^2] All experiments were conducted between August and October 2024, and all baseline numbers were taken from each benchmark's leaderboard as of October 21, 2024.[^2] Two variants of Magentic-One are reported: an all-GPT-4o configuration and a heterogeneous configuration combining GPT-4o for multimodal agents with o1-preview for the Orchestrator's outer loop and the Coder. The GPT-4o/o1 variant was not run on WebArena because o1 refused to complete 26% of WebArena's GitLab tasks and 12% of its shopping-administration tasks, citing safety concerns; the authors judged a fair comparison impossible under those conditions.[^2]
The headline numbers, expressed as exact task-completion percentages with Wald 95% confidence intervals, are summarized below. The comparison baselines are the highest-scoring leaderboard entries on each benchmark at the time of writing, along with GPT-4 as a single-model baseline and reported human performance where available.
| Method | GAIA (test) | AssistantBench (EM) | AssistantBench (accuracy) | WebArena |
|---|---|---|---|---|
| omne v0.1 (GPT-4o, o1) | 40.53 ± 5.6 | - | - | - |
| Trase Agent v0.2 (GPT-4o, o1, Gemini) | 39.53 ± 5.5 | - | - | - |
| Multi Agent (n/a) | 38.87 ± 5.5 | - | - | - |
| das agent v0.4 (GPT-4o) | 38.21 ± 5.5 | - | - | - |
| Sibyl (GPT-4o) | 34.55 ± 5.4 | - | - | - |
| HF Agents (GPT-4o) | 33.33 ± 5.3 | - | - | - |
| FRIDAY (GPT-4T) | 24.25 ± 4.8 | - | - | - |
| GPT-4 + plugins | 14.60 ± 4.0 | - | - | - |
| SPA → CB (Claude) | - | 13.8 ± 5.0 | 26.4 ± 6.4 | - |
| SPA → CB (GPT-4T) | - | 9.9 ± 4.3 | 25.2 ± 6.3 | - |
| Infogent (GPT-4o) | - | 5.5 ± 3.3 | 14.5 ± 5.1 | - |
| Jace.AI (n/a) | - | - | - | 57.1 ± 3.4 |
| WebPilot (GPT-4o) | - | - | - | 37.2 ± 3.3 |
| AWM (GPT-4) | - | - | - | 35.5 ± 3.3 |
| SteP (GPT-4) | - | - | - | 33.5 ± 3.2 |
| BrowserGym (GPT-4o) | - | - | - | 23.5 ± 2.9 |
| GPT-4 (single model) | 6.67 ± 2.8 | 6.1 ± 3.5 | 16.5 ± 5.4 | 14.9 ± 2.4 |
| Human | 92.00 ± 3.1 | - | - | 78.2 ± 2.8 |
| Magentic-One (GPT-4o) | 32.33 ± 5.3 | 11.0 ± 4.6 | 25.3 ± 6.3 | 32.8 ± 3.2 |
| Magentic-One (GPT-4o, o1) | 38.00 ± 5.5 | 13.3 ± 4.9 | 27.7 ± 6.5 | (not run) |
Several patterns are worth highlighting. On GAIA, the heterogeneous Magentic-One sits within a tight statistical cluster around the leaderboard top, behind omne v0.1 only by a non-significant margin. The GAIA gain from swapping in o1-preview is larger than on AssistantBench, which the authors attribute to GAIA's heavier emphasis on logical reasoning and puzzle-solving, the very skills that o1 was optimized for.[^2] On AssistantBench, Magentic-One (GPT-4o, o1) reaches 27.7% accuracy and 13.3% exact match, statistically comparable to the SPA → CB ensembles, which had previously been purpose-built for the benchmark.[^2] On WebArena, the GPT-4o variant reaches 32.8% across all 812 tasks, in the same statistical band as AWM, SteP, and most other open-source systems but below WebPilot (37.2%) and Jace.AI (57.1%), both of which the paper notes are heavily tuned for WebArena.[^2]
The paper draws particular attention to the fact that no prior system other than the base models had been evaluated on all three benchmarks.[^2] Magentic-One's value proposition is therefore not best-in-class performance on any single benchmark but consistent, statistically competitive performance across all three using the same unmodified configuration. The category breakdown reinforces the point: Magentic-One tends to compete relatively better on hard tasks than easy ones. On AssistantBench it actually outperforms the best comparable baseline on the hardest category, and on WebArena the largest gap to WebPilot is concentrated in the Reddit category, the easiest by score.[^2] The authors hypothesize that Magentic-One introduces a fixed overhead that disproportionately benefits long multi-step tasks while creating extra failure surfaces on short ones.[^2]
The paper reports ablations on the GAIA validation set with the GPT-4o configuration, varying both the orchestrator and the agent roster.[^2] Replacing the full Orchestrator with AutoGen's simpler GroupChat mechanism, which only picks the next speaker and drops the ledgers, planning, progress tracking, loop detection, and explicit instructions, reduces GAIA performance by 31%.[^2] This is direct evidence that the Task Ledger / Progress Ledger orchestration accounts for a meaningful share of the system's score, not just the model choice.
Removing individual specialist agents reduces GAIA performance by between 21% (removing both Coder and ComputerTerminal) and 39% (removing the FileSurfer), with the FileSurfer being most essential for level-2 tasks (which often include file attachments) and the WebSurfer being most essential for level-1 tasks.[^2] Interestingly, the team sometimes compensates for missing capabilities: when both the Coder and ComputerTerminal were removed, the remaining agents occasionally solved code-requiring tasks by having the FileSurfer read and reason over the code to predict the answer; when the FileSurfer was removed, the agents searched for online PDF viewers to read attachments. These improvisations are limited but indicate that the multi-agent design does not collapse entirely under partial agent failure.[^2]
The paper also includes an automated error analysis. GPT-4o was used to distill each task log into a postmortem and to apply a clustered code-book of failure modes across the validation logs.[^2] The most common failure modes were persistent-inefficient-actions (agents repeating an unsuccessful action without modifying their strategy), insufficient-verification-steps (marking tasks complete without validating the result), inefficient-navigation-attempts (cycling through tabs and menus instead of reaching the target page directly), and underutilized-resource-options (failing to use available tools fully).[^2] WebArena logs were especially affected by inefficient navigation, consistent with that benchmark's emphasis on dense, custom web UIs.[^2]
Magentic-One occupies a specific niche in the multi-agent landscape: a centralized, ledger-driven, tool-centric team built directly on the AutoGen substrate. Several other systems sit nearby but make distinct architectural choices.
| System | Default control flow | Agent decomposition | Typical use |
|---|---|---|---|
| Magentic-One | Centralized; Orchestrator with Task Ledger + Progress Ledger | Tool-centric (browser, files, code, terminal) | Generalist web + file + code tasks |
| AutoGen (base) | Configurable; GroupChat, Swarm, custom selectors | Application-defined | General multi-agent infrastructure |
| OpenAI Swarm (precursor to OpenAI Agents SDK) | Decentralized handoffs; stateless routines | Role/handoff-centric | Lightweight agent orchestration |
| CrewAI | Sequential or hierarchical processes | Role-centric (researcher, writer, etc.) | Business-process automation |
| LangGraph | Explicit graph; nodes and edges are user-defined | Application-defined | Stateful agent workflows |
| AG2 | Centralized or graph-based | Application-defined | Successor to AutoGen v0.2 lineage |
Compared with OpenAI Swarm (later evolved into the OpenAI Agents SDK), Magentic-One is far more opinionated. Swarm-style systems rely on lightweight stateless routines and handoffs in which the next agent is chosen by the previous agent. Magentic-One instead funnels all routing decisions through a stateful Orchestrator with structured ledgers, and gives the Orchestrator explicit primitives for stall detection and re-planning.[^2] The trade-off is overhead: Magentic-One's outer loop is much heavier than a Swarm handoff, but it provides more reliable error recovery on long-horizon tasks.
Compared with CrewAI, the most visible difference is the axis of decomposition. CrewAI typically organizes teams by human-style roles (researcher, writer, analyst, editor), each of which can plausibly need to browse, write code, or read files. Magentic-One organizes teams by tools (one agent owns the browser, another owns code, another owns files), which the authors argue gives a cleaner path to reuse and avoids duplicated capabilities across roles.[^2]
Compared with LangGraph, Magentic-One is opinionated about both the team and the orchestration loop. LangGraph hands developers a general state-machine abstraction and lets them define the graph from scratch, including the structure of any internal ledgers; Magentic-One ships a fixed graph (outer loop, inner loop, stall counter, five-agent team) tuned for open-ended task completion.
Compared with AG2 (an AutoGen fork that diverged from the v0.2 lineage in 2025), Magentic-One remains tied to Microsoft's mainline AutoGen v0.4+ branch and ships natively in autogen-agentchat.[^6] The two ecosystems share substantial code heritage but have evolved separate APIs since the fork. Finally, compared with WebPilot, the strongest open-source WebArena baseline in the paper, Magentic-One trades raw WebArena score for cross-benchmark generality: WebPilot does not generalize to GAIA or AssistantBench, while Magentic-One is statistically competitive on all three.[^2]
Because Magentic-One agents take real actions in real environments, including the public web, the paper devotes a substantial discussion section to risks and mitigations.[^2] Three categories of mitigation are described.
Containerization and synthetic environments. All experiments in the paper run inside Docker containers controlled by AutoGenBench, which initializes each task from a known clean state and prevents side effects from one task carrying over to another.[^2] The synthetic environments used in WebArena allow risky actions (login attempts, posting comments, modifying carts) to be evaluated without touching live third-party sites. The MultimodalWebSurfer in production deployments is similarly expected to run inside containerized browsers; the AutoGen documentation explicitly recommends running Magentic-One inside Docker and warns that the system can perform irreversible actions if not sandboxed.[^6]
Model alignment and content filters. The authors rely on strong alignment of the underlying models (GPT-4o, o1-preview) and on pre- and post-generation filters as a baseline defense against unsafe outputs.[^2] They explicitly call out the crescendo multi-turn jailbreak as a class of attack particularly worth worrying about in multi-agent settings, because a malicious or accidentally-prompted intermediate agent could escalate requests across turns in ways that defeat single-turn guardrails.[^2]
Observed misbehaviors. The paper transparently catalogues several real misbehaviors observed during development. In one case, a misconfiguration prevented the agents from logging into a WebArena site, so they repeatedly retried until the account was temporarily suspended, at which point they began attempting password resets. In another case, agents correctly noticed that WebArena's Postmill instance was not the real Reddit and tried to direct the team to live Reddit; this was blocked at the network layer. Agents also routinely accepted cookie agreements and terms-of-service prompts without human oversight (though they correctly refused captchas), and in a small number of cases attempted to recruit humans for help, by drafting social-media posts, emails to textbook authors, or even a freedom-of-information request to a government entity.[^2] Each of these attempts was blocked by the lack of the relevant tooling or by human observers, but the authors use them to argue that any production deployment must follow a strict principle of least privilege.[^2]
Anticipated risks. The paper also anticipates that web agents will face the same phishing, social-engineering, and misinformation attacks that target human users, and that attackers may seed external content with prompt-injection payloads targeted at agentic systems. The authors draw attention to the asymmetry between easily reversible, effortfully reversible, and irreversible actions, recommending that systems pause and seek human input before irreversible actions such as sending emails or deleting files. This framing is reflected in the action-guard design of the later Magentic-UI.[^2][^4]
Although Magentic-One was released as a fixed five-agent team, both Microsoft Research and the wider AutoGen community continued to build on it through 2025.
Magentic-UI (May 2025). Microsoft Research released Magentic-UI as an experimental human-centered web agent on May 19, 2025.[^3][^4] Magentic-UI is described as building on Magentic-One and is powered by AutoGen.[^3][^4] The architecture inherits the same core agent roles (Orchestrator, WebSurfer, Coder, FileSurfer) but adds a UserProxy agent that represents the human in the loop, and is fronted by a browser-based interface. The accompanying technical report, "Magentic-UI: Towards Human-in-the-loop Agentic Systems," was published in July 2025 (arXiv:2507.22358).[^7] Magentic-UI introduces six interaction mechanisms designed to give humans low-cost levers over an otherwise autonomous system:[^3][^4]
Magentic-UI also exposes its tool surface through the Model Context Protocol (MCP), so external tool servers can plug into the agent team without changes to the orchestrator.[^4] Magentic-UI is open source and shipped at github.com/microsoft/magentic-ui.[^3]
MagenticOneGroupChat in autogen-agentchat. As discussed above, the original Magentic-One reference code was rebuilt as a first-class AgentChat team during the AutoGen v0.4 stabilization process, making it interoperable with arbitrary AssistantAgent participants and with the rest of the AutoGen ecosystem.[^5][^6]
Adoption in third-party frameworks. The Task Ledger / Progress Ledger pattern was widely adopted in 2025 as a reference design for orchestration in long-horizon agentic systems, often under slightly different names. Both MagenticOneGroupChat itself and the underlying pattern can be wired into a wide variety of frontend frameworks, including AutoGen Studio.[^5]
Continued research. The paper enumerates several limitations that became active areas of follow-up: high cost and latency from many LLM calls, the Coder's lack of stateful execution (a Jupyter-style notebook model would help), the fixed team roster (dynamic team composition), and the absence of cross-task learning (long-term memory). Magentic-UI directly addresses the last with its plan-learning and long-term memory features.[^2][^4]
The Magentic-One source code is released under the MIT license, in line with the rest of the AutoGen project.[^5] This applies both to the original autogen-magentic-one package and to the modern MagenticOneGroupChat implementation in autogen-agentchat.[^5][^6] Magentic-UI is also released as open source under a permissive license.[^3] Model weights are not included; deployments must supply API access to a suitable foundation model such as GPT-4o or o1.
Within the AI-research community, Magentic-One was received primarily as a reference design rather than a leaderboard champion. Its raw scores were statistically tied with several leaderboard systems but did not unambiguously top any benchmark; its real contribution was packaging a coherent, reproducible orchestration pattern with open-source code.[^2] The Task Ledger / Progress Ledger pattern, the tool-centric agent decomposition, and the stall-counter recovery mechanism each diffused into subsequent multi-agent designs.
In the engineering community, Magentic-One's most immediate impact was on AutoGen itself. The release made AutoGen v0.4 the de facto Microsoft-supported framework for shipping autonomous multi-agent systems and gave AutoGen a flagship application against which to evaluate API decisions. By 2025, MagenticOneGroupChat had become the canonical way to demonstrate AutoGen's team abstractions.[^6]