FIELD NOTE 003 · · 8 min read
From Agent Loops to State Graphs: How LangGraph Won the Bet
The agent conversation is circling back to workflows. A loop that plans, calls tools, reads results, and tries again is useful. It is not the full application.
LangGraph made that case in early 2024. It treated the loop as one part of a system with named stages, explicit state, and controlled transitions.
That distinction matters once an agent needs to work with retrieval, rules, approvals, storage, and other services. The work is no longer just inside the loop. It is the workflow around it.
A loop can live inside a graph
LangGraph does not replace an agent loop. It can make the loop a node in a larger graph.

One node may run an agent until it reaches an answer. The next node may check policy with ordinary Python. A later node may ask a person to approve a response. The graph decides what runs next and what state each step receives.
This gives the loop a boundary. It can reason and use tools where that helps, while rules, routing, and approvals stay visible in code.
LangGraph is built around three simple pieces: shared state, nodes, and edges. Nodes do work. Edges choose the next node. State carries the information the workflow needs between them.
An edge may be fixed or conditional. Independent nodes can run in parallel. A graph can also return to a prior node when the task needs another pass.
Context is state, not a growing transcript
Context is more than the prompt sent to a model. It includes retrieved documents, tool results, preferences, earlier decisions, pending approvals, and summaries.

Each of those has a different lifetime. A search result might matter for one turn. A user preference may need to survive across many runs. An approval may stop execution until someone responds.
A state graph makes those choices part of the application. You define the data it holds and how updates are merged. Messages, retrieved evidence, and durable user data can stay separate instead of becoming one large prompt.
That is the practical side of context engineering. It is deciding what the system remembers, what it passes forward, and what it discards.
Anything can be a node
LangGraph does not require an LLM. It does not require an agent. A node is a unit of work that reads state and returns an update.

One node can call OpenAI’s Responses API. Another can use Claude, a LangChain component, or a Pydantic validator. Another can run PyTorch, scikit-learn, a database query, or ordinary Python.
This is the useful meaning of a framework inside a framework. LangGraph supplies the stateful workflow. Each node can use the tool or library that fits its job.
You do not need to rewrite working components just to adopt explicit routing and state. The graph coordinates different kinds of computation without making them all look like agents.
What the runtime gives you
You can write a state machine, persistence layer, retry strategy, and approval flow yourself. Many teams do. LangGraph packages the common parts so they do not have to be rebuilt before the product is understood.

- Persistence and durable execution. Checkpointers save state so a run can resume after a failure or interruption.
- Human review.
interrupt()can pause execution and continue when external input arrives. - Memory. Thread-scoped checkpoints and cross-thread stores support different kinds of context.
- Streaming. A product can show work in progress instead of waiting for one final response.
- Routing and parallelism. Conditional edges and parallel branches express the workflow directly.
Those features do not remove the hard choices. You still need a useful state schema, safe handling for side effects, and a clear rule for when people should intervene.
They do put those choices in the system, where they can be reviewed and changed.
Evaluation follows the workflow
Final answers are a poor place to start debugging. A bad answer may come from weak retrieval, the wrong route, an invalid tool call, a poor model response, or a state update that carried the wrong context forward.

| Part of the workflow | Question to ask |
|---|---|
| Retrieval | Did it find relevant and trustworthy evidence? |
| Routing | Did it choose the right next step? |
| Tool call | Did it select the right tool and valid arguments? |
| Generation | Was the response grounded and useful? |
| Validation | Did the rule catch invalid output? |
| State update | Did it retain, merge, or discard the right context? |
Graphs give these checks a place to attach. A team can evaluate a retrieval step, a router, or a tool call without pretending that one score for the final answer explains the whole system.
The bet LangGraph made
Agent loops are still useful. They belong where a model needs to interpret a request, decide how to use tools, or combine results.

Other parts of the application need different treatment. Rules should be code. State should be explicit. Transitions should be visible. Human review should be a real step, not a prompt instruction.
That was LangGraph’s bet in 2024. The industry is now arriving at the same point: the useful unit is not only the agent. It is the workflow that lets an agent, code, tools, and people work together.
Sources
NORMAL · BALANCE 0