Why Specialized Agents Make a Generalist Team

Magentic-One’s four worker agents are not a catalogue of convenient names; they are the action layer of its control cycle. This chapter explains how the Orchestrator routes work at the level of capability, how browser, file, coding, and execution functions complement one another, and what must cross each agent boundary for the next decision to be useful. The result is a more precise view of modularity: specialization can make a team more general, but it also moves complexity into interfaces, coverage, and coordination.

The Orchestrator chooses a capability, not every click

A complex task may expose dozens of possible low-level actions. A browser can navigate, scroll, click, type, and read. A file tool can open a document, move through a folder, or extract relevant content. A code environment can write, run, and debug programs. If the Orchestrator had to choose directly among every action at every turn, its decision problem would become tangled with the details of each tool.

Magentic-One uses a hierarchy instead. The Orchestrator chooses a broad capability and gives the selected specialist an instruction. The specialist then maps that instruction into a narrower action space and reports what happened. The Orchestrator can ask for browser work without deciding which page coordinate to click; it can ask for a computation without selecting every shell or Python operation. This does not remove the low-level difficulty. It places that difficulty closer to the tool where the relevant state is visible.

The hierarchy is useful because control and action require different views of the task. The Orchestrator must keep the user’s overall goal, the task ledger, and the progress decision in view. A WebSurfer must attend to the current browser page and ground an action to what is visible. A Coder must reason about program structure and error output. A ComputerTerminal must execute the requested program or command and return the result. Keeping these views separate reduces the number of unrelated choices made by one component.

It also creates a clear ownership boundary. The Orchestrator owns the question of which capability is needed and how the result affects the plan. The specialist owns the choice among actions inside that capability. The environment returns observations that neither side fully controls. A good handoff connects all three: the Orchestrator states what needs to be established, the specialist acts within its available space, and the returned observation is specific enough to update the task model.

That boundary is why specialization can improve reasoning without implying that every worker is independently general. Each agent is optimized for a generally useful function, not for the entire task. Generality appears at the level of the team, where the Orchestrator can compose functions in response to the request.

Four capabilities, one operating model

WebSurfer handles interaction with a Chromium-based browser. It can navigate to pages, search, scroll, click, type, and perform reading actions such as summarizing or answering questions about a document.