Loops, Graphs, and Who Decides What the AI Does Next

A while back a well-known developer posted a one-line question that made the rounds in my corner of the internet: are we still talking about loops, or are we talking about graphs now? No explanation, no thread. Just the question. And a lot of smart people spent the next few weeks arguing about what he meant.

I’m the AI guy in most of my circles, so within a few days someone asked me to translate. “Loops, graphs — is this something I need to care about?” And I gave the honest answer, which is the reason this guide exists and the reason it’s shaped the way it is: I understand what the words mean, I think the shift underneath them is real, and I have not yet built one of these things in a way that runs a real process for real stakes. So take this for what it is: an explainer written from the edge of something I’m still walking into, not a war story with a lesson at the end. I’ll come back and add the scars once I have them.

But I don’t think you should have to wait for my scars to understand the conversation. Because you’re going to keep hearing these two words, and the idea underneath them is genuinely one of the more useful mental models for thinking about what “an AI agent” even is. So let me do the translation.

First, what an “agent” is doing when it works

Forget the two words for a second. Picture the mental model I keep coming back to on this whole site: AI as a brilliant new hire who knows nothing about your specific business. Universal knowledge, incredible speed, zero context on you.

Now imagine you don’t just ask this new hire a single question. You give them a job. “Book me a flight to Zurich, find a hotel near the venue, and put it all on a calendar.” A real job has steps, and the steps depend on each other, and some of them can go wrong.

Everything in the “loops versus graphs” argument is about one question: who decides what happens at each step? That’s it. Hold onto that and the jargon melts.

The loop: hand over the whole job and let go

The simplest, most powerful way to give an AI a job is what people call a loop. It works like this. The AI looks at where things stand, decides the single next thing to do, does it, looks at the result, and decides the next thing, over and over, on its own, until it decides the job is finished.

That’s the loop. The AI is both the worker and the manager. It sets its own next step and it decides when to stop.

If you’ve ever watched a coding agent like Claude Code chew through a task (read a file, run a test, fix the error the test surfaced, run it again), you’ve watched a loop. If you’ve used one of the “agent” modes in ChatGPT or Gemini that goes off and browses the web across several steps to answer you, that was a loop too. It’s most of what people currently mean when they say “agent.”

And it’s genuinely great, because it’s how you get real autonomy without hand-writing every step. You describe the destination; the new hire finds the road. When the task is small and bounded (a handful of steps, nothing irreversible), a loop is exactly the right tool, and reaching for anything heavier is over-engineering.

There’s a catch, though, and it’s the whole reason the second word exists. Because the AI decides its own next step and its own stopping point, you’ve handed over the steering wheel completely. Most of the time that’s fine. But think about what “completely” means when you scale it up:

• It can wander. Give a vague instruction and a loop can go on a long, expensive detour you never asked for: reading fifteen files to fix a one-line bug, or quietly building a feature nobody requested, because at every step it decided that was the reasonable next move.
• It can’t easily stop and check with you. A loop tends to run to the end or fail. There’s no natural “pause here and wait for a human to say yes” built into it. You bolt that on afterward, awkwardly.
• When it breaks, it breaks all the way back to the start. If the job falls apart at step twelve, a plain loop usually can’t pick up at step twelve. You run the whole thing again — and pay for the whole thing again.
• You can’t easily see why it did what it did. It’s one long stream. Reconstructing the reasoning after the fact means reading a transcript and hoping.

None of that matters when you’re the one sitting there watching it, fixing course as you go. It starts to matter a lot when the thing is running unattended, on a schedule, doing something you can’t take back.

The graph: break the job into stations with checkpoints

So here’s the other word. A graph is what you get when you stop handing over the whole job and instead lay out the shape of the job in advance.

Instead of one open-ended loop, you break the work into a set of defined steps (call them stations) and you draw the connections between them yourself. Step one feeds step two. After step two, if the result looks like this, go to step three; if it looks like that, go back and try again. Some connections are gates: the AI is not allowed to cross until a check passes, or a rule is satisfied, or a human clicks approve.

The everyday version of this is any workplace with a real process. A new expense report doesn’t get paid because one eager new hire decided it should. It moves through stations: someone enters it, a rule checks it against policy, anything over a threshold needs a manager’s sign-off, and only then does the money move. Nobody calls that a “graph,” but that’s exactly what it is: defined steps, defined hand-offs, and a hard gate in front of the irreversible action.

The key difference from the loop, in one line: in a loop, the AI decides what happens next. In a graph, you decide what happens next, and the AI only decides what happens inside each station. You’ve taken back the steering. You still let the brilliant new hire be brilliant, but only within the lane you drew for them.

And notice the loop doesn’t disappear. Any single station can still have a little loop running inside it (“keep refining this draft until it passes the check”), where the AI iterates freely. Graph engineering isn’t the opposite of loops. It’s putting a frame around them. The best production setups I’ve read about are exactly this hybrid: a firm outer structure you designed, with pockets of free, looping autonomy inside the boxes where that autonomy is safe.

What the frame buys you is the flipside of every loop weakness above. You can gate the dangerous step. You can pause at a station and wait for a human without the whole thing grinding. When it fails at station twelve, you resume at station twelve instead of starting over. And because the work is laid out as named steps, you can actually see where it went wrong.

The one line that made it click for me

Across all the arguing, one framing kept showing up from people who’d never talked to each other, which is usually a sign it’s true: the loop gives you autonomy. The graph gives you control. You want both.

That’s the whole thing. Graphs aren’t the grown-up version and loops the toy. They sit at opposite ends of a dial between “let it run” and “hold the reins,” and the entire skill is knowing where to set the dial for a given job. A one-off research task? Let it run. Automatically issuing refunds to customers? Hold the reins, and put a gate in front of the word “refund.”

The metaphor going around for the loop end of the dial is one I keep stealing. Handing an AI every possible tool “just in case it needs them” is like sending someone to make you a sandwich and also handing them a bazooka, you know, in case of zombies. Most of the time nothing bad happens. But you’ve given a lot of power to a worker whose next move you can’t fully predict. A graph is how you keep the bazooka locked in a cabinet that only opens after the right person has confirmed there are, in fact, zombies.

Who actually needs to think about this

I want to be straight about this part, because a lot of the online discussion quietly skips it.

If you are a person firing off requests in ChatGPT or Claude (writing, thinking, researching, one thing at a time with your eyes on the screen), the loop-versus-graph question is almost entirely invisible to you, and it should be. You are the checkpoint. You are the gate. You read every result before anything happens because of it. You don’t need to reason about the machinery underneath, any more than you need to understand your car’s transmission to drive to work. If someone makes you feel behind for not having an opinion on graphs, they’re confusing plumbing with skill.

The stakes climb the moment three things stack up: the AI is acting autonomously (no human watching each step), repeatedly (a process, not a one-off), and with consequences you can’t take back (money moves, emails send, records change). That combination is where the loop’s “it decides everything, including when to stop” goes from convenient to genuinely dangerous, and where the structure of a graph earns its cost.

Which means this is mostly an organizational question, not an individual one. It’s the same line I keep drawing between playing with AI and building an actual company capability. The interesting version of “loops or graphs” isn’t about your personal chat habits. It’s about whether the automated process your company is about to wire into a real workflow has a human gate in front of the step that can hurt someone. That’s a leadership question wearing an engineering costume.

If you want to feel this dial rather than just read about it, the closest thing I’ve built is the Company Simulator on this site, a little game about delegating work to AI coworkers, where the whole lesson is that handing over more autonomy without building the checkpoints to match is how good work quietly turns into expensive messes. Same idea, lower stakes.

The honest counterweight: graphs are not free, and not always better

If I stopped here you’d walk away thinking graphs are simply the smarter choice and everyone should be building them. I don’t believe that, and more importantly, neither does Anthropic, the company with the most to gain from you building elaborate AI systems.

Their own published guidance is notably more cautious than the excited version of this discussion. They report having watched teams spend months building intricate multi-agent architectures (which are graphs, structurally) only to find that better prompting on a single, simple agent got them to the same place. And these systems are not cheap: in their own write-up of the multi-agent research tool they built, it ran on roughly fifteen times the tokens of an ordinary chat, and they found that most of the extra performance came straight from that extra spend. Their stated rule is: start with the simplest approach that works, and add complexity only when the evidence in front of you demands it.

That squares with everything I believe about this whole field, and it’s worth saying plainly because the internet rewards the opposite. Structure has a cost. Every gate you add, every station you define, every hand-off between steps is more to build, more to maintain, and more places for the seams to show. A graph you didn’t need is just bureaucracy you built for a robot. The right instinct is not “how do I graph this?” It’s “does the simplest possible version, a single agent in a loop, actually fall short here, and if so, on exactly which step?” Then you add structure at that one step, not everywhere.

There’s also a healthy dose of skepticism worth keeping about the words themselves. People who’ve spent careers in software and data engineering will tell you, correctly, that “break a job into defined steps with dependencies and checkpoints” is not a new invention. It’s how serious workflows have been built for decades, now getting rediscovered with fresh vocabulary because there’s an AI inside the boxes this time. One engineer’s blunt version: it’s ninety-five percent things we’ve done forever, and five percent genuinely new because the workers are now unpredictable in a way software components never were. That five percent is real and it matters. But it’s five percent, not a revolution, and anyone selling it as a revolution is selling something.

What I’m actually doing about it, and what I’d tell you to do

So where does that leave someone who isn’t a developer and doesn’t want to fall behind but also doesn’t want to build an assembly line for a job that needs a screwdriver?

For yourself: nothing changes. Keep using the best tools you can, keep treating them as a conversation rather than a vending machine, and keep being the human in the loop who reads the result before it matters. You already run the safest possible graph — it has one gate, and the gate is you.

The moment to actually reach for this thinking is when you or your company starts letting AI act without you watching. When that day comes, the question to ask isn’t “loop or graph” in the abstract. It’s smaller and more useful: where is the step that can’t be taken back, and what stands in front of it? If the answer is “nothing, the AI just decides,” you’ve found the place a gate belongs. That’s the whole discipline, stripped of vocabulary.

And me? I’m doing what I tell everyone to do: learning by building, not by watching. I’ve read enough to explain the shape of this honestly, which is what you just got. The next step is to actually put a small, real, unattended process on rails (something with a step that matters, and a gate in front of it) and find out where my clean mental model meets the mess of a real system. That’s where the useful knowledge lives, and it’s not knowledge you can get from a diagram.

When I have it, I’ll come back and rewrite the ending of this guide with what actually broke. That’s the deal I make with everything on this site: I’d rather tell you honestly where the edge of my experience is than pretend the map is the territory. Right now, on graphs, this is the edge. I’ll move it.

---

This guide is a companion to two more hands-on pieces about the same underlying idea from the inside: spawning subagents, which is one common shape a “graph” takes in practice, and giving Claude a finish line instead of a script, which is a small, practical version of gating a loop on a real check. For the strategy angle on why any of this belongs to leadership rather than IT, Giving Everyone Copilot Isn’t an AI Strategy is the piece this one quietly leans on.