Once you have built one agent loop, the temptation is to make it bigger. Add more tools, more memory, and more responsibilities to the same loop until one loop is doing research, writing, deploying, and reviewing its own output.

That can work for a while. Then the loop starts doing things you did not expect, and debugging it becomes archaeology.

The reason is simple: loops and graphs are different things, and they break differently.

What a Loop Is Good For

A loop is a process that repeats the same shape until something stops it. Inside a loop:

  • The model gets to decide what to do next.
  • Context keeps growing as the loop runs.
  • Termination is often implicit, such as budget exhaustion or a completion signal.

Loops are the right shape when:

  • The next action depends on the previous result.
  • The order of operations is not fixed in advance.
  • The work is exploratory and the model is good at choosing the next step.

A research agent reading papers, a coding agent iterating on a fix, and a chat assistant answering a question are all loop-shaped systems.

What a Graph Is Good For

A graph is a system whose nodes and edges are decided in advance. Inside a graph:

  • Routing between nodes is fixed or constrained.
  • Each node has a clear contract: what it takes and 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 ahead of time.
  • Each step needs to be auditable independently.
  • You want guarantees, such as a specific step always running after another.
  • Multiple agents or services need to be coordinated.

A publishing pipeline that goes research to draft to review to publish, an approval workflow, and a multi-agent research chain are all graph-shaped systems.

How they fail differently

A failing loop often looks like this:

  • Context bloats until the model loses the thread.
  • Budget burns on tangential work.
  • The loop stops for the wrong reason, or does not stop at all.
  • Debugging means reading the whole transcript to find the bad step.

A failing graph often looks like this:

  • A node contract is violated by an upstream change.
  • An edge routes to a node that no longer exists.
  • The graph cannot be re-entered safely because 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 usually mean a pure loop has outgrown itself:

1. You find yourself repeating the same instruction every iteration, such as “make sure you do X before Y.” That logic belongs in an edge, not in the prompt. 2. Different parts of the work want different models or different toolsets. A single loop is the wrong shape when one agent is trying to act like three specialists. 3. You want to test or replay one part of the work without running the whole thing. A graph lets you replay a single node; a loop usually does not.

When any of those is true, it is time to move some of the work out of the loop and into a graph. You do not have to replace the loop; most long-running systems are a graph of loops, not one or the other.

Hybrid shapes

The most interesting long-running systems are not pure loops and not pure graphs. They are graphs 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 decide what to do next. Picking which is which is the real job of designing a long-running system.

How to Tell Which You Are Building

A useful test is this: if you can write down the steps before the run starts, you are building a graph. If you cannot, and the model has to discover the steps, you are building a loop.

Most agent work is some of each. The mistake is pretending one is the other.

Why this matters

This distinction saves time, reduces debugging pain, and makes systems easier to extend. It also helps you assign responsibility correctly: loops are for adaptive progress, graphs are for controlled orchestration.

If a system feels messy, the problem is often not that it needs “more AI.” It usually needs a better shape.

Common questions

Is a graph always better than a loop?

No. A graph is better when the path is known and needs control. A loop is better when the next step must be discovered along the way.

Can a loop contain a graph?

Yes. A loop can call a graph repeatedly, and a graph can contain loop-shaped nodes. In practice, many serious systems are hybrids.

Why not just keep adding instructions to the loop?

Because instructions are weak where structure is better. Once the behavior becomes repetitive, auditable, or role-based, the system usually needs routing, not more prompt text.

Takeaway

Use a loop when the agent needs to decide the next step. Use a graph when the steps and routing are known ahead of time. Most serious systems begin as loops and become graphs when the work gets repetitive, auditable, or multi-role.