LangGraph multi-agent orchestration: the production playbook

• Graph execution is the point: LangGraph gives agents explicit state, routing, loops, interrupts, and recovery within a single graph.

• Reducers are operational logic: A reducer decides whether two agent updates merge or one silently replaces the other.

• Supervisors are useful until they hoard authority: Central routing is readable, but it can hide bottlenecks and bad delegation rules.

• The graph boundary is real: LangGraph does not provide a cross-framework registry, delivery lifecycle, or organization-scoped permissions.

• BAND is best suited to mixed runtimes: Use it when LangGraph agents need governed interaction with agents built elsewhere.

The LangGraph graph API is built around three primitives: State, Nodes, and Edges. That is a small surface area, which is why people underestimate it.

In LangGraph multi-agent systems, agents may run as graph nodes. Handoffs are typically tool-driven: a handoff tool returns a Command that updates state and transfers control to another agent or configuration. State holds the current working record. The value lies not in the diagram itself, but in making routing and state mutation inspectable code instead of behavior buried inside a prompt.

LangGraph vs. LangChain

LangChain gives you model calls, tools, prompts, retrievers, and chains. LangGraph gives you a runtime shape for work that needs to branch, loop, pause, and resume.

If the job is a straight line, a chain is enough. If the job can revisit a step, wait for a human, or choose a different worker after seeing partial output, the graph earns its keep.

Where it sits (framework, not platform/infrastructure)

LangGraph sits at the framework layer. It owns execution flow and state inside a graph-shaped application. It does not own agent identity across teams, message delivery between services, or permissions for agents that live outside the graph.

That scope is reasonable. It is also the line many production designs blur.

LangGraph runs through a shared state object. Every node reads the state it needs and returns an update; the graph then applies that update before deciding what should run next.

The runtime advances in super-steps, a model borrowed from Google's Pregel system. Nodes can run in parallel during a super-step. Across super-steps, updates settle before the next set of active nodes runs. That detail matters when several agents write to shared state in the same phase of work.

Nodes, edges, and the state object

Nodes are plain Python functions. They take the state and return the keys they changed. START and END mark where input enters and where execution stops.

Edges do the routing. A normal edge gives you a fixed next step. A conditional edge asks a function to choose the next node based on the state. In a multi-agent graph, delegation becomes concrete: not "ask the right agent" but a routing function with allowed destinations.

Reducers and state updates

Reducers decide how state absorbs updates. Without a reducer, a new write replaces the old value. With operator.add, add_messages, or a custom reducer, updates can accumulate or merge according to the rules you choose.

This is not a syntax footnote. In a multi-agent graph, the reducer is part of the coordination policy. If a researcher and a reviewer both write messages, the reducer decides whether the graph keeps both contributions or discards one. If a worker updates the status, you may want replacement instead of accumulation. Treat those choices like runtime behavior, because that is what they are.

The LangChain multi-agent docs make a point worth keeping in mind: many tasks do not require multiple agents. A single agent with a clean tool set is often easier to run and debug.

Use several agents when the work has different roles, different context requirements, or different authority boundaries. In LangGraph, that usually starts with one of two shapes.

The following sections describe raw Graph API implementations. In LangChain's current higher-level terminology, the closest equivalents are Subagents, where a main agent coordinates workers as tools, and Handoffs, where tool calls transfer control between agents.

Supervisor pattern

The LangGraph supervisor pattern puts a coordinator node in charge of routing. A typical build looks like this:

1. Define a shared state with a messages channel and an add_messages reducer.

2. Add a supervisor node that inspects state and decides which worker should act.

3. Add worker nodes (research, analysis, writing) as separate functions.

4. Use a conditional edge from the supervisor to route to the chosen worker.

5. Route workers back to the supervisor so it can decide the next step or finish.

I like this pattern for the first production version because it provides a single place to inspect routing decisions. The trade-off is authority concentration. If every worker has to ask the supervisor what to do next, the supervisor becomes the policy layer, queue, router, and sometimes the excuse for not clearly defining worker ownership.

Network/peer pattern

The network pattern lets agents hand off to each other directly. Each node can route to another node through conditional edges or return a Command that updates state and chooses the next destination.

This fits workflows in which the next-best actor depends on what the current agent has just found. It also spreads authority. Before using it, decide which agents may hand work to which peers, what context they may pass, and how you will reconstruct the path after a bad run. Otherwise, the graph stays valid while the workflow becomes hard to explain.

Google Cloud's agentic design pattern guide separates sequential, parallel, loop, and coordinator patterns. LangGraph expresses those patterns as a graph structure rather than separate product modes.

That is why it works well for agentic systems. The path can change while the task is running, and the graph still has a concrete execution record.

Sequential execution

Sequential execution moves work through a fixed order of nodes, with each step receiving the state produced by the previous one. It fits workflows with clear dependencies, where one agent must finish before the next can begin. The trade-off is that a slow or failed node blocks everything downstream.

Cyclic execution and loops

Cycles let an agent retry, critique, or refine before the graph exits. A reviewer can send a draft back to a writer. A planner can ask a researcher for another pass. A tool-using agent can recover from a failed call and try a different route.

Loops need a defensible stop condition. In LangGraph 1.0.6 and later, the default recursion limit is 1,000 steps. LangGraph raises GraphRecursionError when a run reaches the limit. You can change the limit by passing recursion_limit in config, while RemainingSteps lets a node see the remaining budget and adjust its behavior before the graph reaches it.

Conditional edges and routing

Conditional edges are the practical mechanism behind LangGraph multi-agent orchestration. add_conditional_edges maps the output of a routing function to destination nodes. Command lets a node update state and choose a goto in the same return.

The failure mode is familiar if you have operated any router. You wrote branches for the cases you imagined. The case you missed still has to go somewhere. For production graphs, I want explicit fallback routes, typed routing outputs where possible, and enough state in the trace to show why the router chose that worker.

LangGraph handles orchestration inside its own graph. That includes state, nodes, edges, interrupts, checkpointed execution, and routing decisions made by graph code.

The confusion starts when teams use "orchestration" to refer to every operational concern related to agents. LangGraph does not become a registry, delivery system, permission model, or cross-framework recovery layer just because the graph coordinates several agents.

Inside the graph boundary

Within the boundary, LangGraph provides durable state via checkpointers, deterministic super-step execution, interrupts, parallel fan-out, conditional routing, and graph migrations that handle many topology changes.

For a single application owned by a single team, that can be enough. The team can inspect the graph, replay a run, and reason about the state using a single mental model.

What LangGraph does not solve

Outside the boundary, different questions show up:

• Which team owns the agent being called?

• Which agents may invoke it?

• Did the external agent accept the work, process it, fail it, or retry it?

• What happens to work in flight if that external runtime restarts?

Those are not graph topology questions. They are infrastructure questions. Adding more edges may make the diagram look complete, but it will not give an external CrewAI agent a shared identity or delivery lifecycle.

Cross-framework coordination is where a good LangGraph design usually meets the rest of the company. One team has a graph. Another has a CrewAI crew. A platform group has a custom Python service wrapped as an agent. Nobody wants to rewrite the working pieces just to make them talk.

So the translation problem arises.

The cross-framework problem

The common path is pairwise glue code, and a graph does not save you from it. LangGraph still needs a connector to a CrewAI integration, CrewAI needs another to a custom agent, and the custom agent needs a wrapper for an A2A endpoint. Each connection carries its own message shape, history mapping, timeout behavior, and definition of "done."

That does not fail on day one. It fails when nobody can say which connector owns retry state after a bad run. DAG-style orchestration does not fix it either: a graph can describe control flow without normalizing the runtimes it calls.

Adapter-based integration

An adapter provides the LangGraph graph with a single entry point to a shared layer, rather than one connector per peer. The graph stays the graph. CrewAI keeps its crew model. A custom agent keeps its internal service contract. The adapter handles message format, history mapping, delivery state, and recovery at the boundary.

That is the split worth keeping. The graph decides what happens inside the LangGraph workflow. The layer around it decides how an outside participant is addressed, invoked, tracked, and recovered.

When LangGraph agents need to work with agents built elsewhere, the missing piece is not another graph pattern. It is a shared interaction layer around the graph: identity, addressed routing, delivery state, ownership, and recovery across runtimes.

This is where BAND fits. BAND provides framework-agnostic interaction infrastructure through an agentic mesh and Agent Control Plane. LangGraph remains the place your graph logic runs. BAND becomes the place where heterogeneous agents discover each other, exchange work, and leave an operational record.

The LangGraph adapter

BAND's LangGraph integration wraps a graph as a registered agent on the mesh without rewriting the graph. Through framework adapters, the LangGraph agent obtains a discoverable handle, joins a ChatRoom, and processes messages when it is mentioned.

That mentioned rule is small but useful. It keeps a shared context space from becoming a broadcast room where every agent reacts to every message. The graph internals stay intact while the adapter handles format conversion, history mapping, and delivery state at the boundary.

Governance and observability around LangGraph

Around the graph, BAND adds controls LangGraph has no reason to implement: agent ownership, RBAC, organization-scoped visibility, Guidelines for agent behavior, and per-message delivery tracking with attempt history across services.

The layer split matters. BAND does not replace LangSmith for prompt tracing or evals. It does not monitor model drift. It governs how distributed agents discover, delegate, and recover when the work crosses framework and process boundaries. The BAND platform shows how those primitives wrap a LangGraph deployment without making the graph the entire operating model.