Graphs vs Looping: When Your AI Agent Needs a Map (Not Another Retry)

Somewhere in 2026, the agent world split into two camps arguing about shapes. One camp — most loudly Cognition, the team behind Devin — argued that for hard sequential work like coding, a single agent running a tight loop with full context beats fancy architectures every time. The other camp — most loudly Anthropic, describing their multi-agent research system — showed that for broad, parallelizable work, an orchestrator fanning tasks out across a graph beat any single loop by huge margins. Both camps had receipts. Both were right.

That sounds like a contradiction, but it’s actually the most useful finding of the year: neither shape is better. They’re tools for different kinds of problems. This is the closing post of my three-part series — after why agents now run in loops and what graphs actually are in plain English, here’s the only question left: which shape does your task need? (If you want the full evolution story, I covered the prompt → chain → loop → graph arc in my workflows post — and this same shift is why I wrote about agents becoming employees.)

Why loops win the long road

A loop is one agent doing one thing until it’s done: act, check the result, adjust, repeat. It sounds primitive. It isn’t — it’s what makes coding agents work.

The reason is context. On a sequential task — write the code, run the tests, fix what broke — every step depends on everything before it, and the messy middle (the failed attempts, the error messages, the reasons you abandoned approach two) is exactly the information the agent needs to make approach three work. A graph that farms steps out to separate workers throws that scar tissue away. The loop keeps it. That’s the core of Cognition’s argument, and it matches what the debate surfaced all year: on sequential benchmarks and real coding work, single-threaded loops with shared context outperformed the clever architectures.

The loop also fails cheap. When a loop derails, you replay it and watch where it went sideways — one thread, one context, one log. When a distributed agent system derails, you get to interview five workers about whose memory diverged.

Why graphs win the branching road

Now flip the task. You need to process forty customer emails, summarize each, sort them into urgent/normal/never-gonna-read, and route the urgent ones to you with a drafted reply — and legally, nothing gets sent without your approval. Describe that out loud and you’ll hear the tell: “and then,” “in parallel,” “if this, then that.”

That’s graph territory. Branching is where graphs live — junctions where the route depends on what the work revealed (the plain-English breakdown covers nodes, edges, and state if that vocabulary is new). Parallel fan-out is the other superpower: Anthropic’s research agents beat single-loop baselines on breadth-first research largely because a lead agent spawned parallel workers and merged the results — work a single loop would grind through serially, burning the clock and your token budget.

And the third win is the boring one that matters most in a real business: checkpoints. A graph can draw a hard edge that says “stop here until a human approves.” A pure loop has no natural place to wait for you.

The decision checklist

Run your task through these five questions. Three or more “yes” answers to the loop column means loop; the graph column wins the same way.

1. Is the task one road or a map? One road (research X until you have the answer; fix this bug) → loop. A map with junctions (classify, route, summarize, approve) → graph.

2. Does step N need the full history of steps 1 through N-1? If yes — and for writing, coding, and diagnosis, it almost always does — keep it in one loop so the context survives. If each item is independent of the others, fan it out.

3. How many items? One deep item → loop. Forty shallow-but-real items → graph with parallel workers. Parallelism is a volume decision, not a status symbol.

4. Does a human need to approve anything? If the words “send,” “publish,” or “charge” appear in the task, the graph’s approval checkpoint is worth the setup cost on its own. That’s the same least-privilege thinking from my post on why agents lie and cheat — you want a place where the agent must stop, not a polite request that it should.

5. Do you need to replay failures? Loops give you one thread to read. Graphs give you per-node state and resumability — a crashed workflow picks up where it died instead of restarting from zero. For long-running business processes, that resumability quietly becomes the deciding factor.

One more rule of thumb from the year’s debates: start with the loop, and only build the graph when the loop hurts. The failure mode isn’t choosing the wrong shape — it’s building an orchestration masterpiece for a task a single well-prompted loop would have finished while you were still dragging nodes onto the canvas.

The bottom line

The 2026 loop-versus-graph debate wasn’t a war with a winner; it was the industry drawing its first real map of which shape fits which problem. Sequential depth favors the loop. Branching, volume, and checkpoints favor the graph. Most real solo-builder workflows — mine included — end up as a hybrid: a loop for the deep work, wrapped in just enough graph to route it, parallelize it, and stop it before it sends anything you didn’t approve.

If you’re running agents for actual business work now, my piece on agents becoming employees is the natural next read — the hiring logic maps onto the architecture logic almost one-to-one.

New to any of this? The start here guide is the beginner path, and the AI Tool Advisor helps you pick tools for the workflow you just designed.