Control Flow Is Not the Main Problem: A Note on LangGraph
Open-ended agents and deterministic business workflows live in different places. Don't conflate them.
LangGraph is, in my view, one of the most technically sophisticated open-source agent frameworks available.
If you want explicit graphs, stateful nodes, conditional routing, and replayable execution topology, LangGraph is one of the strongest open tools in the market.
This post is not about whether LangGraph is good engineering.
It is.
The real question is narrower and more useful:
When is explicit control flow the right place to invest engineering effort, and when is it the wrong level entirely?
Two Different Kinds of Problems
There are really two different architecture problems hiding under the word “agent.”
Problem 1: open-ended agent reasoning
The path emerges as the model works:
search
inspect a document
decide it needs another capability
run a tool
adjust
continue
For that kind of workload, over-optimizing the graph topology is often the wrong bet. The reasoning path is part of the problem itself. (That kernel is the argument in Agent Reasoning Is Just a While Loop — the loop is trivial; the intelligence is everything around it.)
Problem 2: business process control
The system needs:
typed state
explicit transitions
guards
retries
human tasks
auditable routing
For that kind of workload, deterministic control absolutely matters. But it should usually live in a process engine, not inside an unconstrained LLM graph.
The two problems share a word. They do not share an architecture.
Where LangGraph Excels
LangGraph is excellent when you really do need explicit graph control.
Custom topologies
If your workload is best expressed as nodes and edges with explicit transitions, LangGraph lets you encode that directly.
Replay and debugging
Its checkpointing and replay model is genuinely useful for understanding how the graph moved through state.
Human interruption
The interrupt() model is clean and thoughtfully integrated.
Ecosystem access
The LangChain ecosystem remains one of the broadest pools of Python-native integrations in the space.
If your problem maps naturally to a graph, LangGraph is a serious tool.
Where We Make a Different Bet
For open-ended agent work, our bet is not “draw the graph more precisely.”
It is:
let the agent runtime handle the reasoning loop,
invest in the harness around that loop,
and move deterministic business control into a separate process layer when you need it.
That gives you a different division of labor:
agent runtime for open-ended reasoning
process engine for typed, auditable business control
(The runtime side of that split — interactions, skills, tools as the small set of primitives — is the argument in Why Agent Frameworks Have Too Many Nouns.)
The point is not that control flow is unimportant.
It is important enough to put in the right layer.
There are two very different places control can live, and conflating them makes systems worse.
Graph Persistence Is Not the Whole Execution Substrate
One related note, because it comes up a lot in LangGraph comparisons.
LangGraph now uses the language of durable execution for its persistence layer. That is fair within the graph context. Checkpoints, replay, and interrupts are genuinely useful, and the docs describe them precisely.
The distinction I care about is scope.
Saving and replaying graph state is one part of production execution. It is not, by itself, the rest of the runtime: workers dying mid-run, redeploys, provider throttling, capacity collapse, signals, long human wait states, cost controls, and observability across multiple agents and processes at once.
So the point is not whether checkpointing is useful.
It is.
The question is whether graph-level persistence is the top of the stack, or one layer inside a broader production system. I went deeper on what sits above the durable execution substrate in Durable Execution Is The Floor, Not The Building: A Note On Mistral Workflows — for this one, the distinction is the point.
Where Deterministic Control Belongs
This is where the comparison sharpens.
The lazy framing would be: Vertesia lets the LLM control the flow. That is only half true.
For open-ended agents, yes: the model is allowed to drive its own path through tools and capabilities.
But for business workflows, we now use the Process Engine:
the engine owns state, guards, transitions, routing, and validation
agent nodes are worker conversations bounded by a typed
writescontracttransitions are explicit and typed (
auto,agent,user) — agents may choose from declared exits, never invent theman optional AI supervisor can steer a run, but only through a small set of validated commands the engine accepts
That is a better home for deterministic control than stuffing all of it into a general-purpose agent graph. I wrote up the full design separately — the writes contract, the supervisor seat, the Temporal-backed durable substrate, tools as first-class process primitives, MCP capabilities under the same governance — in The Engine Is the Contract: A Process Engine for Agents, From First Principles. This post is the where argument; that essay is the what.
So the more accurate comparison is now:
LangGraph: explicit graph control inside the agent framework itself
Vertesia: open-ended agents for open-ended work, deterministic process control in a dedicated process engine designed from first principles for agents
That is a clearer and more defensible distinction.
What You Build Yourself
Even with the right graph abstraction, the graph is still only a slice of the system. Tool coherence, documents, memory, observability, distribution, long-running execution — LangGraph intentionally leaves most of that to the surrounding stack. Each of those is its own architecture problem. (Two of them are already in the series: The Repository Reads Itself on content, Provider Limits Are an Architecture Problem on capacity.)
That is not a criticism. It is a design boundary. LangGraph gives you the graph; it does not try to be the platform.
The only point here: control flow is one concern, not the top of the stack.
When LangGraph Is the Right Choice
Choose LangGraph when:
explicit topology is core to the problem
graph control is where your team wants to spend engineering effort
replay and graph-level debugging are central to your workflow
you want deep access to the LangChain ecosystem
When Vertesia Is the Better Fit
Choose Vertesia when:
open-ended reasoning matters more than graph authorship
durability, tools, and documents are the harder part of the system
some workflows need a process engine with typed context and human gates
you want a platform where control is split cleanly between agent runtime and deterministic business orchestration
The real mistake is not choosing LangGraph or Vertesia.
The real mistake is trying to solve a business process problem entirely inside an unconstrained agent graph, or trying to solve an open-ended reasoning problem by over-designing the control graph.
Control flow matters.
But where you put that control matters even more.
Next in the series: Google ADK Is Free. The Production Stack Isn’t. — why the real comparison is platform versus platform, not just framework versus framework.