When Control Moves: Managers, Handoffs, and Workflows
Once a single agent has reached a structural limit, the architecture question changes. The issue is no longer whether the agent can call another tool; it is who should own the next decision, what context should cross the boundary, and where the result should be synthesized or checked. This chapter compares centralized managers, decentralized handoffs, sequential workflows, parallel workflows, and evaluator-optimizer loops so the reader can choose by control and dependency rather than by the apparent sophistication of a pattern.
The labels vary across the supplied guides. A supervisor, manager, router, or orchestrator may describe related forms of centralized control, while collaborative, swarm, federated, or decentralized systems may describe different forms of peer interaction. Those names are less important than the mechanics underneath them: who delegates, who takes over, whether stages depend on one another, and how conflicting outputs are reconciled.
Central control and local ownership
A manager pattern keeps one central model responsible for the user interaction and workflow execution. The manager invokes specialized agents as tools, receives their results, and synthesizes them into a coherent response. The specialist may know how to perform a task, but the manager decides when to call it and how its output fits the larger request. This is a natural design when the system needs one visible owner of the conversation and one place to integrate several forms of expertise.
The benefit is not merely convenience. Centralization makes responsibility legible. The manager can decide which specialist receives the task, retain the overall objective, and resolve differences before returning an answer. A user does not need to understand which internal agent handled a subtask. In a customer-support setting, a manager might keep the conversation while invoking a billing specialist, an order specialist, or a technical-support specialist as needed. The resulting interaction can feel like one service even though the work is distributed behind it.
The same central point creates coupling. Every delegation decision passes through the manager, and every result may need to fit within its context. As the number of specialists and intermediate results grows, the manager can become a bottleneck in latency, tokens, or attention. It must also distinguish whether a specialist's result is a conclusion, an intermediate fact, or a request for another action. A central chain of responsibility is useful only while the manager can still preserve a coherent view of the task.
Hierarchical variants extend this idea by allowing a supervisor to delegate to a team leader that coordinates further specialists. That can hide detail from the top-level manager and give each layer a more focused problem. It can also make diagnosis harder: a failure may arise in the original delegation, within a subteam, or at the point where results are synthesized. The more levels are added, the more important it becomes to trace decisions and define which layer owns an unresolved case.
A decentralized handoff takes a different view of ownership. One agent transfers control to another specialist, passing the latest conversation state with it. The receiving agent becomes the active owner and can interact with the user or continue the workflow according to its specialization. This is useful when a task should fully move from triage to order management, sales, or technical support rather than remain under a coordinator that mediates every step.
The handoff can make local responsibility clearer. A triage agent can identify the nature of a request and then let an order-management agent handle delivery tracking or a return.