Treat "agent as a tool," not as an org chart

When people first build multi-agent systems, they often imagine a little company: a manager agent, a designer agent, a coder agent, all chatting with each other. Part 2 calls this over-anthropomorphizing, and advises against it.

The recommended pattern is to treat an agent as a tool. From the main model's point of view, "Deep Research" or "Plan Task" is just a tool call. The main agent calls something like call_planner(goal="..."), the harness quietly spins up a temporary sub-agent loop, and a structured result comes back. This is the MapReduce pattern: the main agent treats the sub-agent like a deterministic function with a defined goal, set of tools, and output schema. The benefit is that the returned data is instantly usable, with no further parsing or back-and-forth conversation, and the overall design stays flat and modular instead of becoming a tangle of agents talking to each other.

The earlier todo.md story is the concrete payoff of this thinking. Manus replaced a constantly rewritten to-do file (which wasted around 30 percent of tokens in earlier versions) with a dedicated planner sub-agent that returns a structured Plan object, injected into the context only when needed rather than consuming tokens every turn.