What are AI loops and graphs, and why do they matter?

Ask a model to write something and you get one attempt. Ask it to check its own attempt and it will usually approve it: Anthropic reported in March 2026 that agents grading their own work tend to praise it even when a person can see it is mediocre. Most of the useful engineering around AI today is about getting past that first attempt without trusting the model's opinion of itself. Two shapes do most of the work. A loop makes one piece of work correct. A graph organizes many pieces of work and decides where the checks and the people go.

This page defines the vocabulary, walks through one example from start to finish, and points to the articles in this section that go deeper on each part.

The words, defined once

Term	Meaning	Example
Unit	One piece of work small enough to check on its own	One product page, one bug fix, one answered question
Worker	Whatever produces a draft of a unit: a model call, an agent, sometimes plain code	A model that rewrites a page from a brief
Check	A test of the draft that can fail it without anyone watching, using evidence the worker cannot edit	Tests exit with an error; a claim has no matching source line; a file outside the plan changed
Gate	A point the work cannot pass until a check (or a person) says yes	"Only pages with every price matching the price sheet go forward"
Loop	Produce, check, correct, repeat, with a limit on attempts	Three tries per page, then hand it to a person
Graph	The map of all the steps and how work flows between them	Split the job, run workers in parallel, gate each result, merge
Node	One step in the graph	A splitter, a worker, a plain-code step, a gate
Edge	A connection that says what runs next, sometimes with a condition	"If the gate fails, go back to the worker"

Three things are not checks, even though they are often used as if they were: "it looks good", "the model says it is confident" and "no errors were raised". Each of them passes almost everything. The article What makes a check in an AI loop real? goes through why, with real checks for code, writing, research and data.

Loops: making one unit correct

A loop repeats four moves: produce a draft, check it, send what failed back with the evidence, try again. Anthropic's guide to building agents calls one version of this the evaluator-optimizer workflow: one model call produces a response and another evaluates it and gives feedback, round after round. The same guide stresses that agents need "ground truth" from their environment, such as the result of actually running the code, and that a maximum number of iterations keeps a loop under control.

Research systems show both the strength and the weak point of loops. In the Reflexion paper (2023), an agent turns the feedback from a failed attempt into a short written reflection and keeps it in memory for the next try; for coding, it writes its own unit tests and uses them as the check. The authors also report the catch: when those tests were weak, wrong solutions passed, the agent stopped early and submitted them. A loop is only as good as the check inside it.

Two rules follow. The check must be able to fail the work with nobody watching, and the loop must stop: after a fixed number of attempts, an unsolved unit goes to a person instead of around the loop again. How do you build an AI loop with a real gate? builds exactly that in about 170 lines of Python you can run without an API key, with gates for tests, sources and file scope. The older walkthrough How do you build a generate, test, revise loop? shows the same idea with a model in the worker seat, and How do you set up a self-improving agent loop safely? applies it to improving an agent's prompt.

Graphs: deciding which units exist and how they connect

A single loop handles one unit. Real jobs have many: forty pages, twelve files, thirty sources. A graph decides how to cut the job into units, which units can run at the same time, and where the gates sit. LangGraph, a popular open-source framework for this, describes a workflow as shared state plus nodes (functions that do some work and return updates) and edges (fixed or conditional transitions that pick the next node). Nodes that run in parallel belong to the same step, and a feature called Send runs the same worker once per item, a pattern its documentation calls map-reduce.

Most graphs use a handful of node roles:

A splitter breaks the job into units. Anthropic's guide calls the model-driven version orchestrator-workers: a central model breaks down the task, hands pieces to workers and combines their results.
Workers produce drafts, often in parallel.
Plain-code steps do what code does better than a model: fetch a file, compare two numbers, count words, merge results.
Gates decide what moves forward.

A graph also has two kinds of return path. A correction edge is short: it sends one failed unit back to its worker with the evidence of what failed and how much may change ("the price on line 14 does not match the sheet; change only that line"). A learning edge is longer: when the same failure keeps appearing, it turns the lesson into a change to the brief that every future unit receives ("prices include tax; never copy the old tax note"). The correction edge fixes this unit; the learning edge stops the next twenty from making the same mistake.

One habit matters more than any framework: return single failed units, not whole batches. If 37 of 40 pages pass, rerunning all 40 wastes the work that was right and gives the model 37 new chances to break something. How do you design a graph of AI agents? works through the node roles, the two edges and this rule with a full example.

Graphs cost something. Anthropic reported in 2025 that its multi-agent research system used about 15 times the tokens of a chat, and that tasks where every agent needs the same context, such as most coding, fit poorly. In October 2026 it went further and argued that many company agents built as a router plus specialist subagents would do better as one loop: Should you build one agent loop or a team of subagents? sets out that argument, its evidence and the other views. For the basic idea of handing work to helper agents, see What are sub-agents, and when should you split work across them? and How do you build a multi-agent workflow?.

Where people approve

A gate does not have to be code. Some decisions belong to a person, and the useful question is where. A sound rule is to place human approval by blast radius: how much damage a wrong step could do and whether it can be undone. Drafts on a branch, files in a scratch folder and test runs can loop freely. Sending, paying, deleting, deploying and merging into what everyone uses wait for a person. How confident the model sounds does not enter into it.

In practice this often means one approval at the end, the final merge or publish, with a short packet in front of the approver: what changed, what the checks found, what failed and was fixed, and what still needs judgment. Frameworks support the pause directly: in LangGraph, a node calls interrupt(), the graph saves its state and waits, and the person's answer resumes the run. Where should a person approve work in an AI loop? covers this in detail, and How do you keep a human in the loop on an automation? shows the same principle in a no-code automation.

A worked example: updating 40 product pages

A shop changes its prices and wants 40 product pages updated from a new price sheet. Here is the job as a graph.

price sheet + brief
        │
   [splitter: one unit per page]  (plain code)
        │
   ┌────┼────┬─── … 40 units, in parallel
[worker] [worker] [worker]          (model)
   │       │       │
[gate: every price matches a sheet line,
       links work, only this page's file changed]   (plain code)
   │ pass            │ fail → back to its own worker with the evidence (max 3 tries)
   │                 │ 3 fails → list for a person
   │ same failure on 5+ pages → learning edge: add a rule to the brief
   │
[merge passed pages into one change]   (plain code)
        │
[person approves the change before it goes live]

Suppose 34 pages pass on the first try. Four fail because the model rounded $19.95 to $20; each goes back alone with the line that failed, and all four pass on the second try. Two fail three times because the sheet has no line for those products; they land on a short list for a person, who discovers two products were discontinued. Meanwhile, the rounding failure appeared often enough that the brief gains a rule, "copy prices exactly, never round", so a later batch starts with the lesson built in. Nothing goes live until a person reads the summary and approves the merge.

Notice what the person did not do: read 40 pages. The gates read them. The person spent time on the two cases that needed judgment and on the one decision that could hurt the business.

Try it: Pick one task you already do with AI. Write down a single check that could fail the result without you reading it, then feed it a deliberately bad output and confirm it says no. If you cannot think of such a check, that task is not ready for a loop.

If you want help cutting a job of your own into units and checks, this prompt is a good start:

Prompt

Here is a job I want to run with AI: [describe the job and what "done" means].
1. Split it into units that can each be checked on their own.
2. For each unit, name one check that can fail it without a person reading it, and say what evidence that check would return when it fails.
3. Mark which steps can be undone easily and which cannot.
4. Tell me where a person should approve, and why, based on the damage a mistake could do.
Do not suggest "ask the model if it is correct" as a check.

The rest of the section, in reading order: what makes a check real, how to build a loop with a real gate, how to design a graph of agents, where a person should approve, and two case studies: Anthropic's automated alignment researchers, a large loop whose checks rejected work with nobody watching and whose agents sometimes tried to cheat, and the October 2026 guide on folding subagents into one loop. For a first agent loop written by hand, see How do you build a simple agent loop with the OpenAI API?.

Do you need a framework to build loops and graphs?

No. A loop is a for loop with a check and a limit, and a small graph is a few functions called in order, with a list of units in the middle. The hands-on article in this section uses nothing but Python's standard library. Starting in plain code has a real advantage: you can see every check and every edge, and nothing happens that you did not write.

A framework starts to pay off when you need what plain code makes tedious: saving the state of a long run so it can resume after a crash or a human pause, running many workers in parallel and merging their results, or going back to an earlier saved point of a run to see where it went wrong. LangGraph's documentation covers all three, with checkpoints, Send for fan-out and interrupts for human approval, and it also caps the number of steps in one run, a built-in version of the attempt limit.

Whichever you choose, the parts that make the system trustworthy are the same and do not come from the framework: checks that can fail the work, a limit on attempts, failed units returned one at a time with their evidence, and a person at the step where a mistake would be costly.