LangGraph multi-agent architecture: what held up in production

When a graph beats a tool-calling loop

A LangGraph execution graph beats a plain tool-calling loop when the work branches, has to survive a restart, or needs a person's approval partway through. A loop asks the model what to do next until it stops; a graph makes the possible paths explicit as nodes and edges, so retries, handoffs and failure routes are code you can read.

For a single agent that answers a question with two or three tool calls, the loop is the right design and a graph is overhead. The platform that taught us where the line sits was an autonomous agent workflow product built over around 800 billed hours and rated 5.0 by the client. Its agents carried out multi-step jobs on their own, handed work between each other when the task changed shape, and did it while holding a real-time voice conversation. A loop could not keep up with the branching, and a restart lost everything in flight.

The shape of a production execution graph

A production graph has a supervisor node that decides which worker to route to, worker nodes that each own one kind of task with their own tools, and an approval node that holds the graph before any write with consequences. State flows along the edges and is saved at every step. Everything else is detail inside a node.

On the agent platform the supervisor was deliberately thin. It read the current state, classified what was needed and routed; it did not do the work itself. Each worker had a narrow tool set and a narrow prompt, which made them easy to test in isolation and easy to replace. Handoffs between workers were edges in the graph with conditions on the state, so a change in task shape, a research job that turned out to need a booking, for instance, took a defined path instead of improvisation inside one long prompt.

The branches we drew that paid for themselves were the ones for failure. A tool call that errors goes to a retry edge with a counter in the state; a retry that exhausts goes to a node that writes down what was tried and asks a person. Drawing those paths in advance is what makes an agent predictable enough to run without someone watching.

Structured tool contracts

Agents on the platform called tools through typed schemas with narrow scopes rather than free-form text. Each tool declared its inputs as a schema, validated them before anything ran, and returned a typed result. Reads and writes were separate tools with separate permissions, so a worker that only needed to look things up could not change anything.

The read-write split sounds like bureaucracy until the first time a model decides to be helpful. A single manage_record tool with an action field is one bad argument away from a deletion; get_record and update_record as two tools, with the update behind the approval node, are not. We also kept tool descriptions short and literal. The model reads them on every call, and a description that oversells what the tool does produces calls that fail validation.

Validation on the way in mattered as much as the schema. The model's arguments were parsed and checked before the tool ran, and a failed check went back to the model as an error result it could correct, not as an exception that killed the run.

Persistent state so long work survives restarts

Workflow state was saved as the agents worked, after every node, so a deploy or a crash in the middle of a job was a pause rather than a loss, and the graph resumed from the last saved step when the process came back. LangGraph's checkpointing gives you this; the engineering is deciding what belongs in state.

Our rule was that state holds facts, not transcripts: the job's inputs, which steps have completed, the results that later steps need, the retry counters and the pending approval if there is one. The conversation with the model is reconstructed from those facts when a node runs, which keeps the saved state small and makes it readable when you are debugging a job that stopped at three in the morning.

Persistence also gave the product something it could sell. A job that takes an hour can be started, left, and checked on, and the status page reads the same state the graph does.

Human approval nodes before writes

Every write with consequences, sending a message on the user's behalf, changing a booking, spending money, passed through an approval node. The graph reached the node, saved state, and stopped. A person saw the proposed action with the evidence that led to it and approved or rejected it; the graph resumed on the answer.

This is the orange node on every diagram we draw, and it is the part clients push back on first because it looks like it slows the agent down. It does, for the actions that deserve it. The approval log also showed which action types the agent got right every time, which is the evidence you need to take the human out of the loop for those types later. Automation earned step by step, with a record, is how an agent gets trusted with more.

Observability

Every node entry, every tool call with its arguments, every result and every routing decision was logged with the job's identifier. When an agent did something odd the question was answerable in minutes: which worker, which step, which tool, what came back. Without that log, debugging an agent is reading the model's mind.

We kept the logs structured rather than prose, so they could be queried, and we logged the state before and after each node rather than only the model's text. The model's text is the least informative part of a failing run.

Running the same graph behind a voice pipeline

The agent platform put real-time voice on LiveKit and ElevenLabs in front of the graphs. Users talked to the agents in real time while the same tools and state ran underneath. The voice layer handled speech in and out; the graph handled thinking and doing.

Voice tightens the latency budget on every step. A graph that waits a few seconds between nodes is fine for a status page and painful on a call. The adjustments were in design rather than framework: workers in the voice path did one thing each, slow tools ran as background jobs the agent could report on later, and the pipeline acknowledged the user while the graph worked. The approval node still existed; on a call it became the agent asking the user to confirm before acting.

LangGraph, a plain loop or a vendor agent SDK

The three ways to build the control flow, row by row.

We recommend the plain loop for single-shot agents, LangGraph when two or more of the middle rows apply, and a vendor SDK when the team is committed to one provider and values speed of setup over control. The agent platform sat squarely in the LangGraph column on every row.

Questions we get about LangGraph

Is LangGraph tied to one model provider? No. The graph is control flow; the model inside a node can be Claude, OpenAI or anything with a tool-calling interface, and can differ per node.

How do agents hand work to each other? Through the state and the edges. A worker writes its result into state; a conditional edge reads the state and routes to the next worker. There is no agent-to-agent chat.

Where does the state live in production? In a database the checkpointer writes to after every node. Postgres is the usual choice; the requirement is that a new process can read the state and resume.

How long does a build like this take? The agent platform ran to around 800 hours over several increments. A first graph with a supervisor, two workers and an approval node is a much smaller build; the written plan sets the number.

What we would do on your project

We draw the graph before we write it: the supervisor, the workers, the tools each may call, where the state is saved and which actions wait for a person. That drawing, with the trade-offs named, is the discovery sprint, from $2,500. Book a free architecture call and we will tell you on the call whether your agent needs a graph at all. The build it comes from is the autonomous agent platform, and the AI agent development service covers the rest.