Everyone who has used a coding agent knows the basic loop: read, act, check, decide, repeat until done. The term loop engineering has started circulating in the industry for good reason — once you see the loop as an engineering object rather than a chat session, a ladder of capability opens up. Here is that ladder as I build it, and then the step beyond it that I think matters more: wiring loops into graphs.
Four levels of loop
Level 1 — the agent loop. One session, one task, a human watching. This is where everyone starts and where most teams stop. Its ceiling: "done" is whenever the agent feels done, and the human is the verification machinery.
Level 2 — the verification loop. Add a grader. Not a vibe — a mechanical one: a gold set of inputs with expected outputs, a deterministic checker, an eval suite. The loop now iterates until the score clears the bar, and "done" becomes a measurement. This is the level that changes economics, because it's the level where the human leaves the inner loop. If you've invested in evals for your retrieval or your business logic, that investment cashes out right here: your gold set becomes the grader.
Level 3 — the event-driven loop. Decouple the loop from a human's keyboard. A loop finishes and writes a signal — a file, a hook firing, a message with a defined shape. Another loop, waiting on that signal, wakes up and starts. Two isolated contexts, one explicit contract between them. Isolation is the point: a loop with a clean, small context outperforms a giant session every time, and the signal is what lets you have both isolation and coordination.
Level 4 — the improvement loop. A loop that watches outcomes and proposes changes to the system itself — a better skill, a tighter check, a revised spec — with a human approving every change. The loop climbs the hill; the human holds the map.
From loops to graphs
Levels 1 through 4 give you excellent single workers. They don't give you a job. Real jobs — build this subsystem, produce this quarter's compliance package, migrate this integration — are too big for one loop and too interdependent for a pile of independent ones.
The step beyond loop engineering is what I call graph engineering: a decomposition loop splits the job into parallel work with verifiable contracts; parallel build loops execute them simultaneously; their completion signals are correlated — tested against each other, not just counted; an integration loop assembles the parts and verifies the whole; and fix loops pick up the improvement messages that integration emits. The execution unfolds as a graph of loops, running until the job is done.
For the decomposition itself I reach for a twenty-year-old discipline: domain-driven design. DDD was invented to cut systems along boundaries where teams could work independently. It turns out to cut exactly where loops can work independently — a bounded context is a contract a build loop can be verified against. The old strategic design work didn't get automated; it got a new executor.
A worked example, end to end: an annual compliance attestation package — controls evidence gathered, tested, cross-referenced, assembled, every claim cited. A decomposition loop splits it by control domain into contracts. Six build loops run in parallel, each gathering and testing evidence for its domain, each graded by its contract's checks (Level 2, six times over). As each finishes, it signals (Level 3). A correlation step holds the gate until the signals reconcile — the access-control evidence and the change-management evidence must name the same systems, and a mismatch is caught here, not by an auditor. The integration loop assembles the package and runs whole-package checks; failures go out as messages that fix loops pick up. A human approves at the gates that matter. The deliverable ships with its signal log attached — the evidence of how it was made is part of what's made.
Why architects should care
The pattern's value isn't only throughput. It's two properties that ad-hoc agent use never gives you.
Visibility. The executed graph — drawn from its own signal log — is something an architect can read the way they read an architecture diagram. You can see where work flowed, where it waited, where it looped. Compare that with "we had a long chat with an agent and something came out."
Repeatability. The graph is deterministic even though every node is agentic. The decomposition pattern, the contracts, the gates — those are fixed and versioned; the intelligence lives inside the nodes. Deterministic pattern, agentic nodes. Run the same graph on next year's attestation and you get the same shape of execution with new content — which means your architecture and design patterns finally reproduce, instead of living in the heads of whoever built the last one.
One disambiguation, because the word is overloaded: this execution graph is not your knowledge graph. The knowledge graph models what your business is — entities, relationships, facts. The execution graph is how work runs. A mature setup has both, and the loops in the second consult the first.
Start at Level 2. Take one task your team already trusts an agent with, and give it a grader instead of a reviewer. Everything else on the ladder — signals, graphs, the whole factory — grows from the day "done" became a measurement.