Scale Coordination Only When the Workflow Demands It

OpenAI’s agent guide treats orchestration as a response to observed complexity, not as the default form of sophistication. The practical question is when one agent with clear tools and instructions can no longer execute a workflow reliably, and when splitting responsibilities would make the system clearer rather than merely larger. This chapter compares the guide’s single-agent, manager, and decentralized patterns so readers can choose who keeps control, what crosses a handoff, and which new failure surfaces the choice creates.

An agent is already a loop: it interprets a goal, uses available tools, examines results, and decides whether to continue or finish. Orchestration determines whether that loop belongs to one agent or is distributed across several. The safest starting point is therefore the smallest loop that can handle the mapped workflow and be evaluated honestly.

Keep one agent until complexity is real

The single-agent run is the baseline

OpenAI recommends maximizing a single agent’s capabilities first. A single agent can gain more tools while keeping workflow control in one place. That reduces the number of boundaries where context must be transferred and makes evaluation and maintenance easier to reason about. It also lets a team learn whether a problem comes from a weak instruction, an unclear tool, or a genuinely overloaded responsibility before adding coordination.

The basic unit is a run: an execution loop that continues until an exit condition is reached. The guide gives several examples of exit conditions. A final-output tool can signal that the intended result is ready. The model may return a response without making another tool call. An error may stop the run, or a maximum number of turns may be reached. These conditions are not implementation trivia. They define when the agent is allowed to stop owning the workflow and what happens when it cannot complete it.

A loop without a clear termination rule can fail in two opposite ways. It can stop after a plausible partial result and leave work unfinished, or it can continue calling tools after the useful work is done. A maximum turn limit can prevent an endless attempt, but it does not by itself make the result correct. The system still needs a way to distinguish completion from an intermediate state and a way to return control when the result is not acceptable.

Single-agent design also benefits from prompt templates. Instead of maintaining a separate prompt for every closely related use case, a flexible base instruction can accept policy variables and user context. That can reduce duplicated logic and make updates easier. It works only when the common routine is genuinely common. If the template hides important differences between policies or users, it may make the system consistently wrong in a way that is harder to notice.

Split for a failure, not for a number

The guide does not recommend dividing an agent simply because it has many tools. It notes that some implementations manage more than 15 well-defined, distinct tools, while others struggle with fewer than 10 tools that overlap. The relevant variable is clarity. Similar names, ambiguous parameters, and overlapping responsibilities make it harder for the model to select the correct tool.