Orchestration
Building with LangGraph
Where an explicit state graph earns its complexity in agent orchestration, and where a plain loop is the better engineering call.
- LangChain
- Orchestration
When should you use LangGraph?
LangGraph models an agent as an explicit state graph — nodes that do work, edges that decide what happens next, and durable state between them. That structure pays off when a workflow has real branching, needs to pause for human approval and resume later, or has to be inspected step by step when something goes wrong. For a single-step tool-calling loop it is overhead, and we say so rather than adopting it by default.
Use it when
- The workflow branches on intermediate results rather than running a fixed sequence.
- A step needs to pause for human approval and resume later with state intact.
- You need per-node visibility into where a run failed, not just an end-to-end error.
- Multiple specialised agents hand work to each other and the handoffs need to be explicit.
Reach for something else when
- A single-step tool-calling loop, where a plain function with retry logic is clearer.
- A fixed linear sequence with no branching and no pause requirement.
- Your team has no capacity to learn a new orchestration concept before handover.
From our own builds
What we have learned running it
We use LangGraph on most multi-step agent builds and deliberately keep the graph thin — nodes call ordinary functions that hold the business logic, so the orchestration layer stays replaceable. The capability that has mattered most in practice is durable state across a pause, because human approval steps are a requirement in almost every enterprise agent and implementing them without persistence is awkward. The mistake we have made ourselves and now avoid is pushing logic into the graph definition, which makes both testing and migration harder than they need to be.
What the graph model actually buys you
The pitch for an explicit state graph is usually framed as capability. In practice the return is debuggability.
When a linear agent loop fails, you get an error and a transcript, and you reconstruct what happened. When a graph fails, you know which node it stopped at, what state was in scope, and what the last decision was. On a workflow with eight steps and three branches, that difference is the majority of your debugging time.
The second real benefit is durable state across a pause. Almost every enterprise agent needs a human approval somewhere, and an approval can take hours. Persisting state properly so the run resumes rather than restarts is genuinely fiddly to build yourself.
When we tell clients not to use it
If the workflow is one model call, one tool call and a response, a framework is a dependency and a concept your team has to learn for no return. A plain function with a retry and structured logging is clearer and easier to hand over.
We mention this because “which framework” is a common first question and it is rarely the question that determines the outcome. Tool contract design, schema validation and the evaluation suite decide whether the agent works. The orchestration layer decides how quickly you find out why it did not.
Keep the graph thin
Our consistent practice, learned from getting it wrong: business logic lives in ordinary functions and the graph only routes between them.
That keeps the logic unit-testable without spinning up a graph, keeps your engineers working in code they already understand, and means that if you later move to a different orchestrator you rewrite the routing rather than the system.
Frequently asked questions
When is LangGraph the right choice?
When would you not use it?
Does the framework make agents more reliable?
Are we locked in if we build on it?
Where we use this
- AI agent developmentAutonomous agents that execute a business process end to end, with the guardrails and evaluation infrastructure that keep them trustworthy at volume.
- Evaluation & observabilityEvaluation suites, regression gates and production tracing that turn AI quality from an opinion into a number you can defend.
- RAG developmentRetrieval systems that answer over your own data with a citation for every claim, and a retrieval score you can actually measure.
Next Step
Tell us what you are trying to automate
A 30-minute technical call with an engineer who has shipped this before — not a sales qualification round. You leave with a feasibility read, a rough shape for the build, and an honest answer about whether it is worth doing at all.