Why linear call chains break, and LangGraph doesn't
A linear call chain looks reliable while the scenario is short: a step, another step, an answer.
As soon as branching appears — "if data is missing, ask the user for clarification" — the code turns into a tree of conditions, and the agent's state gets smeared across local variables and intermediate dictionaries.
Add a loop like "ask again and wait for confirmation," and tracking which step we are on becomes a separate task.
The worst behavior comes from a failure in the middle of the scenario.
The process crashes on the fifth step out of ten — and re-running the step again performs what has already passed: the email is sent a second time, the CRM card is created as a duplicate, the external counter is incremented again. There is no restore point, so recovery comes down to a full run from scratch.
LangGraph changes the execution model: the scenario is described as a graph of nodes and transitions, and the agent's state becomes an explicit structure that each node reads and appends to.
State is saved after every transition — after a failure, the scenario continues from the last successful node, while branching and cycles are expressed by ordinary graph edges, not nested conditions.
Next, we break down how this is addressed in practice: where state lives, how checkpoints are arranged, and what re-running a step after a failure looks like.
What LangGraph provides: the measurable effect of graph orchestration
Graph orchestration differs from a linear chain in that each step is a separate node with explicit inputs and outputs, and state lives outside the model.
A step failure therefore does not bring down the entire run: the agent returns to the last saved checkpoint and retries only the failed node — recovery takes seconds instead of restarting the scenario from scratch.
This gives the first measurable effect — the share of scenarios completed end-to-end.
Where a single model call was interrupted by an unavailable service or an incomplete response, the graph reaches the final step in 90+% of cases: the failed node is retried, and already collected data is not lost. The fallback branch is described in the same way as the main one.
The second effect is branch reuse.
New logic (input validation, handoff to an operator, a different data source) is added as a node and an edge, not as an edit to the entire scenario: a typical extension is completed in one or two days of engineering work instead of rewriting half the logic and re-debugging.
The third is agent observability, which removes the main support pain: "the answer is wrong, and it's unclear where." Every transition between nodes is logged, you can see at which step context was lost, how long the call took, and where the fallback path triggered. An incident is investigated using the run log, not by blind reproduction.
Technically, this is provided by LangGraph — state checkpoints, step retry, and branching are built in, with no need to build them around model calls.
Graph execution modes: comparison of approaches
The execution mode determines where the decision about the next step is made — inside a single model call, in a rigid scenario, or in a graph node. This affects answer reproducibility and how quickly a failure is localized. Below are four options chosen at the start.
| Orchestration option | When it fits | What limits it |
|---|---|---|
| One large model call | Short scenario without branching: parse the request and return a structured response | No intermediate control — an error in the middle of reasoning is visible only at the end |
| Rigid chain of steps | The regulation is known in advance and changes rarely | Deviation from the scenario breaks the whole chain, and branching has to be written as conditions in code |
| Graph with shared state | Multi-turn tasks: data collection, validation, return to a previous step | Requires discipline in state description, otherwise the graph reads worse than a linear scenario |
| External task dispatcher | Long processes and parallel branches that survive restart | Adds an infrastructure layer that must be maintained and synchronized with logic |
The key difference of a graph is that state lives between steps: a node receives accumulated context, not just the last message. This allows returning the task to a previous step if validation fails, without retelling the entire history to the model.
This is how LangGraph is designed: routing between nodes is described explicitly, not inferred by the model on the fly.
Pure options are less common than a hybrid: the dispatcher holds the queue and retries, while the graph makes the decision about the next step. We lock down the scheme before development — it immediately shows where agent logic ends and infrastructure begins.
Stages of implementing LangGraph in a running service
Implementing a graph does not mean rewriting the service: we extend existing logic, leaving working routes as fallback. Each stage ends with an artifact that can be checked before moving to the next one.
- Analysis of current scenarios. Record where the service already makes decisions: branches, calls to external systems, places where a human is required. The output is a process map with explicit inputs, outputs, and failure points.
- Graph schema. Define nodes, transitions, stop conditions, and the state carried between steps. We agree on the schema before code — it immediately shows cycles, dead ends, and scenarios where the agent may loop.
- Logic migration. Existing checks, limits, and service calls become graph nodes; validation rules are preserved. The old route remains working so the switchover is reversible.
- Agent validation on real data. Run historical requests with a known outcome and calculate the share of correct decisions. Discrepancies are analyzed step by step: you can see exactly which node or transition produced the error.
- Load run. Observe behavior on a flow close to production: response time, retries, spend on expensive calls. Here we also configure limiters and rollback rules to previous logic.
- Handover to operations. We hand over the graph schema, configuration, run logs, and instructions for editing nodes. Separately, we describe what is visible in monitoring and by what signs the team understands that the agent has deviated from expected behavior.
This order gives a predictable transition: first logic, then validation on real data, and only then load and operations.
What we hand over: graphs, policies, documentation
A project is considered delivered not when the agent answers on a prepared example, but when your team can change the behavior of an individual step itself without re-parsing the code. Therefore, the handover includes a set of artifacts: from the graph map to the release policy. Below is what exactly remains with the client after LangGraph integration.
- Graph description and state map — schema of nodes, transitions, and branching conditions, with notes on what data accumulates during execution and at which step the agent stops.
- Node contracts — input and output formats of each step, required fields, behavior on an empty or invalid model response, timeouts, and number of retries.
- Rules for access to external systems — which accounts are needed, where keys are stored and how they are rotated, what the agent only reads and where it is allowed to write.
- Release policy for changes — how editing node logic or model instructions passes validation on a scenario set and gets into the working version.
- Monitoring and incident analysis — which events are recorded, how to distinguish an external service failure from a routing error, and how to revert the graph to a previous version.
- Agent documentation for support — instructions in plain language: what to do on a typical failure, where to look first, where the team responsibility boundaries are.
- Set of validation scenarios — tasks with expected outcomes, used to run the build after every edit.
Case: request processing agent stopped failing
The client — a service company with several thousand requests per week — had an agent on LangGraph processing incoming requests: extracting details from email, checking them against the client database, preparing a response, and passing data to the accounting system. It wasn't answer quality that broke, but scenario resilience.
An agent step failure — an unavailable external service, a connection drop, an unexpected field format — brought down the entire run. The request hung in an undefined state, an operator handled it manually, and scenario recovery after a failure took hours. The share of requests completed end-to-end without intervention stayed around 60%.
We moved processing to an explicit state graph: each step got a checkpoint, a limited number of retries, and a marker for unrecoverable failure.
A node error no longer rolls back the entire run — the agent returns to the last saved state and continues from the same place or hands the request to an operator along with the already collected context.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Requests completed without operator | ~60% | 94% |
| Scenario recovery after step failure | manually, hours | automatically, seconds |
| Manual rework of processing logic | every week | once a quarter |
The side effect turned out no less important: when some failures are closed by retry and some by correct handoff to an operator with context, engineers fix the cause rather than the symptom.
The volume of manual logic rework falls for the same reason — new branches are added to the graph without breaking what already works.
LangGraph or a custom function-based orchestrator?
Short answer: while the scenario is linear, your own orchestrator made of ordinary functions is cheaper both in development and support. A graph library like LangGraph pays off where branching, cycles, and resuming execution from the middle appear.
A custom dispatcher is a chain of calls where state sits in one dictionary and is passed from step to step. Two to four steps, one external service, simple error handling: such code reads end-to-end and doesn't require the team to know someone else's execution model. Support cost here is close to zero — changing the order of steps doesn't break anything around it.
The custom solution starts to lose when forks based on step result, parallel branches, a clarification loop, and a pause until user response appear.
Then you have to implement traversal yourself, store state checkpoints, retry failed steps without duplicates, and limit the number of iterations. This is already a small engine — with its tests, debugging, and documentation for new developers.
The selection criterion is simple: if the schema fits on one page, there are few states, and no returns back — use functions.
If there are cycles, forks, long tasks with waiting for an external event or operator involvement — the graph provides resilience that otherwise has to be written by hand.
Support cost diverges over the horizon: custom is cheaper at the start and more expensive with every new requirement, graph schema — vice versa. The transition doesn't rewrite logic: nodes remain ordinary functions, only the routing layer between them changes.
Technical doubts before starting integration
Engineers who will lead the integration are rarely interested in general benefit — they ask what will happen to the already working agent.
Below are five questions that come up before starting migration to LangGraph, and our answers to them — so the scope of work is clear in advance.
Will the current agent logic have to be rewritten?
No. Model calls, database and external service calls remain the same — the connection between steps changes: instead of a rigid chain, nodes and explicit transitions appear.
What happens to state during transition between steps?
State is a shared object that each step receives and appends to. At any moment you can see what the agent knew and what it relied on at decision time.
Can an interrupted run be continued instead of starting over?
Yes. Checkpoints are saved after each node, so repeated runs don't re-execute completed steps and don't duplicate calls to external services.
How to add a new branch without breaking the live system?
A new node is placed next to the old ones, and the previous route remains working. The branch is enabled by a flag on part of the requests, and rollback is switching back.
How to analyze why the agent made this particular decision?
Step-by-step log: which node was called, what entered state and what came out. The discrepancy is visible at a specific step, not in the general log — analysis stops being guesswork.
If a doubt remains on a specific point — we'll break it down on your agent's schema.Let's discuss the task: how to start graph integration
To come back with an estimate and plan, rather than general considerations, we need source data on your scenario. You can send it in free form — tracker notes and a napkin diagram will work better than polished documentation.
- Current scenario: who does what now, where branching is, at what moment a human is involved.
- Volume: how many runs per day, length of a typical dialogue or document package, whether there are load peaks.
- Constraints: what cannot be moved outside the perimeter, what to anonymize, what response latency is acceptable.
- Integration points: where the graph gets the launch from and where it returns the result — interface, database, ticketing system, CRM.
- What has already been tried: nodes, model calls, results — what didn't satisfy in quality or stability.
- Acceptance criterion: what we consider success in numbers — share of requests closed without a human, manual rework, response time.
This is enough to break the scenario into a graph: define state, branches, checkpoints and rollbacks, show where LangGraph nodes replace scattered model calls, and how to measure the effect at the first stage.
Describe the task as it is — we'll come back with an estimate and plan: scope of work, sequence of stages, what we do at the first step and at what point you accept the result.
