Choosing a coordination topology is the architectural decision that determines how multiple AI agents share work, route control, and recover from failure. This article compares the four principal patterns in production use today: the supervisor or orchestrator, collaborative peer-to-peer, adversarial generator-critic, and graph-based coordination. The material is aimed at engineers and architects designing multi-agent systems on frameworks such as LangGraph, CrewAI, and AutoGen who need a structured basis for that decision. Each topology is examined through its mechanism, trade-offs, and characteristic failure modes, drawing on the supervisor pattern, collaborative agents, adversarial architecture, and graph-based coordination queries present in current research and vendor documentation. The objective is to make topology selection a deliberate choice tied to workflow shape, observability needs, and budget, rather than a default inherited from framework scaffolding.
A coordination topology is the directed graph that defines who can call whom, who can hand off to whom, and who decides that the work is done. In a multi-agent system, it sits above the prompts, the tool definitions, and the model selection: the topology is the shape of the control loop, while the rest are the payloads that flow through it. Choosing a topology is therefore the architectural decision that determines how agents share work, route control, and recover from failure, and changing it later usually means rewriting the control loop rather than re-prompting.
Four patterns dominate current production practice:
The canonical references for this taxonomy are the Google Cloud agentic design patterns guide, which treats multi-agent coordination as one of several structured choices, and the LangGraph multi-agent architecture write-ups, which treat node-and-edge graphs as the substrate on which all four patterns are realized.
Production frameworks — LangGraph, CrewAI, AutoGen, Magentic-One, AgentVerse, and DyLAN — all implement variants of these four shapes. CrewAI's documentation, for instance, distinguishes a network architecture from a supervisor architecture as two of the most common starting points, while LangGraph (which reached v1.0 in October 2025) expresses both as the same underlying graph with different edge configurations.
This article compares the four patterns through a fixed lens: mechanism (how control and messages actually flow), trade-offs (cost, latency, debuggability, governance surface), failure modes (what breaks first when the topology is stressed), and decision criteria (workflow shape, observability needs, and budget). Topology selection should be deliberate and tied to those criteria rather than inherited from framework scaffolding.
In the supervisor (or orchestrator) pattern, a single central agent receives the incoming request, decomposes it into sub-tasks, decides which specialist agent should handle each one, and synthesizes the returned outputs into one coherent response. Specialists are typically narrow in scope — research, code generation, data analysis, drafting — and remain idle until the supervisor calls them. CrewAI exposes this topology directly through Process.hierarchical together with a designated manager_agent that selects which task to perform and which agent to assign it to (Machine Learning Mastery, "Building a Multi-Agent System with CrewAI"). LangGraph implements the same idea as a graph node whose outgoing edges fan out to worker nodes and whose incoming edges aggregate their results (Multi-Agent Systems with LangGraph).
There are two common implementations of the routing decision itself:
The supervisor is a single point of failure and a throughput bottleneck: if it crashes, hangs, or misroutes, the entire downstream chain is wrong or stalled (Multi-Agent Systems with LangGraph). Routing errors propagate, so the supervisor prompt usually demands as much iteration as the specialist prompts. Adding an LLM call on every request solely for routing should be weighed against a lightweight classifier; in many production deployments the rule-based variant is the cheaper default and the LLM variant is reserved for ambiguous inputs.
The pattern fits workflows where:
OpenAI's practical guide to building AI agents describes the same topology as the "manager pattern," noting that it is ideal when you want exactly one agent to control workflow execution and maintain direct access to the user.
In the collaborative peer-to-peer pattern, agents operate as equals on a shared communication surface — typically a public message channel or shared workspace — and any agent can hand off execution to any other agent at runtime. There is no central arbiter deciding who acts next; the iteration order emerges from the work itself. As described in the LangGraph multi-agent survey, "multiple agents work together without a central coordinator, passing messages to each other based on the task's needs. Each agent can invoke any other agent when it determines it needs help from a different specialty" (Architecting Multi-Agent Systems with LangGraph).
This matches the Google Cloud "multi-agent swarm" characterization: "Each agent can communicate with every other agent, allowing them to share findings, critique proposals, and build upon each other's work to iteratively refine a solution. Any agent can hand off the task to another agent better suited to handle the next step" (Choose a Design Pattern for an Agentic AI System). A canonical fit is non-linear workflows such as a coder-reviewer-tester loop in software development, where the same artifact must bounce between specialists several times before it converges.
The lack of a supervisor makes this the hardest pattern to debug and the easiest to get stuck in infinite loops, because no single node enforces a stop condition. Coordination complexity grows quadratically with agent count — every agent potentially talks to every other — so a graph that scales linearly in agents scales quadratically in possible transitions. Information loss at handoff points is a recurrent failure mode, and conflicting writes to the same shared resource are common when two agents react to the same intermediate output (Harness Engineering in AI Agents).
Teams should only adopt peer-to-peer after shipping a simpler supervised or hierarchical multi-agent system. The pattern demands explicit termination conditions — a clear "done" predicate every agent can evaluate — and hard cycle limits that the runtime enforces regardless of model output. Structured schemas for inter-agent messages reduce ambiguity at handoff points and make traces testable.
Peer-to-peer becomes practical rather than purely theoretical with LangGraph's Command primitive, introduced in late 2024. According to the LangGraph multi-agent survey, Command "allows nodes to dynamically decide which node to execute next at runtime — without needing pre-defined edges," enabling "edgeless flows" where "you don't need to pre-define every possible edge in the graph — the runtime decision replaces static edge definitions" (Architecting Multi-Agent Systems with LangGraph). For peer-to-peer specifically, this means agents can hand off to any other agent in the graph by returning a Command that names the next node, without enumerating every possible edge at compile time — the runtime decision replaces static edge definitions and keeps the topology maintainable as specialists are added.
The adversarial topology inserts structural opposition into the workflow. Two flavors dominate production use today.
The first is the generator-critic loop. One agent drafts an output, and a second agent — typically prompted differently and often backed by a different model provider — evaluates the draft against an explicit rubric such as factual accuracy, adherence to a style guide, or compliance constraints. The loop iterates until the critic approves, a fixed iteration budget is reached, or a quality threshold is met. Google's multi-agent review and critique pattern operationalizes this as an implementation of the loop agent pattern, in which a loop workflow agent drives the sequence of subagents and a termination condition decides when to stop. Truefoundry's taxonomy of agent architectures calls this the "proposer-critic loop" and describes deployments where a bank pairs drafting, brand-compliance, and jurisdiction-disclosure agents, surfacing disagreements to a human with the conflicting clauses flagged.
The second flavor is red-team / blue-team. Here the opposition is the design goal rather than a quality check. One agent probes a system with adversarial inputs, malformed payloads, or exploit chains, while the other agent detects and patches the openings. According to Kimi.ai's resources on multi-agent systems, this configuration is common in security testing because a single reviewer pursuing only one objective tends to miss the vulnerabilities that internal opposition naturally surfaces.
The topology roughly doubles model spend per round, because each iteration pays for a draft plus an evaluation, and latency scales linearly with the number of cycles. Engineering effort is also non-trivial: prompts must encode the rubric precisely, and disagreements between the two agents require explicit resolution logic rather than a silent majority vote.
Route unresolved disagreements to a human reviewer with the conflicting clauses flagged, rather than letting the orchestrator pick arbitrarily. A poorly specified critic produces vague feedback that degrades output on subsequent revisions; the critic must be demonstrably better at evaluating quality than the generator is at producing it. Run budgets on iterations, tokens, and wall-clock time so a stuck loop cannot burn cost indefinitely.
Pick this topology when outputs must clear compliance, brand-safety, or factual-accuracy bars, and when the workflow rewards internal opposition — security testing, regulated content generation, and any domain where a single reviewer is structurally blind to its own blind spots.
Graph-based coordination encodes the workflow itself as a graph object rather than as a chain of agent-to-agent calls. The graph becomes the source of truth for execution order, dependency handling, and message passing, which makes the topology inspectable and reproducible in a way that implicit hand-offs are not.
Two distinct graph abstractions appear in the literature. The Task Dependency Graph (TDG) is a directed acyclic graph (DAG) whose nodes are subtasks and whose edges encode execution-order dependencies; the DAG constraint is deliberate, since it guarantees no dead loops during planning and dispatch. The Agent Coordination Graph (ACG), by contrast, places agents as nodes and communication paths as edges, with message passing occurring between connected agents (see the taxonomy in "Graphs Meet AI Agents"). TDGs are typically used to drive planning over decomposable work, while ACGs are used when the question is "which agents should talk to which other agents" rather than "which subtasks depend on which."
When prior agent-to-agent relationships are not known in advance, the same survey identifies three classes of methods for optimizing ACG topology:
Prefer an explicit, hand-authored TDG shaped as a DAG for long-horizon plans: it is cheap to inspect, simple to test, and matches the way engineers already reason about workflows. Reach for learned ACG topology only in domains where hand-engineering edges is infeasible — for example, traffic control, packet routing, or other environments where the optimal neighbor set changes with the state of the world and cannot be reasonably enumerated.
LangGraph's StateGraph covers the static-graph case: nodes represent agents or processing steps, and edges (including conditional edges that branch on state) define the routing between them. For the edgeless, runtime-decided case, the Command primitive lets a node return a Command that names the next node to execute, replacing a pre-declared edge with a runtime decision. The same framework thus supports both sub-flavors of graph-based coordination: declarative DAGs with conditional edges for plans whose shape is known in advance, and Command-driven edgeless flows for plans whose shape is decided at execution time.
Empirical studies report that multi-agent systems fail on more than 60% of real-world tasks, with the failures rooted in coordination design rather than the underlying model's reasoning (MAST taxonomy write-up). The Multi-Agent System Failure Taxonomy (MAST) groups14 failure modes into three buckets:
Independent of any taxonomy, every multi-agent system inherits the failure classes of any distributed system with shared mutable state and no shared clock (multi-agent systems have a distributed systems problem):
Because these failure modes are not framework bugs but inevitable consequences of multiple autonomous processes sharing state, a small set of guardrails belongs in every topology:
interrupt primitive pauses graph execution at a checkpoint, surfaces a payload to a reviewer, and resumes via Command(resume=...) (architecting multi-agent systems with LangGraph). The exact signature, payload shape, and resume mechanism have evolved across LangGraph releases, so treat the interrupt surface as version-sensitive and pin the runtime, checkpoint store, and thread configuration together.
Topology choice becomes tractable when each pattern is mapped to the shape of the workflow rather than to framework defaults. A simple rule of thumb: pick the topology whose control-flow shape most closely matches the work.
Pure topologies are reference points; production systems are almost always composite. The most common arrangement is a supervisor that delegates to peer-to-peer worker clusters, or a generator–critic pair nested inside a supervisor that owns user interaction. LangChain's matrix shows that no single pattern scores well on every axis, which is why blended designs dominate in practice.
Multi-agent systems are consistently slower, more expensive, and harder to debug than a single well-prompted agent. The pragmatic rule is to resist adding a second agent until a single agent has been demonstrated to fail on the target workload. When that bar is met, a Supervisor + Specialists layout is the lowest-risk starting point because it preserves observability, isolates failures, and lets each specialist use the cheapest model that meets its quality bar.
Graphify produces a queryable graph.json of the codebase and surrounding material. The build step uses tree-sitter for local AST parsing, extracts symbols and relationships deterministically, and groups them into communities. Three artifacts are written to graphify-out/: an interactive graph.html, a human-readable GRAPH_REPORT.md, and the machine-readable graph.json that downstream tools load. Because extraction is local and deterministic, the same input yields the same graph on every run, which is what makes it safe to share across agents.
graphify-mcp-tools loads that graph.json into an in-memory SQLite database and serves queries to agents over the MCP stdio protocol. Runtime is Node.js only — Python is required only for the initial graph build. Seven tools cover the retrieval shapes a multi-agent system actually needs:
graph_search — indexed text search with type and repo filters, plus BFS/DFS context expansiongraph_impact — BFS blast radius for upstream and downstream dependents of a symbolgraph_path — weighted Dijkstra shortest path between two symbols, with edge-type filtersgraph_explain — full detail on a node, including all edges, community membership, and centrality metricsgraph_community — list nodes belonging to a community, ranked by degreegraph_hotspots — most connected nodes, supporting degree, in/out degree, and betweenness centralitygraph_outline — tree-sitter code outline for any file: functions, classes, imports with signaturesThe graph-query tools can be registered once at the system level. A supervisor routes through them when it needs grounded context before delegating. A peer-to-peer worker calls them when it is unsure about the blast radius of a change. A critic uses them to verify claims against the actual call graph. A planning node uses them to weigh architectural alternatives. Because every role reaches the substrate through the same tool surface, topology choice stays orthogonal to memory choice — moving from supervisor to peer-to-peer does not require re-implementing context retrieval inside every agent.
Build the graph once, expose it once, and let each topology route through it. Pipeline composition, retrieval-comparison patterns, read/write memory loops, and hook patterns are covered in sibling articles and intentionally not duplicated here.