PresidenteOG Agent Topology Selector
Adapted from https://raw.githubusercontent.com/ai-boost/awesome-prompts/main/prompts/multi_agent_topology_selector.txt (ai-boost/awesome-prompts, GPL-3.0) — rewritten, not copied.
Overview
More agents is not automatically better — every extra agent is state that has to move between contexts, and a chance for two agents to duplicate or contradict each other's work. Pick the coordination shape the task's structure actually demands, then name who owns what.
When to use
- A task looks like it could span more than one
crew-*agent and it isn't obvious whether they should run in parallel, in sequence, or undercrew-lead. - Someone proposes spinning up several agents for something a single one could finish.
- Reviewing a dispatch table before executing it.
Evaluate first
| Dimension | Ask |
|---|---|
| Task structure | Are the subtasks genuinely independent, or does step 2 need step 1's output? Does anything need a single arbiter deciding between conflicting outputs? |
| Coordination cost | How much state has to move between agents, and how often? Since subagents here can't message each other directly, all handoff state passes back through the main thread — does that overhead outweigh the parallelism gain? |
| Failure surface | Could two agents duplicate the same edit? Could one act on a stale view of a file the other just changed? Is ownership of each file or decision unambiguous? |
| Constraints | What's the actual token/time budget, and does this need a human checkpoint before it lands? |
Topologies
| Shape | Use when | Owner in this workspace |
|---|---|---|
| Single agent | One specialist can finish the whole thing | Dispatch directly, e.g. crew-coder |
| Parallel | Subtasks are truly independent, no shared file or state | Main thread spawns each crew-*/cavecrew-* agent itself — subagents can't spawn each other |
| Sequential pipeline | Each stage needs the previous stage's output (investigate → build → review) | Main thread runs them in order, passing the prior receipt forward |
| Hierarchy | The task needs upfront decomposition and ownership assignment across several specialists | crew-lead (inherits main's model) plans and returns a dispatch table; main thread executes it |
| Hybrid | A hierarchy where some branches then run in parallel | Only justify this when at least one branch is genuinely independent of the others — don't default to it |
Process
- State the task in one sentence and list its subtasks.
- Mark each subtask pair: independent, or dependent-on-previous.
- Pick a topology from the table — default to the simplest one that fits; a single agent is often enough.
- If parallel or hybrid, name which agents run concurrently and confirm they don't touch the same files.
- If hierarchical, confirm
crew-leadis producing a dispatch table, not itself trying to invoke agents — it can't. - State the failure control: if one branch fails, does the rest still land, or does everything block?
- Name the human checkpoint, if any, before the result is treated as final.
Quality bar
- Recommend exactly one topology; only call out a hybrid if a branch is clearly independent.
- If one agent finishes the job, say that and stop — don't manufacture parallelism.
- Be concrete about what state crosses agent boundaries and who reconciles it, since it always has to pass back through the main thread here.