Graphs and loops

Two ways to build an agent, and the single question that separates them.

Graph

The path exists before the run starts.

collect normalize enrich flag store your branch

Loop

The path is whatever just happened.

thinks calls a tool reads result context when it stops done

The question is who decides what happens next, and when. Everything else follows from that.

What you are actually choosing

A graph is a map you draw in advance. You name the steps, wire the edges, and decide which conditions send a run down which branch. At run time the system walks a path you already approved. If reality produces a case you never drew, there is no path for it.

A loop hands the decision over. You give the model a goal, a set of tools, and a stop rule, then let it choose its own next move after seeing each result. It will handle cases you never imagined, and it will also spend twenty turns on something you could have wired in ten minutes.

Neither is more advanced than the other. They trade the same thing in opposite directions: the graph buys certainty with rigidity, the loop buys range with variance.

The shape in code

Graph

graph.node("collect", fetch_sources)
graph.node("normalize", clean)
graph.node("enrich", add_context)
graph.node("store", write_rows)

graph.edge("collect", "normalize")
graph.edge("normalize", "enrich", when=is_new)
graph.edge("normalize", "flag", when=is_dupe)
graph.edge("enrich", "store")

graph.run(state)

Loop

messages = [goal]

while True:
    reply = model(messages, tools=toolbox)
    messages.append(reply)

    if reply.finished or turns > 30:
        break

    for call in reply.tool_calls:
        messages.append(run_tool(call))

Side by side

Graph
Loop
Who picks the next step
You, while building
The model, mid-run
What you build
State schema, nodes, edges, retries
Tools, context, stop rules, sandbox
Where the hard work is
Modeling every path worth taking
Writing tools whose errors teach the model how to recover
How it fails
No path for the case in front of it
Wanders, burns turns, stops short of done
Cost and latency
Bounded, you can quote a number
Varies per run, needs a ceiling you enforce
Debugging
Replay the run, inspect state at each node
Read the transcript, fix a tool or the prompt
Best when
Steps are known and the result must be provable
Steps cannot be known until the work is underway

Which one fits

  • Can you list every step before the run begins?Graph
  • Does someone need to audit why it did what it did?Graph
  • Do you need a hard cost ceiling per run?Graph
  • Is the next step obvious only after seeing the last result?Loop
  • Would each new edge case mean shipping another branch?Loop
  • Is the output judgment rather than a record?Loop

Most real systems are both

collect normalize strategist loops until done publish

The useful pattern is a graph for the spine you need to guarantee, with a loop living inside the one or two nodes where the work is genuinely open ended. Collection and storage should not be improvised. Judgment cannot be wired.

You already own one of each. An orchestrator like n8n is a graph: you drew the nodes and the edges hold. A coding agent is a loop: it reads, runs, reads again, and nobody specified that path in advance. Choosing between them is not a tooling question. It is a question about which steps you are willing to leave undecided.

One spine you can prove. One loop where the thinking happens.

TEST STRING: edited from Claude Code on 2026-09-13 to check update_document.