Graph vs Loop: Which Should Your Agent Use?

The default is a loop. Escalate to a graph only when specific signals show up - because a single agent running discover, plan, execute, verify on repeat handles more than most builders expect, and it is far cheaper to build and debug than a multi-node graph. If you are mid-decision on whether your next agent needs a "graph," this page is the honest answer: probably not yet, and here is exactly how to tell.

The term "graph engineering" landed on X in mid-July 2026 and the timeline immediately split into two camps - one declaring loops dead, one calling the whole thing slop. Both are overreacting. The useful version is boring: a loop is one node, a graph is several, and your job is to figure out how many nodes your problem actually has. Usually one.

Should You Start With a Loop?

A loop is one agent running the same cycle until a condition is met:

discover → plan → execute → verify → (repeat until done)

That is the whole shape, and it is genuinely enough for most agent work. If we walked through everything you might build this quarter, the majority is a single well-scoped task with a checkable definition of done: fix the failing tests, draft and self-review a page, triage an inbox, research one question and write it up. All of those are loops. None of them need a graph.

We wrote the full playbook for this in Loop Engineering, and the one line worth carrying into this decision is: in any loop, the verifier is the bottleneck, not the model. The model generates cheaply, over and over; the thing that decides whether all that motion produced value is the check you wrote. Get the verifier right and a single loop ships a surprising amount.

So the default is not "start simple and feel bad about it." The default is a loop because a loop is the right tool for a single-specialty task, and reaching past it costs you real money and real debugging time. The rest of this guide is about the narrow set of cases where reaching past it actually pays.

Remember the relationship, because it defuses the whole debate: a loop is a graph with one node and an edge back to itself. You are never choosing between two philosophies. You are choosing how many nodes your problem needs.

How Do You Know You've Outgrown the Loop?

You have outgrown a single loop when the problem stops being one job. Here are the five signals that actually justify wiring a graph - specialized nodes (agents or steps) connected by edges (the routing between them), with shared state flowing along those edges. If none of these are true, stay in the loop.

Signal 5 is the one to watch most closely, and it is where the loop-to-graph line is genuinely useful rather than fashionable. When a single verifier is overloaded, the fix is not a longer prompt - it is a separate node whose only job is that one check. That move, a dedicated reviewer node with its own edge, is the smallest honest graph there is. @rohit4verse captured the general version on X with the org-chart metaphor: agents graduating from while-loops toward something closer to an org chart, with specialized nodes working in parallel and state flowing between them. An org chart is the right image: you add a node when you would hire a specialist, not before.

One node per signal you actually have. If you have one signal, you probably need one extra node - not a sprawling mesh.

What Does a Graph You Didn't Need Cost You?

Here is where the skeptics are right, and pretending otherwise gets builders hurt. A graph is not free sophistication. Every node is another thing to design, another place the run can fail, another output to verify, and every edge is coordination latency a single loop would have spent inside one context. @PawelHuryn put the backlash bluntly on X: "I call BS on graph engineering. Loop engineering was already confusing." That reaction is not just noise - a graph you didn't need is exactly the confusion he is pointing at.

The steel-man of the skeptic case is not "graphs are bad." It is "most people reaching for a graph have a loop-shaped problem and a verifier they never bothered to strengthen." That is correct, and it is the trap this whole guide exists to keep you out of. A graph earns its complexity when the problem is genuinely multi-specialty or genuinely parallel. Absent that, the complexity is a tax with no return, and the honest move is to write a better verifier and stay in the loop.

The tell that you fell into the trap: you can't point at which of the five signals forced each node. If every node traces back to a real signal, keep it. If a node exists because the diagram looked more serious with it, delete it.

Graph or Loop: How Do You Decide in 30 Seconds?

When you are mid-decision, run the problem down this tree. It is deliberately biased toward the loop, because the loop is the cheaper mistake.

                        ┌─────────────────────────────┐
                        │  New agent task in hand      │
                        └──────────────┬──────────────┘
                                       │
                    Does it decompose into DISTINCT
                    specialties (research / write /
                    review) that each want their own
                    context and tools?
                                       │
                 ┌──────── no ─────────┴───────── yes ────────┐
                 │                                            │
     Do you need TRUE parallelism                    Wire a GRAPH:
     (fan out N items, then join)?                   one node per
                 │                                   specialty, edges
        ┌── no ──┴── yes ──┐                         for the routing,
        │                  │                         shared state on
   Different model         │                         the edges
   or tool needed          │
   per step, OR need       └──────────────► GRAPH (fan-out → join)
   AUDITABLE branching?
        │
   ┌─ no ┴ yes ─┐
   │            │
   │            └──────────────────────────► GRAPH (routing / branches)
   │
   Is one verifier failing because
   it's judging too many things?
        │
   ┌─ no ┴ yes ─┐
   │            │
   │            └──► Split the verifier into its own
   │                 node → smallest honest GRAPH
   │
   └──► STAY IN THE LOOP.  Strengthen the verifier,
        pin the stop condition, ship it.

Most real tasks fall out the bottom-left exit: stay in the loop. That is the intended result, not a failure of the flow.

Do You Need a Framework for This?

You do not need a new framework to make this call, because the frameworks already express both ends of it. LangGraph describes itself as a low-level orchestration framework and runtime for long-running, stateful agents - you assemble nodes and edges into a state graph, so a single node looping on itself is a loop and adding specialized nodes with routing makes it a graph, in the same codebase. Google ADK ships template workflow agents (sequential, parallel, and loop) plus agent routing and multi-agent workflows, which is the same loop-to-graph spectrum exposed as building blocks. The framework gives you the vocabulary for both; it does not make the decision. Your problem's signals do. If you are wondering whether "graph engineering" is just LangGraph with a new name, we take that question apart in Is Graph Engineering Just LangGraph? - the short version is that the frameworks are prior art and the term is a framing, not an invention.

What's on Your Loop-or-Graph Checklist?

Before you wire a single edge, run the decision through this:

1. Default to a loop. Assume one node until a signal forces a second.
2. Name the signal out loud. Distinct specialties, parallel fan-out, per-step model/tool, auditable branching, or an overloaded verifier - if you can't name which one, you don't have a graph yet.
3. One node per real specialty. Not one node per step you could imagine splitting.
4. Fix the verifier before adding nodes. Half the "I need a graph" cases are a weak verifier in disguise (Loop Engineering covers how to write a strong one).
5. Price the coordination. Every edge is latency and every node is a failure point - make sure the parallelism or specialization buys back more than it costs.
6. Keep it collapsible. If you can delete a node and the result is the same, delete it.

Do that and you'll build the graph your problem needs and not one node more - which is the only version of "graph engineering" the skeptics can't dunk on.

Related Content

• Graph Engineering: The Complete Guide - The pillar: what graph engineering is, where it sits in the stack, and what's genuinely new versus a rebrand of prior art.
• Graph Engineering vs Loop Engineering - The conceptual boundary between the two layers, deeper than this decision guide goes.
• Loop Engineering: Stop Writing Prompts, Start Writing Verifiers - The default architecture and why the verifier is the bottleneck. Read this first.
• Is Graph Engineering Just LangGraph? - Whether the term is a new discipline or a framework wearing a new hat.
• Dynamic Workflows: Orchestrate Subagents at Scale - When the fan-out gets wide, push the graph into a script instead of babysitting it.

Start Here

Graph engineering is the layer above loop engineering, so the honest advice is: nail the loop before you wire the graph. Take one task you were about to over-engineer, cut it back to a single loop with a strong verifier, and only add a node when a signal from the list above actually forces your hand.

Want the foundation the graph sits on? The Loop Engineering course takes you from "you are the for loop" to a loop that runs on schedule, ships behind quality gates, and reports back - the skill you need solid before any of this graph work pays off.

Bring the task you're about to over-build. Inside the AI Builder Club we run it through the loop-or-graph worksheet together, count the signals honestly, and settle on the smallest architecture that ships - then you go build it.

Join AI Builder Club