From Single Agent to Orchestrator

Subagents, Agent Swarms, and Coordinated Work.

A single AI agent can plan, research, write, review, and operate tools. The moment several agents enter the same workflow, however, a different class of problem appears. The question is no longer only: Can this agent complete the task? It becomes: How can multiple autonomous work instances divide responsibility, context, time, cost, and decisions without turning parallel work into coordination chaos?

That is where orchestration begins.

Multi-agent systems can look like an obvious upgrade: if one agent is useful, ten agents should be ten times as useful. In practice, that assumption is wrong. Additional agents first increase the number of interactions, not the quality of the result. They can repeat the same research, use different versions of the same document, contradict one another, wait on each other, multiply cost, or propagate an early mistake across several work streams.

A professional multi-agent system therefore needs more than well-written individual roles. It needs a coordination architecture. Who decomposes the task? Who is allowed to spawn whom? Which agent receives which context? Which work packages can safely run in parallel? Where are results recombined? How are competing findings resolved? What happens when one branch fails, arrives late, or moves in an unexpected direction? And when is a single agent simply the better design?

The central thesis of this article is therefore:

The real performance gain does not come from more agents. It comes from better orchestration.

More agents are not proof of quality

The intuitive equation "more agents = more intelligence" invites overengineering. A system can look technically impressive and still perform worse than a carefully managed single agent.

The reason is straightforward: every additional instance creates coordination cost. Another agent needs an assignment, context, permissions, an output contract, a return path, and a rule that determines how its result affects the shared project state. If five agents are launched in parallel, the architecture gains not merely five work streams but also five potential delays, five error sources, and several possible conflicts between results.

The relevant question is therefore not how many agents are available. It is:

Which parts of the task are independent enough to be separated, and how will their results later be recombined reliably?

That is the line between multi-agent design and uncontrolled agent spawning.

From role design to orchestration

The previous article focused on the individual role: orchestrator, specialist, reviewer, documentation function, and human decision authority. That level answers what an instance is responsible for.

Orchestration answers another question: How do work, context, state, and control move between those instances?

A role can be perfectly specified and still sit inside a poor multi-agent system. A research agent may have an excellent role contract. But if it receives the same assignment as three other agents, works from an outdated project version, or produces a result that never reaches the final synthesis, the overall architecture remains weak.

Multi-agent orchestration is therefore not a collection of good prompts. It is the design of a workflow between autonomous or semi-autonomous components.

At minimum, five flows must be coordinated:

Task flow — which work moves where?

Context flow — which information travels with it?

Control flow — who determines the next step?

State flow — which version is authoritative?

Evidence flow — how are findings, sources, tests, and uncertainties passed on?

If these five flows are invisible, the result is not a multi-agent system but several black boxes working at the same time.

Five questions before using multiple agents

Before an architecture introduces more than one agent, it should pass five tests.

If several answers are "no," a single well-equipped agent will often be the stronger architecture.

That is not a step backward. It is architectural discipline.

The architecture map: agents as a graph

A useful mental model is to treat a multi-agent system as a graph. Agents are not merely "colleagues"; they are nodes in a work network. Edges between them transport tasks, context, state, control, or results.

Nodes

A node can be an agent, deterministic service, reviewer, data access layer, or human decision point. The label matters less than the function it performs.

Edges

An edge represents a transition. It should answer at least what is transferred, in what format, which version applies, who is allowed to trigger the transition, and what happens if the transition fails.

State

The graph also needs a traceable project state. Otherwise, two agents may work simultaneously on two different versions of reality. Explicit state therefore matters: which task is open, which version is approved, which result is only a draft, and which dependency blocks further work?

This graph view exposes a crucial point: multi-agent orchestration is not primarily a model problem. It is a state, interface, and coordination problem.

Pattern 1: Manager and subagents

The manager/subagent pattern is one of the most intuitive architectures. A central instance retains the overall assignment, decomposes it into subproblems, calls specialized subagents, and synthesizes their results.

The manager does not have to be the best domain expert. Its job is coordination: retain the goal and global state, decompose work sensibly, delegate without unnecessary overlap, collect results, detect gaps and contradictions, create additional assignments when justified, and take responsibility for the final output.

This pattern is especially strong when the final product needs one coherent voice or a single point of outcome ownership. A technical report can, for example, be prepared in parallel by market, engineering, regulatory, and risk specialists while the manager preserves the common question and final synthesis.

The weakness is the bottleneck. If every decision, every subagent, and every result must pass through one central instance, the manager can become the throughput limit. It also becomes a single point of failure: if the manager misunderstands the objective, it may distribute the wrong work extremely efficiently.

The manager therefore needs not maximal context but a reliable global state and strong delegation rules.

Pattern 2: Handoffs between specialists

In a handoff, one instance transfers active responsibility to another. This is different from a manager briefly invoking a specialist as a tool.

A typical chain might look like:

Triage → domain analysis → review → completion

The triage function identifies the case and transfers control to the appropriate specialist. That specialist owns the next phase and may later hand the work to a reviewer or another role.

Handoffs are useful when each phase needs its own instructions and focused working context. They reduce the burden on a central manager and allow specialists to operate with narrower context.

But handoffs introduce a classic organizational problem: loss of responsibility at the boundary. If it is unclear what was transferred, which assumptions apply, and which issues remain open, the next agent starts from an incomplete reality.

A handoff therefore cannot mean only "continue from here." It needs a structured transfer contract.

Pattern 3: Sequential chain

Not every multi-agent architecture has to be dynamic. A simple chain can be highly robust:

Research → draft → review → revision → documentation

Each instance processes the previous output and creates a clearly defined next state.

The strengths are traceability and low coordination complexity. The cost is latency: every step waits on the previous one. Early mistakes can also propagate through the chain.

Sequential chains are therefore appropriate when dependencies are real. If the reviewer needs the draft before meaningful review is possible, artificial parallelism does not help.

The important lesson is: parallelism is not a quality feature. If the dependency is sequential, the architecture should respect it.

Pattern 4: Parallel fan-out and fan-in

Parallelism creates value when several subproblems can be handled independently.

During fan-out, a larger problem is split into parallel branches. During fan-in, the outputs are collected and reintegrated.

Consider a market analysis:

Agent A studies customer segments, Agent B analyzes competitors, Agent C reviews regulatory conditions, and Agent D evaluates technical feasibility.

All four can work at the same time if they share a common baseline and do not depend on each other's intermediate conclusions. A synthesis function then performs the fan-in.

The hard design work is not the fan-out. It is the fan-in. That is where contradictions, unequal depth, incompatible formats, and competing recommendations have to be handled.

A strong parallel architecture therefore defines before launch how outputs will later be recombined.

Design the fan-in before the fan-out

Many multi-agent systems are designed from the visible end: first the team decides how many agents should work in parallel, and only later asks how their results will be integrated. That ordering creates avoidable integration debt.

A better principle is: fan-in before fan-out. Before a branch starts, the architecture should know what kind of result it must return and how that result can later be compared, combined, challenged, or rejected.

Four decisions are essential:

1. Shared schema: Parallel workers return compatible structures.

2. Shared reference: They work from the same approved baseline and explicitly name deviations.

3. Integration rule: Before execution, the system knows whether outputs will be merged, weighted, reviewed, or escalated.

4. Incompleteness rule: A missing or late branch must never be silently interpreted as "no finding."

This is especially important in research. If four agents return free-form prose, the synthesizer first has to reconstruct a common structure. If each returns claim, evidence, source, uncertainty, and consequence as separate fields, the final synthesis becomes much more reliable.

The difference is architectural: the fan-out no longer produces arbitrary text. It produces composable work products.

Pattern 5: Evaluator-optimizer and independent challenge

A powerful design deliberately separates production from evaluation.

One agent produces an output. A second agent evaluates it against explicit criteria. If the result fails, it returns to a revision loop. The cycle continues until the criteria are met or a stop condition is reached.

The same principle can use different systems: one model creates a plan, another critiques the structure, a third searches for blind spots, and a final instance consolidates the findings.

The benefit does not come from different brand names. It comes from different evaluation functions and genuinely independent perspectives.

If all agents receive the same prompt, same context, and same hidden assumptions, a dramatic "AI debate" may still multiply the same error.

Pattern 6: Dynamic swarm

A swarm goes beyond a static list of agents. An instance may create additional workers while processing the task, open new parallel branches, and adjust the number of active agents dynamically.

That can be powerful because the architecture does not have to know every useful subproblem in advance. It can discover missing angles during execution and react to them.

The same property creates the risk. Without limits, dynamic spawning can turn a small request into dozens or hundreds of subagents. Every branch consumes context, model calls, tools, and integration capacity. The larger the swarm becomes, the more outputs later need to be judged and combined.

A swarm therefore requires an explicit spawn budget: maximum number of simultaneously active agents, maximum spawn depth, maximum total number of child tasks, token or cost budget, time budget, and a stop rule for declining marginal value.

Without these limits, autonomy is confused with resource consumption.

Vertical or horizontal orchestration?

A particularly useful distinction is between vertical and horizontal orchestration.

Vertical orchestration means that a main agent retains the overall assignment and creates short-lived subagents underneath it. Those subagents complete bounded tasks and return results. They do not own a persistent project workspace.

Horizontal orchestration means that several agents or sessions operate as independent, longer-lived work streams. Each has its own context, role, and area of responsibility. A research agent may continuously maintain evidence while a risk agent continuously tracks risks and a delivery agent follows execution status.

Vertical orchestration is easier to control. Horizontal orchestration scales specialization and parallel work more strongly, but requires stronger synchronization.

Many mature systems combine both: a central work stream that creates subagents when needed, plus a small number of persistent specialist contexts.

An orchestration maturity ladder

Not every project should start with the most complex multi-agent structure. A maturity ladder is more useful: each level is introduced only when the previous one works reliably.

This ladder is not a ranking of intelligence. For a tightly coupled task, level 1 may be more professional than level 5. Maturity therefore means choosing the lowest architectural complexity that reliably supports the required work mode.

It also protects against a common incentive problem: teams build spectacular agent architectures because the platform makes them possible, although the actual task would have been safer with one agent, two tools, and one independent reviewer.

The handoff contract

Whenever work moves between agents, the transfer needs a defined format. A minimal handoff can contain:

This prevents two frequent errors: context dumping and context starvation.

Context dumping sends the entire project to a receiving agent although only a small slice is relevant. Context starvation sends too little and forces the agent to invent assumptions.

Good handoffs therefore carry not the largest possible context but the smallest sufficient context, plus clear pointers to where additional information can be obtained.

Context is not a shared garbage heap

Multi-agent systems need a deliberate context topology. Three patterns are particularly important.

Shared state

Relevant agents access a controlled common project state. This works for baselines, approved decisions, terminology, and authoritative versions.

Isolated working context

An agent receives only the slice needed for its assignment. This reduces distraction and prevents irrelevant or sensitive information from spreading unnecessarily.

Selective replication

Certain information is intentionally copied into multiple contexts: objective, quality criteria, or binding terminology. Source and version must remain identifiable.

The wrong design is: everyone sees everything, all the time.

That may sound collaborative, but it often creates context overload, version ambiguity, and decisions that are difficult to trace.

State ownership and write conflicts

The more agents can modify the same project state, the more important the question becomes: Who owns which truth?

A shared folder or database does not solve the problem by itself. If two agents edit the same specification at the same time, the last writer may silently overwrite the first. If both keep separate versions, the project may split into two incompatible realities.

Three patterns help:

Single writer: One instance has write access to a critical state; other agents submit change proposals. This is slower but highly robust.

Branch and merge: Agents work on separate state branches and a defined integration function merges them later. This increases parallelism but requires conflict resolution.

Event sourcing: Agents do not directly mutate the authoritative state. They emit traceable events or change requests from which the accepted state is built.

For many knowledge and project systems, a simple rule is enough: critical baselines are read-only; changes are proposals until an integration step promotes them to the next baseline. This prevents parallelism from silently destroying the shared source of truth.

Parallelization means understanding dependencies

Before several agents start simultaneously, the task should be treated as a dependency graph.

If B requires A's output, A and B cannot meaningfully run fully in parallel. If C and D are independent, they can. If E requires both, E is a natural fan-in point.

This turns parallelization into a concrete question:

Which edge represents a real dependency, and which one merely reflects habit?

Good orchestration finds genuinely independent work without artificially fragmenting tasks. Poor orchestration parallelizes everything and pays the synchronization cost later.

The orchestrator needs budgets, not only goals

An autonomous manager that receives only a goal can theoretically keep generating more work. Professional systems therefore define resource budgets in addition to outcome targets.

Budgets are not merely cost controls. They force prioritization.

A system that can make good decisions inside a bounded budget is often more robust than one that is allowed to work indefinitely.

Spawn budget: how many agents may exist?

There is no universal ideal number of agents. The answer depends on task breadth, independence, context, cost, and integration effort.

A useful heuristic is:

Start with the smallest number of agents that creates a real functional separation. Expand only when a concrete bottleneck or clearly independent subproblem becomes visible.

Dynamic spawning should therefore not be authorized with "create as many agents as necessary." A stronger rule is:

Create an additional agent only when the new subtask is sufficiently independent, has a clear output, is not already covered, and the expected value justifies the remaining budget.

That turns the swarm from a spectacle into a controlled resource mechanism.

Backpressure: when the system creates more work than it can process

Agentic systems can produce work faster than humans or downstream agents can review it. That is a classic backpressure problem: the output rate of one stage exceeds the processing capacity of the next.

Suppose a research manager launches twenty subagents while only one synthesis agent can process their findings. The research stage may finish quickly, but the bottleneck simply moves downstream. More parallelism has not removed the queue.

The orchestrator therefore needs not only spawn limits but also fan-in capacity limits. Useful rules include: start new branches only when enough integration capacity exists, prioritize results instead of reviewing everything at the same depth, stop exploration when additional agents produce diminishing information gain, compress intermediate state before opening more branches, and defer new work when integration queues are saturated.

This creates a useful operational metric: marginal information gain per additional agent. If five more agents return only variants of known findings, stopping is more professional than exhausting the remaining budget.

Combining results: merge, vote, adjudication

After parallel work comes the hardest question: How do different outputs become one decision?

Several patterns are available.

Merge: Non-competing information is combined. Useful for complementary research.

Vote: Multiple agents choose among alternatives and the majority wins. Simple, but dangerous when all share the same wrong assumption.

Adjudication: An independent reviewer or manager evaluates competing outputs against explicit criteria and evidence.

Evidence-weighted synthesis: Claims are weighted by source quality, tests, and strength of support rather than by number of votes.

Escalation: If a conflict cannot be resolved reliably, it remains an explicit open decision rather than being silently averaged away.

The higher the decision risk, the less appropriate pure majority logic becomes.

Consensus is not proof of truth

Several agents can agree and still be wrong. This becomes especially likely when they use the same base model, same context, and same sources.

A multi-agent system therefore does not automatically create independent evidence. Real counterchecking requires variation in at least one relevant factor: different sources, different evaluation criteria, different roles, a different model family, a different search strategy, a different data basis, or a deterministic test.

The key rule is:

Agent plurality is not the same as evidence plurality.

Voting among ten copies of the same mistake merely produces a highly confident mistake.

Stragglers, race conditions, and cascade failures

Once agents work in parallel, problems familiar from distributed systems appear.

A straggler is a slow branch that delays the entire fan-in.

A race condition occurs when two agents modify the same state and the result depends on timing.

A stale state occurs when an agent keeps working on an old project version while others have moved forward.

A cascade failure occurs when a wrong intermediate result is distributed to several downstream agents and influences later decisions.

A circular handoff occurs when A hands to B, B to C, and C back to A without creating a meaningful new state.

These failures demonstrate why multi-agent systems are not merely prompt engineering. They need mechanisms familiar from software and process architecture: versioning, idempotency, locks or write permissions, timeouts, retries, dead-letter routes, and explicit state transitions.

Isolating failure domains

A multi-agent system becomes more robust when a local error cannot automatically contaminate the entire run. Work streams should therefore be treated as failure domains.

A research agent should not simultaneously own the right to overwrite the final baseline. A coding agent should not delete all prior artifacts because a test failed. A faulty specialist should invalidate only outputs that actually depend on that specialist.

Three properties help:

Bounded write rights: An error can affect only a controlled state area.

Dependency traceability: Downstream artifacts know which upstream results they depend on.

Rollback points: Approved states can be restored without restarting the entire run.

This makes fault tolerance more than a retry. A retry repeats work; a well-designed failure domain prevents a local fault from becoming a system-wide failure.

Observability: who did what, when, and why?

The more agents participate, the less useful a single chat log becomes as evidence.

A robust system should record at least: run ID and task ID, parent/child relationships between agents, agent role and version, valid context or data version, tools used, important state changes, produced artifacts, evidence and tests, cost and runtime, and stop and escalation reasons.

Observability is not only for debugging. It makes it possible to understand why the system reached an outcome and where a deviation entered the workflow.

In swarms, traceability becomes especially important. Otherwise the system reaches a paradoxical state: it can work faster than a person can follow, but nobody can explain which subinstance influenced which decision.

Balancing reproducibility and adaptability

Orchestration lives in a productive tension. A fully deterministic workflow is easy to reproduce but may react poorly to new information. A fully dynamic system may adapt extremely well but is harder to test and audit.

Not every layer should therefore be equally flexible. A robust design can use fixed state and handoff schemas while selecting specialists dynamically. It can enforce hard budgets while allowing free exploration inside those budgets. It can centralize final write rights while decentralizing analysis.

The goal is controlled variability: be dynamic where adaptation creates value and deterministic where traceability, safety, or repeatability matters more.

This separation also improves evaluation. It becomes possible to distinguish whether a failure came from the creative reasoning of an agent or from an unstable coordination interface.

Cost and token economics

Multi-agent systems scale not only work but also consumption.

Every additional agent has its own context, generates its own tokens, and may call tools. Parallelization can reduce wall-clock time dramatically while increasing total compute.

There is no contradiction: faster and cheaper are different optimization targets.

An architecture should therefore measure at least three dimensions separately:

1. Wall-clock time: How long does the user wait?

2. Compute/token cost: How much total work is produced?

3. Quality gain: What additional evidence, coverage, or reliability is achieved?

Only the relationship between these three values shows whether multi-agent design is economically justified.

When a single agent is better

A single agent is often the better choice when the task is strongly sequential, almost every step requires the same full context, subtasks are tightly coupled, a consistent reasoning and writing process matters more than perspective diversity, the benefit of parallelism is small, coordination cost exceeds the expected gain, or evaluating the multi-agent system would be harder than the original task.

The most mature multi-agent decision can therefore be: Do not build a multi-agent workflow.

Practical example: a strategic specialist report

Suppose an organization needs a defensible decision report for a new product idea.

A poor architecture immediately launches twenty agents with the instruction "analyze everything."

A better architecture begins with a manager that decomposes the problem into four largely independent branches:

Market agent: demand, segments, competitors.

Engineering agent: feasibility, dependencies, integration risks.

Regulatory/risk agent: requirements, uncertainties, exclusion criteria.

Finance agent: cost assumptions, sensitivities, economic risks.

All four receive the same approved baseline but different context slices and output contracts. They work in parallel. A synthesis agent then performs the fan-in.

The synthesizer is not allowed to smooth contradictions away. It creates a conflict matrix: which claims disagree, which depend on different assumptions, and which require more evidence?

For two unresolved questions, the manager spawns targeted additional subagents. A reviewer then checks the complete report against the original decision criteria.

The result is not "a swarm because swarms are impressive." It is an adaptively expanded work architecture.

The orchestration canvas

A compact architecture map is sufficient for many real projects.

A good canvas reveals whether the architecture is actually designed or merely populated with impressive agent names.

Seven stress tests before production

A multi-agent system should not be tested only under ideal conditions.

1. Duplication test: Two agents start the same work. Does the manager detect the overlap?

2. Straggler test: One agent arrives much later. Does the entire run block unnecessarily?

3. Conflict test: Two agents return contradictory but plausible findings. Is there a defensible resolution rule?

4. Stale-state test: One agent works from an outdated version. Is that detected before integration?

5. Spawn test: An agent wants to create ten more agents. Do need and budget rules constrain it?

6. Context-loss test: A handoff omits required information. Does the receiver ask for clarification or invent the missing state?

7. Cascade test: An early intermediate result is wrong. Can the system identify which downstream outputs are affected?

These tests do not measure eloquence. They measure the robustness of coordination.

A seven-step build path

A practical multi-agent system should not begin with a swarm.

1. Stabilize individual roles. Each role must understand its assignment, boundaries, permissions, and output.

2. Connect two roles sequentially. Test a clean handoff.

3. Add a manager. Make delegation and return paths visible.

4. Parallelize two independent branches. Only when independence is real.

5. Define aggregation and conflict resolution. Design the fan-in before expanding the fan-out.

6. Add budgets, observability, and failure routes. This is where the architecture becomes production-capable.

7. Permit dynamic spawning only when the need has been demonstrated. A swarm is an advanced stage, not the default starting point.

This path keeps system complexity proportional to the problem.

Conclusion: the real agent is the coordination system

Multi-agent systems move the bottleneck. With one agent, the main question is whether the model can perform the task. With several agents, the decisive question becomes whether the system can coordinate their work reliably.

A good manager decomposes without fragmenting. A good handoff transfers sufficient context without copying everything. Good parallelization exploits real independence. A good swarm grows only inside explicit budgets. A good synthesis counts evidence, not merely votes. And good observability makes the path to the result visible.

The central architecture rule is therefore:

Do not create another agent instance unless you can explain what independent value it contributes, how it will be integrated, and how its result will leave the branch and re-enter the system.

That is how a group of models becomes a coordinated work system.

The next step extends technical coordination into an organizational question: what changes when agents do not merely sit below a manager, but work within more distributed role and decision structures? That is the next layer of the series.

Public sources for further reading