Multi-agent systems with LangGraph: choose the architecture by workload and control

Key takeaways

• Multi-agent work must create enough value to cover its added performance cost.
• Heavy parallel work, oversized context, and numerous complex tools are strong signals.
• Shared context across every agent and many inter-agent dependencies are poor fits today.

For builders evaluating multi agent systems with LangGraph, the topology is only the visible part of the decision. We treat the graph as an architecture contract. It assigns work, but it also determines where state lives, where people can pause execution, and what happens when a paused node runs again. A convincing demo can leave those obligations unanswered. The architecture has to make them explicit.

When do multi-agent systems with LangGraph earn their cost?

The architecture choice has two gates. The pattern depends on workload characteristics, and the task value must cover the cost of increased performance. The worksheet keeps that fit test beside the state, approval, and replay choices that make the graph operable.

The worksheet can reject a poor fit before coordination code accumulates. If the fit survives, it narrows the LangGraph multi agent architecture to a topology and makes its control obligations visible. Our comparison of agentic AI and multi-agent systems helps frame the earlier decomposition choice.

Request shape changes the call and token bill

Pattern fit does not determine runtime cost by itself. Request shape changes both calls and tokens. In the documented one-shot scenario, subagents used four calls. Handoffs, skills, and the router each used three.

The repeat-request scenario changed the spread. Subagents used eight calls, handoffs and skills used five, and the router used six. Those figures make repeat work a different cost case from a single request, even when the candidate patterns stay the same.

The call gap also changed with the request. In the one-shot case, subagents made one more call than each of the other patterns. With repeat requests, subagents made three more calls than handoffs or skills and two more than the router. Handoffs and skills remained tied in both scenarios, while the router moved from their one-shot tie to one extra call on repeat work.

The documented multi-domain scenario adds the token side of the comparison. Subagents and the router each used five calls and 9K tokens. Handoffs used 7+ calls and 14K+ tokens. Skills used three calls and 15K tokens. In that scenario, the smallest call count did not produce the smallest token count.

Subagents and the router were identical on both reported measures in the multi-domain case. Handoffs used more calls and tokens than either. Skills used the fewest calls and the most tokens of the four listed patterns. Call count and token use are separate measures in the documented scenario.

Supervisor flexibility is not free

A supervisor can be attractive because the evaluated architecture made fewer assumptions about its underlying agents than the other architectures in the benchmark. That generality leaves more room for different agent designs, but a naive supervisor implementation may produce worse results.

The token mechanism is concrete. In the documented benchmark, the supervisor used more tokens than the swarm because it translated subagent responses. The swarm allowed subagents to respond directly to the user. Translation becomes part of the supervisor's operating cost, not just a diagram box between agents and the user.

That response path is an architectural choice. The supervisor sits between the subagent and the user in the documented implementation, so it performs another language step. The swarm's subagent-to-user path removes that translation step. The benchmark connects that difference to the supervisor's higher token use.

This is why we would not select a supervisor from topology alone. The decision includes who produces the user-facing response and how much context the supervisor must receive and restate. The supervisor may accept a wider range of underlying agents, while its mediation path adds work. For other routing structures and failure shapes, see our agent architecture patterns.

Scaling depends on context transfer and operating tools

Cross-domain scale depends on what moves between agents. Improving information transfer between subagents and the user, together with context management, can improve performance while retaining the ability to scale across domains. Make information transfer to subagents and the user explicit beside the routing design.

In the documented benchmark, single-agent token use increased as the number of distractor domains grew. Supervisor and swarm token use remained flat. That creates a concrete evaluation question for a domain-heavy workload: does token use rise as irrelevant domains are added?

Operating the system also requires more than routing. Multi-agent and complex single-agent systems require durable execution, debugging, observability, and evaluation tooling. Those are harness responsibilities around the model. Our agent orchestration glossary provides the broader vocabulary for that control layer.

State scope comes before agent boundaries

Before drawing agent boxes, decide which data is thread-scoped, cross-thread, or expected to cross a subgraph boundary. LangGraph Stores persist application-defined data outside graph state. They support long-term, cross-thread memory such as user preferences, facts, and shared knowledge.

Subgraph state follows a different mechanism. A parent graph may not immediately see a subgraph's state update because each subgraph manages its own checkpoint namespace. If the data must cross that graph boundary, use shared state through a Store or write it from the subgraph to the parent checkpoint.

The checkpoint namespace is a visibility boundary. A subgraph can manage its update in its own namespace while the parent lacks an immediate view of that change. Shared state through a Store gives cross-boundary data another route. Writing the update to the parent checkpoint puts it where the parent graph can receive it.

Consider a preference that should remain available across separate threads. That belongs in the Store. Now consider a subgraph result that the parent needs for its current execution. That result must reach shared state or the parent checkpoint. Putting both behind a vague "memory" label hides two different persistence choices.

Three questions expose the scope before implementation: should the value survive across threads, should a parent graph receive it, and which checkpoint namespace owns it now? The documented mechanisms answer the first two. A Store holds application-defined cross-thread data, while shared state or the parent checkpoint carries a required subgraph update across the graph boundary.

LangGraph multi agent orchestration becomes easier to reason about when the state scope is explicit. The agent boundary can then follow the data boundary, instead of forcing later code to repair an accidental checkpoint design.

State updates need explicit merge rules

Within a graph, agents can read from and write to a central state schema. Nodes return dictionary updates, and reducer functions merge those updates into global state. The node should return a partial state-update dictionary instead of mutating state directly.

Suppose two nodes each return an update to a list field. That list needs a reducer. Without one, the last write wins. The consequence is especially visible when parallel branches produce separate results and the state model is expected to retain both.

A partial update names the state fields changed by one node. The reducer then defines how those returned values enter global state. This separates the node's work from the merge behavior. For list fields, that merge behavior must be explicit because an absent reducer leaves the final write as the stored value.

The implementation rule is compact: define the central schema, have each node return only its update, and give collection fields the reducer that merges those updates. A central-state implementation makes the read, partial-update, and reducer path explicit. This keeps state change legible at the graph boundary and avoids hiding coordination inside in-place mutation.

This state contract matters before parallel branches are added. Every branch can return its own partial dictionary, while the reducer owns the combined result. The graph's merge rule remains visible in the state definition instead of being spread across node mutations.

How should approval pauses work?

Approval should sit on the tool call that needs a decision. Human-in-the-loop middleware checks tool calls against a configurable policy. When intervention is required, it issues a LangGraph interrupt. The middleware can pause a proposed file write or SQL execution and wait for a human decision.

The pause is part of execution, not a detached message. LangGraph persistence saves graph state while human intervention is pending, so the system can resume later. That gives the approval a durable place in the trajectory.

The execution path is inspectable: middleware checks the proposed tool call against policy, an interrupt pauses the graph when intervention is required, and persistence saves the current state. The human decision can then occur while the graph is paused, with the saved state available for later resumption.

There is one replay boundary to design around. An interrupt reruns its containing node, so any side effect performed before the interrupt should be idempotent. Place the approval with a clear view of what the node has already done and what a rerun could repeat.

Parallel edges change the coordination mechanics

Parallel execution is a graph choice, not just several agents starting at once. In one documented parallel-edge implementation, agents see the same state snapshot and their updates are merged. That state behavior connects parallel topology to the reducer rules above.

The edges also encode different interaction models. Handoff edges create transfer tools, while parallel edges create direct graph connections without tools. A transfer tool makes the handoff an agent action. A direct edge places the parallel branch in graph structure.

In code review, locate the coordination mechanism itself. A handoff should expose its transfer tool. A parallel branch should expose its direct graph connection. That inspection keeps a tool-mediated transfer distinct from graph-defined fan-out.

Parallel execution can significantly speed processing when agents perform independent work. Independence is the operative condition. If one branch needs another branch's result, the work has a dependency that the graph must represent. The gain comes from concurrent independent work, while the merge still needs explicit state behavior.

Parallelism follows the dependency graph

Dependency-aware parallelism starts independent work concurrently and waits where dependencies make waiting necessary for quality. This gives the graph a concrete scheduling rule. Concurrency follows the work that can proceed from the same available inputs.

A review flow makes the distinction clear. Parallel reviewers can separately check code quality, business logic, and security. After those reviews, issues can be routed to the relevant agent for repair. The three reviews can begin as independent work. Repair depends on the issues they produce, so it waits.

The reviewer topology has two phases without forcing every check into a serial chain. Code quality, business logic, and security reviews start from the work under review. Their reported issues then become inputs to the repair route. Dependency-aware scheduling preserves that ordering while allowing the independent checks to proceed together.

This is a better test than asking whether a workflow is "parallel." Mark the inputs each node needs and the updates it returns. Direct edges can start nodes whose inputs are ready. Dependencies identify the points where waiting protects the quality of later work.

What do runnable LangGraph examples expose?

A useful LangGraph multi agent example on GitHub should expose more than an agent loop. One public runnable swarm template includes a triage agent, three specialists, direct agent-to-agent handoffs through Command, a recursion guard, and traceability. That payload exposes routing, control, and inspection mechanics together.

The same LangGraph multi agent GitHub source provides runnable subgraph composition examples for different state schemas, shared state keys, and per-thread namespace isolation. Those examples are useful when the core question is not which specialist to call, but how parent and subgraph state should meet.

A separate integration pattern draws another boundary: LangGraph owns workflow, state, and routing, while a Claude Agent SDK invocation inside each node owns tools, context, and agent capabilities. It shows that graph orchestration and node-level agent capability can have distinct owners.

This split is useful when evaluating a LangGraph multi agent example GitHub implementation. The graph can remain responsible for execution order and shared state without absorbing every node's internal tool and context design. The node-level SDK invocation can retain those agent capabilities inside the boundary LangGraph routes.

When reviewing LangGraph multi agent patterns, inspect the runnable example for topology, state scope, transfer mechanism, recursion control, traceability, and replay behavior. Then compare your workload against our multi-agent orchestration architecture guide before you add another agent.