Once you have built one agent loop, the temptation is to build a bigger loop. Add more tools. Add more memory. Add more responsibilities to the same loop until the same loop is doing research, writing, deploying, and reviewing its own output.
That works for a while. Then the loop starts doing things you didn't expect, and debugging it becomes archaeology.
The reason is that loops and graphs are different things, and they break differently.
What a Loop Is Good For
A loop is a thing that runs the same shape repeatedly until something stops it. Inside a loop:
- The model gets to decide what to do next.
- The context keeps growing as the loop runs.
- Termination is implicit ("budget exhausted" or "model said done").
Loops are the right shape when:
- The next action depends on the previous result.
- The order of operations isn't fixed in advance.
- The work is exploratory and the model is good at choosing.
A research agent reading papers, a coding agent iterating on a fix, a chat assistant answering questions — all loops.
What a Graph Is Good For
A graph is a thing whose nodes and edges have been decided in advance. Inside a graph:
- The routing between nodes is fixed (or constrained).
- Each node has a clear contract: what it takes, what it returns.
- Termination is explicit: the graph ends when the terminal node runs.
Graphs are the right shape when:
- The order of operations matters and is known up front.
- You want each step to be auditable independently.
- You want guarantees — "this step always runs after that step."
- Multiple agents or services need to be coordinated.
A publishing pipeline that goes research → draft → review → publish, an approval workflow, a multi-agent research chain — all graphs.
The Failure Modes Differ
A failing loop looks like:
- Context bloats until the model loses the thread.
- Budget burns on tangential work.
- The loop stops for the wrong reason (or doesn't stop at all).
- Debugging means reading the whole transcript to find the bad step.
A failing graph looks like:
- A node's contract is violated by an upstream change.
- An edge routes to a node that no longer exists.
- The graph can't be re-entered safely (state leaks between runs).
- Debugging means inspecting the trace at the failing node.
Loops fail in narrative ways; graphs fail in structural ways. The fix for each is different.
When to Graduate from Loop to Graph
Three signals that you have outgrown a pure loop:
1. You find yourself writing the same prompt-injection every iteration ("make sure you do X before Y"). That logic wants to live in an edge, not a prompt. 2. Different parts of the loop want different models or different toolsets. A single loop is the wrong shape when one agent is trying to be three specialists. 3. You want to test or replay part of the work without running the whole thing. A graph lets you replay a single node; a loop doesn't.
When any of those three things is true, it is time to lift some of the work out of the loop and into a graph. You don't have to replace the loop — most long-running systems are a graph of loops, not one or the other.
Hybrid Shapes
The interesting long-running systems are not pure loops and not pure graphs. They are a graph where some of the nodes are loops:
- A cron tick kicks off a graph.
- The graph routes to a research node, which is a loop that reads
until it has enough material.
- The graph routes to a writing node, which is a loop that drafts and
self-reviews.
- The graph routes to a publish node, which is a single, non-loop
step.
- The graph terminates.
The graph is for routing and auditability. The loops are for the parts where the model genuinely should be deciding what to do next. Picking which is which is the entire job of designing a long-running system.
How to Tell Which You Are Building
A quick test: if you can write down the steps before the run starts, you are building a graph. If you cannot — if the model has to discover the steps — you are building a loop.
Most agent work is some of each. The mistake is pretending one of them is the other.