Topology Selection Decision Tree

One-Line Summary: A practical decision tree for picking a topology: start with single-agent, escalate to supervisor / queen-led only when single-agent demonstrably falls short, escalate beyond that only for specific patterns (mesh for negotiation, hive-mind for exploration, conversational for discussion, federation for cross-trust).

Prerequisites: Topology as a design decision, queen-led hierarchy, mesh topology, hive-mind pattern, supervisor pattern, conversational orchestration, role-based orchestration

The Tree

The discipline is to start at the top and only descend when the current level is provably insufficient.

1. Is one agent enough?
     ├─ YES → single agent. STOP. (most tasks land here)
     └─ NO → continue
2. Can the work be cleanly decomposed into specialist subtasks?
     ├─ YES → supervisor / queen-led. STOP. (most multi-agent tasks land here)
     └─ NO → continue
3. Does the task benefit from peer dialogue or debate?
     ├─ YES → conversational orchestration (AutoGen-style)
     └─ continue
4. Does the task have many partial solutions that combine?
     ├─ YES → hive-mind (shared memory + parallel workers)
     └─ continue
5. Do peers genuinely need to negotiate without a coordinator?
     ├─ YES → mesh topology
     └─ continue
6. Are agents owned by different parties / on different machines?
     ├─ YES → federation + consensus protocols (Module 06)
     └─ continue
7. None of the above clearly fit?
     └─ adaptive topology (let runtime signals pick)

A second sanity check: how often does the pattern's coordination overhead pay off in quality? If you cannot articulate why a more complex topology beats supervisor for this task, default to supervisor.

When to Use Each

Single agent — Routine coding, content generation, RAG queries, anything fitting in one context window. The strong default.

Supervisor / queen-led — Tasks with clear specialist subtasks: code review (style + correctness + security), research synthesis (search + summarize + cite), build pipelines (compile + test + deploy). The strong multi-agent default.

Role-based — When the workflow maps cleanly to named roles (content production, design review). A flavor of supervisor with personas elevated to first-class.

Conversational — Decisions that benefit from explicit deliberation: design reviews, ambiguous trade-offs, debate-style problem solving.

Hive-mind — Exploratory problems where you don't know the right decomposition: comprehensive research, large-codebase understanding, ideation.

Mesh — Genuinely peer negotiation without a coordinator. Rare.

Federation — Cross-organizational, cross-machine, or zero-trust scenarios. Not really a pure topology; usually combined with one above.

Adaptive — High-volume systems running heterogeneous tasks where the right shape varies. Operationally heavy; only worth it at scale.

Why This Decision Matters

The cost of getting topology wrong is high in both directions. Picking too simple wastes the multi-agent advantage; picking too complex burns tokens, slows the system, and obscures bugs. The tree biases toward simplicity for a reason — most tasks land at single or supervisor, and most teams should resist their instinct to escalate further.

Common Mis-selections

"I picked mesh because it sounded most agentic." Mesh is the most expensive and least-debuggable topology. Pick it last, not first.
"I picked hive-mind because the problem was big." Big problems are not automatically exploratory. If the decomposition is clear, supervisor handles big problems too.
"I picked adaptive because I want flexibility." Adaptive is for systems with proven heterogeneity at scale, not for "we might need flexibility someday."
"I picked role-based because I had a content workflow." Role-based is fine, but a supervisor with role-named sub-agents is functionally equivalent and usually cheaper.

How Harnesses & Frameworks Implement This Decision

The choice of topology constraints you to certain harnesses. If you know you need mesh + adaptive, ruflo is one of the few harnesses that implements both as first-class. If you only need supervisor, every framework supports it. The decision tree above is harness-agnostic; the implementation choice follows from the topology selected.

Connections to Other Concepts

All Module 03 topology concepts feed into this decision.
choosing-your-harness-stack.md — The corresponding harness-selection capstone.
harness-cost-models.md — Why simpler topologies usually win on cost.
../../agentic-design-patterns/01-design-patterns/multi-agent-decision-framework.md — Foundational decision framework.