CORE GUIDE

MENTAL_MODELINTERMEDIATE7 min read

Orchestration topology trade-offs

Loops, graphs, supervisors and parallel workers solve different coordination problems; topology should be chosen from dependency structure rather than architectural fashion.

Mental model

An orchestration topology is a control-flow decision. Use the simplest structure that represents task dependencies, state ownership, retry boundaries and verification without paying unnecessary coordination overhead.

Why it matters

Multi-agent diagrams can look sophisticated while hiding basic responsibility problems. A linear loop is easier to observe and recover than a graph, while a graph becomes valuable when work has real branches, joins, independent stages or conditional recovery. Supervisors add centralized coordination but can become bottlenecks; peer-to-peer delegation distributes control but makes global state and accountability harder.

01

Match topology to dependencies and failure boundaries

Start by drawing the task dependencies without agent labels. If one state transition naturally follows another, a loop or sequence is usually sufficient. Introduce branches for conditional paths, parallel nodes for independent work and joins only when outputs have a clear reconciliation contract. Define who owns shared state, where retries occur and which node verifies completion before choosing the coordination mechanism.

02

Example: research pipeline versus open-ended incident response

A research workflow with collect, extract, synthesize and verify stages may fit a simple graph with one parallel evidence-gathering branch and a clear join. An incident-response assistant with changing observations may be better modeled as one bounded loop that repeatedly diagnoses and acts. Splitting it into many agents would add handoffs without creating real independence.

Common failure modes

  • Choosing a multi-agent graph before identifying actual task dependencies.
  • Adding supervisor layers that repeat work already visible in shared state.
  • Creating parallel branches with no deterministic merge or conflict policy.

Engineering heuristics

  • Draw data and state dependencies before assigning agents.
  • Prefer a loop until branching or independent concurrency has measurable value.
  • Define join, retry and ownership semantics before adding parallel nodes.

Takeaways

  1. 01Topology is a consequence of workflow structure.
  2. 02More nodes create more coordination and observability cost.
  3. 03Simple control flow is a baseline that complex orchestration must beat.

Used in

This Concept is reused across these canonical learning paths.

Related concepts from the Knowledge Graph

These relationships come from the canonical graph, not a separate Guide taxonomy.

Delegation contract and shared vs isolated statePREREQUISITE
Loop vs Graph responsibility boundaryPREREQUISITE