Loop and Graph Engineering, Explained Simply

The bug that taught me this

I run a learning platform for our students, and it has a levelling system: you earn XP, hit a threshold, and level up. A straightforward feature. I did what I always do: described it properly, gave the agent context, set a goal and let it run. It came back saying it was done. I tested it, and it looked good.

Except it had quietly broken another feature, our streaks logic, on the way through. I did not notice for two or three days. My first thought was that the model was not good enough. It was not that. I had told it what to build, but I never properly defined what done meant. Those are completely different things, and that gap is where I think most people are losing time right now.

Prompt vs loop

A normal prompt works like this: you ask, it does the thing once, hands it back, and you review it and decide if it is good. You are doing the quality check every round.

A loop moves that job to the agent. You give it the task and the condition it has to pass. It does the work, checks itself against the condition, and if it fails, goes again, and again, until it passes. Then it stops. There are three parts: a start (a schedule, a rule, or you kicking it off), the task, and the success criteria. Without an end criterion you get the famous infinite loop.

Of those three, only the success criteria is really interesting. "Build me a levelling system" is not a criterion. It is a wish. There is nothing for the agent to check itself against, so it builds something reasonable, decides it is probably fine, and hands you something 70 or 80% done. That is the worst outcome, because now you have to find the missing 20% yourself, and you will not know where it is until someone sends a bug report.

What I write now looks like: the tests pass, XP thresholds trigger correctly at the boundary, and streak logic still behaves. Every line is simply true or false. No judgement left anywhere. We go deeper on this in our written guide to loop engineering.

Loops work outside code too

Our platform has computational thinking challenges for students, and writing them by hand is slow. But each challenge has hard, checkable requirements: exactly one correct answer, a reference solution that actually runs, a difficulty within the band we want rather than secretly brutal, and it must teach the specific concept it is meant to.

None of that is taste. All of it is checkable. So it loops: generate, test itself, bin the failures, go again. Instead of sitting through each challenge one by one, I review the whole batch at the end. That is how we produced hundreds of them.

Four kinds of loop, four levels of trust

Anthropic's engineering team wrote up different loop patterns, and it is worth reading. Here is the version that stuck with me:

Climb the trust ladder one rung at a time

Those are not really four features. They are four levels of trust, the same ladder you use with people. With an intern you spell out each step: run Facebook ads, build creatives, click this, look at these numbers. With a senior hire you say "I want more revenue from ads" and they figure it out. That unsupervised judgement is what companies pay seniors a lot for.

Each rung up is not more capacity. It is more unsupervised judgement, which means more mistakes can happen while you are not watching. So you climb one rung at a time, only after the rung below has earned it.

Why one agent with a big job goes weird: graphs

Loops did not fix my second problem. After the levelling feature I got ambitious and handed one agent a much bigger job: build the feature, write the tests, update the docs and check it against the design. It started fine, then got progressively weirder. It forgot constraints from the beginning and contradicted decisions it had made 40 steps earlier.

That is not a model problem. It is a context window problem. The agent is holding the entire job in one context, and past a certain load it stops being reliable in ways that are hard to spot. Like your brain: remembering one thing is easy, remembering a thousand is not. It is the same reason you do not give one person on your team every job. You give them one goal and a few tasks to focus on.

The fix is to stop using one agent and draw a map instead: this agent does this, that one does that, here is the order, here is what depends on what. That map is a graph, and each agent gets its own clean context. If you have ever told Claude Code to spin up sub-agents in parallel, one hunting for frontend inspiration, one fixing the backend, one writing tests, all reporting back, you have already built one. It does not have to be parallel either: implement, then verify, then advise, then fix is a sequential graph. Our written guide on graph engineering goes further.

Loops inside graphs, and when to use which

The part I found most useful is that they nest. Any node in a graph can itself be a loop. Give that research node a success criterion for what a good frontend reference looks like, and now it loops inside your graph. It was never loops versus graphs. A loop is just a graph with a cycle in it. If you want to push further, look at dynamic workflows in Claude Code, which are scripts that orchestrate those dependencies for you, for example auditing every route handler for missing auth checks file by file.

None of this is new. LangChain's LangGraph library has done this for years. The vocabulary just became famous in 2026.

The simple rule: a repeating task with a finish line is a loop, one agent. A job with real dependencies between parts is a graph, multiple agents. Not because it is elegant, but because each agent starts clean, does one job, and hands over a finished result instead of everything it weighed and discarded along the way.

The real lesson: brief properly and define done

What I really took away was neither loops nor graphs. I spent two years getting good at describing what I wanted to build and almost no time getting good at describing what finished looks like. The second is now the whole game.

So the compounding skill is not coding or design any more. It is briefing properly and knowing how much judgement you are willing to hand over. That is management. Same job, different hire.

Writing pass conditions that actually catch bugs, like my broken streaks, still requires understanding the system you are building: what can break, where, and how to test it. That is why our AI-Native Software Development Programme teaches fundamentals and agentic workflows together. You can try the first lessons in the free trial, and if agents are still new to you, start with AI agents explained like you're 10.