Loops and Graphs: Stop Micromanaging Agents — Approve Only the Final Merge

0 Introduction

You inspect every step an agent executes not because you want to, but because no other mechanism does it for you. To truly step off the "foreman's chair" you need two things, yet almost everyone builds only one.

A loop lets a work unit self-correct without you until it passes. A graph decides which work units exist and how they are organized. Below we break down the difference, the non-obvious mechanics, and the key to approving just one thing instead of every step.

1 A Loop Is a Check That Can Fail

Strip everything away and a loop has only four parts: execute, check, correct, repeat until green. The check is the most important part.

If there is no mechanism that can judge failure after you walk away, it is not a loop — it is just a scheduler. This sounds obvious, yet almost no one writes the check conditions first.

Teams usually assemble the workflow first, then tack on a review step at the end where another model checks the output. Two optimists nodding at each other.

Write the conditions first, and make them programmatically decidable:

GREEN   Test suite exits with status code 0
GREEN   Every conclusion includes source line numbers
GREEN   diff only modifies files listed in the plan

NOT A CHECK   Output looks good
NOT A CHECK   Model says it's confident
NOT A CHECK   No errors reported

That last one traps even careful people. No error does not mean the result is correct.

If you build a loop on such conditions you may get a supremely confident system that repeats the same mistake until the budget runs out, with perfectly clean logs.

2 An Upper Bound No One Tells You

A loop can make a single work unit better. That is its entire job, and it excels at it.

But it cannot decide which work units exist, their execution order, or discover that two of five steps don't actually need to wait for each other.

You end up with an excellent agent executing three steps in the wrong order — steps that should never have been sequential.

Each step is correct internally, yet the overall result is slow and structurally wrong.

Tuning the loop further won't help because the fault is not inside any work unit.

This is when people blame the model, and when the next architectural layer starts delivering value.

3 Graph Is the Upper Layer

Graph describes the shape of the entire job: which tasks run, which can run in parallel, which must wait, which are unnecessary, and where results flow.

It has only two elements:

Node — a work unit: a well-bounded task with one input and one output.

Edge — a dependency: this node's output becomes another node's input.

Almost every unnecessary wait comes from treating "then" as an edge.

Example: "summarize file, then query weather" have no dependency. Querying weather does not need the file summary.

They are independent nodes that got chained only because you typed them in that order.

Apply this to every arrow in your pipeline: Does the next step actually read a variable from the previous step?

If you cannot name the exact variable passed along, there is no real dependency edge — the wait is pure waste.

Most workflows have two or three such arrows; removing them is often the single biggest speedup.

4 Four Node Types — One Isn't Even a Model

Splitter, Worker, Code Node, Gate — that's the whole vocabulary.

4.1 Splitter

Splits work into units and sits at the front. If the split dimension is wrong, all downstream work is wasted:

Split a repo by folder → four workers may re-review the same three files.

Split by blast radius → each worker sees different content, none fully replaceable.

4.2 Worker

Handles one work unit per run.

Uses a single perspective.

Has its own context window.

The last point is often ignored. If four auditors share one context window they converge: the first writes a finding, the others orbit it, and you get four reports on the same issue.

You paid for four people but got one viewpoint and three echoes.

4.3 Code Node

The node type people forget exists.

Merging, sorting, deduplication, comparing exports before/after — none require reasoning. Each has a single correct answer, usually a few lines of code. Using a model adds cost, latency, and variance to a step that had none.

If you can describe a transformation without using "judge", "decide", "evaluate", or "summarize", it should be code.

If every graph edge goes through an agent, you pay for every connection.

5 Where Does the Loop Belong?

Loop lives inside a node; graph lives between nodes.

Inside a work unit: execute, check, correct, repeat until green. produce, check, correct, repeat until green.

Between work units: split, fan out, merge, gate, send back. split, fan out, merge, gate, send back. None of the second group can be expressed inside a single work unit.

So you don't choose one or the other:

A graph without internal loops produces unverified work in parallel — worse than serial execution because it produces more unverified output.

A loop without an external graph is just a very good step in a queue nobody designed.

6 Two Return Paths — and the One Everyone Skips

A graph with no return path is just a pipeline: it produces a result and forgets everything. Next week it starts from the same place and repeats the same blind spots.

A graph that keeps working needs two return paths with completely different jobs.

6.1 Correction Edge (short)

Gate rejects a work unit and sends it back to the step that produced it, which fixes the current run.

6.2 Learning Edge (long)

An accepted result flows back to the Splitter as a new constraint, correcting every future run.

Almost everyone builds the first and skips the second. The symptom: a system that runs fast but never gets smarter.

The learning edge carries not the output but constraints distilled from it:

ACCEPTED   utils slice migration completed, passed on first run (the splitter's brief for every later slice)
DERIVED    adapters must preserve keyword args unchanged (the splitter's brief for every later slice)
LANDS IN   splitting brief for every subsequent slice (the splitter's brief for every later slice)

Notice where it lands: not in the Worker's instructions, but in the brief that decides how work is split.

A confirmed cause becomes a rule, so the next problem starts where the last one ended.

7 Return the Work Unit, Not the Whole Batch

This is the costliest mistake on the return path.

Four slices migrated; one test fails. If you roll back the whole batch, the three correct slices get rewritten.

Their next versions differ but aren't better — they were already fine.

You then re-validate all four, and any originally correct slice may now fail for unrelated reasons.

You turned one failure into four uncertain results and paid extra. Do it twice and the system never converges.

Externally it looks like the model keeps failing; actually your return path destroyed correct work.

Every return must carry four things, each with a purpose:

UNIT      handlers slice
VERDICT   red
REASON    test_auth_redirect failed
EVIDENCE  expected 302, got 200, handlers/auth.py:88
SCOPE     only fix this file, do not modify other slices

The last line matters more than it appears.

Without Scope, the returned unit balloons: Agent opens a file, spots two side issues, fixes them all. A one-slice fix becomes a four-file diff nobody reviewed.

Max three attempts. If a unit fails three times, the problem is likely in the plan that created it — a loop cannot see that plan.

8 Open Gates by Blast Radius, Not Confidence

Many designs use a confidence score with a threshold. That's the wrong variable.

Confidence is the weakest decision input because it's the only variable the model itself can influence.

The real question: if this change is wrong, what happens? Classify work by the cost of fixing a mistake:

8.1 Reversible & Limited Blast Radius

Copy edits, tests, well-covered independent functions. A bad merge just needs a revert — this lane can auto-approve.

8.2 Reversible but Wide Blast Radius

Shared utilities, schema additions, anything used by dozens of callers. Require deterministic checks and a clean run trace.

8.3 Hard to Reverse

Database migrations, deletions, anything writing production data or moving money. This lane never auto-opens , regardless of score.

That's not "set the threshold very high"; it's a lane that stays closed. The distinction matters because thresholds get tuned; a closed lane stays closed.

Inside an open lane, Gate reads evidence in this order:

Deterministic results first

Then the current run trace

Then how often this node's past work was rolled back

Finally the model's own judgment

9 Start from Your Own Work

Pick a task you repeat. Draw the Splitter, execution lanes, Merge, a Gate, and a return edge.

Build the Gate first. Once you have a mechanism that can explicitly fail, everything else gets easier. A graph without a Gate is just a faster way to produce unverified output.

Then build the execution lanes.

Finally build the learning edge — last because you can't distill constraints until you have acceptable results.

Put the human on the step with the highest consequence and lowest reversibility .

Approve the Merge. Decide which fixes ship. Not intermediate outputs, not every step.

A human in the middle of a graph becomes the slowest node in that graph. The whole graph's speed is capped by that person's reading speed.

The entire methodology condenses to three sentences:

Measure the whole path, not just the final answer.

A conclusion that doesn't change how the next step runs is just a report.

Any failure not turned into a permanent constraint you will meet again.

Most people keep tuning a single loop and call it a system.

Those who draw the graph around the loop start running whole agent clusters and wonder why everyone else struggles to catch up.