The five multi-agent architectures and agent communication

What you'll learn

• Explain the one primitive under every LangGraph architecture: a node that writes to state and names the next node.
• Compare network, supervisor, tool-calling supervisor, hierarchical and custom workflow by who decides what runs next.
• Diagnose a runaway loop, and stop it with recursion_limit.
• Choose what agents exchange: messages, typed fields or a draft and its critique.

Lesson 1 of T11.1 ended on a fixed graph: a crew whose order is known before it runs. Larkspur's support requests do not come in a fixed order. How long does a refund take? needs billing alone. My server went down last night. Do I get service credits? needs operations, then billing. The T9.3 router picks one knowledge base once, and on the outage request it answers the outage and never reaches the credits. Something has to decide, at run time, which agent runs next.

The command that transfers control

Every architecture in the routing notebook is built from one return value. A Command is what a node returns to do two jobs at once: write an update to state and name the node that runs next. Its parts:

Table 1: The fields of a Command and the annotation that declares its targets.

add_edge fixes a path when the graph is built, and Command(goto=...) picks one at run time. Most real systems use both. A target listed in the annotation that the code never returns still appears as an edge, which is why the notebook keeps each Literal to the branches the function can take.

The five architectures impose different rules on that one capability:

Table 2: The five architectures by who holds the routing decision.

We ran the notebook's four StateGraph builds with the model replaced by a stub that answers "ok". Routing in the notebook keys off role tags the code adds to each reply, never off the model's wording. The paths below are the ones a live run takes:

Table 3: Paths from the notebook's graphs with a stub model. The network's reviewer sends the draft back once, then ends on its second visit.

The reviewer-to-writer hop in the network is wired by no add_edge. The reviewer chooses it. In the supervisor run only the workers' messages appear, because the supervisor routes without appending a message. A router that writes nothing keeps the transcript readable: it holds only the work.

The tool-calling supervisor needs no routing code. Each specialist (billing, technical, general) is wrapped as a tool, and InjectedState hands it the graph's state without the model passing it as an argument. The tool's docstring is the routing rule, because it is the description the model reads. The notebook's mixed query, "trouble with my bill and the app keeps crashing", may call one specialist or two from one run to the next. That variability is the trade: routing quality becomes a prompt and description problem, and you can no longer read the rules in code.

Planted failure: the runaway loop

A network has no node that can say "stop". The notebook plants a runaway loop: two nodes, ping and pong, that hand off to each other forever. LangGraph counts super-steps and stops a run at recursion_limit:

Table 4: The ping-pong loop under each limit. The default comes from LangGraph's installed source.

The limit caps steps, not time. Twenty-five steps of a graph that calls a model at every node is still slow. The limit guards against runaway loops and is no timeout. Pass it on every run.

For Larkspur, the choice comes down to a few questions in order:

Figure 1: Choosing an architecture. Each "no" moves one question down.

The support assistant's order is not known in advance (a question may need one specialist or two), so it starts at the second question. The answer depends on whether conversations stay with one specialist across turns. A swarm is a network in which the handoffs are tools and the graph remembers who holds the conversation. Lesson 4 of T11.1 builds the supervisor and the hierarchy, and lesson 5 of T11.1 builds the swarm. Who runs next is half the design, and the next section covers the other half.

While agents run, they pass work to each other through state. The optional notebook builds three patterns for that:

Table 5: Three ways agents exchange work.

With typed fields, a malformed reply fails validation instead of silently becoming a wrong value. The analyst's confidence must lie between 0.0 and 1.0, and the collector must return points with a source and a finding. Downstream agents read those fields directly and parse nothing.

A critic that quotes its evidence

The generator and critic loop shows how to keep a model from ending its own loop. A critic that answers yes or no can approve a draft that misses a criterion, and nothing checks it. We call this the lenient critic. The notebook's critic never gives the verdict. For each of three criteria (a named LangGraph feature, a concrete use case, a trade-off) it copies the sentence from the draft that meets it, or writes none. Code computes the verdict:

Figure 2: The generator and critic loop. The model supplies quotes, and code decides.

We ran the notebook's check function on a three-sentence Larkspur draft ("LangGraph checkpointers let a support thread resume. A billing agent and an outage agent can share one graph. The cost is more model calls per request.") with planted critiques:

Table 6: The critic check on planted critiques (notebook functions run with a stub model).

An invented quote cannot pass, because membership in the draft is tested in code. MAX_ITERATIONS = 3 ends the loop whether or not the critic ever approves.

Key distinction: this loop is not a blackboard. Its order is fixed (draft, critique, draft), and only the exit is decided at run time. A blackboard has a controller that picks which of several specialists acts next from what is on the shared board. T11.2 builds one.

The code for this lesson is in these notebooks. Colab runs one in your browser: install the packages its first cell imports and set the API keys it reads. To run every notebook as written, clone the repository and use its uv environment.

• Build every architecture from one primitive, a node returning Command(goto=..., update=...). add_edge fixes a path at build time, Command picks one at run time, and most systems use both.
• Pick the architecture by who should decide what runs next. Use a custom workflow when the order is known, handoffs when the conversation should move with an agent, and a supervisor when routing must be auditable.
• Always pass recursion_limit, since the default is 10,007 super-steps. In a generator and critic loop, have the critic quote evidence per criterion, compute the verdict in code and cap the iterations.