Supervisor pattern (the default)
Who uses it: Developer building a first multi-agent system
One supervisor plans and routes work to workers
Workers: research, coding, writing — each with its own tools
Workers report back to the supervisor, not to each other
Shared memory holds intermediate results
Supervisor decides when the overall task is done
Why this works: The supervisor pattern is the cleanest place to start because control is centralized — one agent owns the plan, so you always know who decided what, which makes debugging far easier than a free-for-all.
Hierarchical teams
Who uses it: Team scaling beyond a handful of agents
Top supervisor delegates to team-lead agents
Each team lead supervises its own group of workers
Example: a 'research team' and a 'build team' under one top agent
Memory is scoped — team-local plus a shared global store
Failures are contained within a team before escalating
Why this works: Hierarchy is how multi-agent systems scale without one supervisor becoming a bottleneck — sub-supervisors absorb local coordination, so the top agent reasons about teams, not individual workers.
Peer-to-peer agents
Who uses it: Engineer building agents that negotiate directly
No central supervisor — agents message each other
Each agent decides what to hand off and to whom
A shared message bus or blackboard coordinates state
Useful for debate / critique loops between equal agents
Risk: harder to trace and can loop without a stop condition
Why this works: Peer-to-peer trades the clarity of a supervisor for flexibility — agents self-organize, which suits debate and critique patterns, but the diagram must show the stop condition or the system can loop forever.
Human-in-the-loop
Who uses it: Team deploying agents for high-stakes output
Supervisor delegates as usual to worker agents
An approval gate pauses before irreversible actions
A human reviews and approves, rejects, or edits
Approved work continues; rejected work routes back to a worker
Every decision is logged for audit
Why this works: Human-in-the-loop is essential when agent output has real consequences — the diagram makes the approval gate explicit so reviewers can see exactly where a human must sign off before the system acts.
