Single-Agent, Workflow & Multi-Agent Orchestration

Definition

Agent orchestration coordinates the order, ownership and exchange of work among models, tools and people. Patterns include fixed pipelines, a single adaptive agent, parallel workers and an orchestrator that delegates bounded subtasks.

Decomposition is valuable when subtasks have clear boundaries. If every worker needs the entire evolving conversation and repeatedly waits for the others, the apparent modularity may add overhead without useful independence. Compare that design with one agent or a fixed workflow.

What it covers

Dependencies

Identify which results must exist before another step can run.

Contracts

Specify each worker’s inputs, outputs and acceptance conditions.

Authority

Limit worker permissions and parent-to-child delegation.

Aggregation

Resolve conflicting, missing or unsupported worker results.

A worker contract should include what the worker may do, what evidence it must return and when it should stop. Passing a goal without those boundaries can cause duplicate searches, conflicting actions or broad permission inheritance. Delegation should preserve the original task’s restrictions.

In practice

Practical design patterns by Min.

• Use sequential execution where a later action depends on verified earlier state.
• Parallelize only sufficiently independent work within shared capacity and budget limits.
• Assign one accountable owner for final decisions and consequential writes.

The orchestrator needs an explicit failure policy. Decide what happens when one worker times out, returns contradictory evidence or exceeds its budget. Partial results may be sufficient for a draft but insufficient for a consequential decision. Report that distinction to the user.

Research notes

Source-grounded details and editorial applications. Follow each link for the original document.

Working example

Why the controls matter

In the supplier example, parallel analysis can shorten independent reading work, but contract acceptance remains a separate decision. The aggregator should surface disagreements rather than averaging them away. Shared source errors can affect all workers, so agreement alone is weak assurance.

Common pitfalls

• Treating agreement among similar models as independent confirmation.
• Allowing multiple workers to update the same external record without coordination.
• Ignoring coordination and synthesis costs when estimating parallel speed gains.

Measure end-to-end results including scheduling, context transfer and final synthesis. Shared quotas or downstream bottlenecks can make a parallel system slower under load. A bounded worker pool and backpressure are often more useful than unconstrained fan-out.

Questions for operational review

Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.

• Which subtasks are genuinely independent?
• Who owns conflicting or incomplete results?
• Can parallel workers create duplicate external effects?