Loops, Graphs, and the Layer That Matters

This site uses cookies to understand how visitors find us.<br>You can accept or decline non-essential cookies.

Decline<br>Accept

Menu

manifesto<br>docs<br>blog<br>roadmap<br>registry

GitHub

Discord

install.sh

The timeline spent July arguing about whether we moved from loop engineering to<br>graph engineering. One post asked “are we still talking loops or did we shift<br>to graphs yet?” and pulled half a million views. Within a day there was a<br>manifesto, a backlash, and a wave of guides teaching the new discipline.<br>Before that it was loop engineering. Before that, context engineering. Before<br>that, prompt engineering.

Four namings in three years. Each one describes the layer of scaffolding one<br>level further out from the model. Each one arrives with the claim that the<br>previous layer is obsolete. Each one is real work, and none of them is a<br>paradigm.

Here is the pattern worth noticing: the industry keeps inventing disciplines<br>for the space between the model and the backend. That space keeps generating<br>new disciplines because it keeps generating new pain, and it keeps generating<br>new pain because of the paradigm underneath it. The agent scaffolding is its<br>own world, separate from the system it acts on, integrated by hand. Every<br>year the scaffolding gets a new floor, the floor gets a name, and the name<br>gets a course.

Floor 1: prompt engineering (2023)

Floor 2: context engineering (2024)

Floor 3: loop engineering (2025-26)

Floor 4: graph engineering (July 2026)

What loops and graphs are

Strip the vocabulary and both terms are describing prompts and patterns.

A loop is one agent’s cycle: plan, act, observe, repeat until a stop<br>condition. The engineering is the verifier and the stop condition. A graph is<br>several of those cycles integrated together: specialized nodes, routing<br>edges, state passed between them. A loop is just a graph with one node.<br>Neither is new. State machines and DAG orchestration have run production<br>systems for decades. What happened in July is that the pattern got a new<br>name, and the new name got a new market.

None of this is a criticism of the patterns. Fan-out across parallel<br>researchers and fan-in to a reviewer with a fresh context is a real<br>improvement over one agent drowning in its own transcript. Explicit routing<br>you can read as a diagram is better than control flow you reconstruct from a<br>log. These are good patterns. We use them.

The criticism is of the frame. Loop engineering and graph engineering present<br>the shape of the agent’s reasoning as the load-bearing engineering decision.<br>It is not. The shape is the easy part, and it is disposable. The load-bearing<br>decision is what the loop or the graph is made of, and what happens to it<br>after it works.

Patterns come down. Substrates hold.

At iii, we have been reducing all patterns to a few core primitives. Here is<br>what building an automation looks like when you focus on the engineering<br>decisions and business logic instead of the shape of the agent’s reasoning.

You work with our harness. Our harness is what you’d expect: the turn<br>orchestrator, the model providers, the policy gate, the session store, the<br>sandbox. You describe the job. The agent runs it, in whatever shape the job<br>needs. Sometimes that shape is a loop. Sometimes it fans out and joins. The<br>difference is you are not designing the topology. You are working the<br>problem with the agent, in a session, against a real live system. The same<br>system that you can deploy later.

Every step of that session is contained inside what we call the engine. Every<br>function call the agent makes is a span on one trace. Every tool it touches<br>is a worker (aka service) in the open source catalog at<br>workers.iii.dev. The session chat is the design<br>conversation and the trace is the execution record, and they are all unified<br>over the same base system.

Importantly you get to keep this work long term. Most loops are designed to<br>be disposed of along with your token budget. In iii’s case, once your loop<br>works, you turn it into permanent workers and functions. The session showed<br>you the shape: these three calls in sequence, this fan-out, this check before<br>this write. That shape becomes reusable functions and triggers (aka events).<br>The loop the agent ran becomes a durable subscriber on a queue topic. The<br>fan-out becomes parallel function calls. The verification step becomes a<br>policy gate function. The one-off session becomes a permanent capability of<br>the system, made of the same primitives as everything else on the iii engine.

At no point in that workflow did “loop engineering” or “graph engineering”<br>appear as a discipline. The loop was how the agent happened to traverse the<br>problem. The graph is the reusable workers and functions it produced. Both<br>were inherent properties of the system. The work products are functions,<br>triggers, and workers, and those can be used long after the pattern that<br>discovered them is gone.

Why the disciplines keep multiplying everywhere else

The...