Two years into the agent era, the most consequential architectural decision you will make has almost nothing to do with which model you pick.
It is this: who decides what happens next?
Either the model decides observing the result of its last action, reasoning about it, and choosing the next step on its own. Or you decide, in advance, by declaring the structure: these are the stages, these are the transitions, this is what happens when a step fails.
The first is a loop. The second is a graph. Through 2026 this has hardened into a genuine dispute among people who build agents for a living, with “loop engineering” and “graph engineering” emerging as competing disciplines rather than competing tools.
The dispute is real, but the framing is wrong. Loops and graphs are not rival philosophies. They are answers to different questions, and the interesting engineering happens at the point where you decide which question you are actually asking.
What a Loop Actually Is
The loop is the original framing. Anthropic’s Building Effective AI Agents drew the line that most of the field still uses: workflows are systems where language models and tools are orchestrated through predefined code paths, while agents are systems where models dynamically direct their own processes and tool usage.
Stripped to its mechanics, an agent loop is almost embarrassingly simple. It gathers context, takes an action, observes what happened, and decides whether to go again.
Step four is the entire argument. In a loop, the transition function lives inside the model’s reasoning, not in your code. That is precisely what makes loops powerful: they handle situations you never anticipated, because nobody had to anticipate them. Give a competent model good tools and a clear goal, and it will find paths through a problem that you would not have thought to declare.
It is also, precisely, what makes them hard to operate. You cannot read a loop’s control flow before it runs. There is no diagram. The path exists only after the fact, in a trace.
What a Graph Actually Is
The graph camp starts from the opposite end. Rather than deferring structure, you declare it: typed nodes that do work, edges that define legal transitions, conditional edges that branch on state, and a persisted state object threaded through the whole thing.
This is not a new idea, it is a state machine, and we have been building those for fifty years. What is new is applying it to non-deterministic components. The node may be an unpredictable model call, but the topology around it is fixed and inspectable.
That inspectability is the whole pitch. You can look at a graph before it executes and know every path the system is permitted to take. When something goes wrong at 3am, you can point at the node it happened in. Auditors can review the structure without reading a single trace.
Graphs also bring a property loops struggle with: durable execution. Because the graph has explicit boundaries between steps, state can be checkpointed at each one. Frameworks like LangGraph persist state at every superstep, organised by thread, which is what enables fault recovery, state history, time-travel debugging, and human-in-the-loop approval gates. A crash resumes from the last checkpoint rather than restarting the task and re-executing every tool call along the way.
The Trade That Actually Matters
Almost every comparison of these two architectures gets lost in framework features. The real trade is simpler and harsher.
Read those two cards again, because they explain nearly every failed agent project I have seen.
Teams building in regulated domains reach for loops because loops demo beautifully, then discover eighteen months later that they cannot explain to a regulator why the system did what it did. Teams building open-ended research or coding tools declare elaborate graphs, then discover their users constantly want the one path nobody declared.
Neither team picked the wrong framework. Both answered the wrong question.
Where Loops Break
Loops fail in characteristic, well-documented ways. Research analysing five popular multi-agent frameworks across more than 150 tasks catalogued 14 distinct failure modes, grouped into three families: specification and system design, inter-agent misalignment, and tellingly; task verification and termination.
That third family is the loop’s structural weakness, and it deserves more attention than it gets.
The instinct is to treat these as prompt problems. They are not. They are control-flow problems, and the fix is a control-flow mechanism: an explicit termination condition the model does not own. A test that must pass. A schema that must validate. A budget that hard-stops the loop regardless of what the model believes.
Loop engineering, done properly, is mostly the discipline of deciding how the loop ends.
Where Graphs Break
Graphs have the opposite pathology, and because graph failures are quieter, they get discussed far less.
The dominant one is premature structure. Declaring a graph means committing to a decomposition of the problem before you have run the problem. If your decomposition is wrong and early ones usually are you have hard-coded a misunderstanding into the topology. Every subsequent change means restructuring nodes and edges rather than adjusting a prompt.
The second is path explosion. Real processes have exceptions, and every exception is a conditional edge. Graphs that begin as elegant five-node diagrams accumulate error branches, retry paths, and special cases until the diagram is no longer something a human can hold in their head. At that point you have lost the auditability that justified the graph in the first place you are just maintaining a very large state machine.
The third is subtler: structure that pretends to be understanding. A graph makes a system look rigorous. Nodes and edges convey a precision the underlying model calls do not actually have. A well-drawn diagram wrapping four unreliable model calls is still four unreliable model calls.
The Decision Framework
Strip away framework marketing and the choice comes down to four questions. They are ordered deliberately the first one usually decides it.
| Question | Points to a loop | Points to a graph |
|---|---|---|
| What does failure cost? | A retry, a wasted minute, a bad draft | A regulator, a customer, an irreversible write |
| Is the path knowable in advance? | No- it depends on what is found along the way | Yes- the stages are stable and repeatable |
| How cheap is verification? | Cheap tests run, schemas validate, output compiles | Expensive correctness needs a human or takes days |
| Who has to explain it later? | The engineer who owns it | Compliance, audit, or a court |
The verification question is the one teams skip, and it is the most predictive of the four. A loop is only as good as its exit condition. Where verification is cheap and automatic code that must compile, tests that must pass, data that must satisfy a contract loops are extraordinarily effective, because the loop can check its own work and iterate honestly. Where verification requires human judgment or a slow downstream process, the loop has no reliable way to know it is done, and its greatest strength becomes its greatest liability.
Graphs of Loops
Here is where the debate resolves, and it resolves in a way neither camp likes to state plainly: a loop is a node in a graph.
Production systems converge on this. Not because it is a clever compromise, but because the two architectures answer questions at different altitudes. The graph answers what stages exist and what must be true between them. The loop answers how this particular stage gets done.
The structure carries what must be auditable: the stages, the boundaries, the checkpoints, the approval gate. The loops carry what must be adaptive: the messy, open-ended work of actually investigating or drafting something.
Critically, this is not “use both and hope.” It is a specific claim about where the boundaries go. Boundaries belong wherever you need one of three things: a durable checkpoint you can resume from, an artifact you can inspect, or a human who must approve before the system continues. Everywhere else, a boundary is just overhead.
The practical consequence is that graph nodes should be drawn around commitments, not around tasks. A node is not “the agent researches the topic.” A node is “research is complete and the findings are persisted” a state you can checkpoint, resume from, and show someone.
What Data Engineering Already Solved
The part of this discourse I find most striking is how much of it is rediscovery.
Data engineering spent fifteen years learning to run unreliable steps over unreliable infrastructure. It produced a well-understood body of practice: idempotent operations so retries are safe, checkpointing so failures resume rather than restart, lineage so you can trace an output back to its inputs, and backfills so you can recover from a bad run without redoing everything.
Agent frameworks are now converging on exactly these ideas under the banner of durable execution persist completed execution boundaries, then recover after crashes without repeating tool calls, external mutations, human approvals, or outbound messages. That last clause is a hard-won lesson: replaying a step that already sent an email is worse than not recovering at all.
The observability layer is maturing along the same lines. OpenTelemetry’s GenAI semantic conventions have reached stable status, and teams with proper agent tracing report substantially faster incident resolution than those debugging from logs. This matters more for loops than graphs a graph is partly self-documenting, while a loop’s control flow exists only in its trace. If you choose loops, tracing is not optional tooling. It is the only record of what your system did.
How to Actually Decide
The advice converging across production teams is consistent, and it runs against the instinct of most engineers: start simpler than you think you need, instrument heavily, and add structure only in response to failures you have actually observed.
A single well-instrumented loop will tell you where it needs boundaries. It will show you the stage that always fails, the point where a human should have approved something, the place where work is lost on a crash. Those observed failures are your graph discovered rather than guessed.
The reverse rarely works. Teams that begin with an elaborate graph have committed to a decomposition before they have evidence for it, and the cost of being wrong is structural rather than incremental.
So: begin with a loop, and give it a real exit condition a check the model does not control. Instrument it completely, because that trace is your only visibility. Then wait for it to fail, and read the failures carefully. When you find work that must survive a crash, draw a checkpoint. When you find a decision a human must own, draw an approval gate. When you find an artifact someone needs to inspect, draw a boundary around it.
Do that consistently and you will not have chosen between loops and graphs. You will have earned a graph, one node at a time, with each node justified by a failure you actually saw which is the only kind of architecture that survives contact with production.
The Honest Summary
Loop engineering and graph engineering are not competing schools. They are two halves of one skill: knowing which decisions to hand the model and which to keep in your code.
Hand the model the decisions where the space is too large to enumerate and where checking the answer is cheap. Keep in your code the decisions where failure is expensive, where someone will ask you to explain what happened, or where the system must survive being interrupted.
Get that division right and the framework question mostly answers itself. Get it wrong, and no framework will save you.
References:
- Building Effective AI Agents Anthropic’s workflow-versus-agent distinction
- LangGraph stateful graphs, checkpointing, and durable execution
- OpenTelemetry GenAI semantic conventions the emerging standard for agent tracing
About the Author
Aqil Khan is an Agentic AI Engineer and Data Governance & Analytics Consultant specializing in building data pipelines and autonomous AI systems. He writes about the frontier of AI coding assistants, agentic workflows, and intelligent data systems at Towards Agentic AI.