Loop, harness, factory

Three concepts stacked on top of each other. Most arguments about AI-driven development are really arguments about which of the three someone means.

The stack is small enough to be pedantic about: three words that get used interchangeably in conversations where the difference decides the answer.

Loop: One agent doing a single job on repeat: gather context, take an action, check the result, go again until some condition is met. The smallest unit of agentic work — and everything above it is loops stacked on loops.
Harness: The walls around that loop: the sandbox it runs in, the tools it can reach, the memory that survives between runs, and the gates that decide what "done" means. The loop is the behaviour; the harness is the environment the behaviour happens inside.
Factory: Many harnessed loops running at once, fed by a queue of work and drained through a review gate into production, with people owning the whole arrangement from above. Not a bigger agent — an org chart made of loops.

The shift the first one asks of you is easy to state and hard to do: you stop prompting the agent turn by turn and start designing the small system that prompts it for you. The second is where most of the difference between teams actually lives — a raw model with no harness will happily spin forever, and it will look busy the entire time. The third is where the lights are, which is the subject of everything that follows.

Stated that way the progression sounds like a scaling story — more loops, more throughput. The real change is where you stand: each layer moves the work you personally do further from the diff. At the loop layer you are designing a procedure. At the harness layer you are designing an environment. At the factory layer you are designing an organisation, and your leverage is almost entirely in where you put the gates.

The factory as a closed loop

Draw the thing honestly and it closes on itself. Intent (from leadership, from engineers) and signals (from incidents, from users, from monitoring) feed a queue. A harness picks up an item and builds a change. Automated checks run: CI, tests, static analysis, scanning, at a scale and frequency that costs essentially nothing. Deploy ships it. Monitoring turns production back into signals, and the queue fills again.

machine step · cheap, green, repeatable human judgment · the one box that resists scaling

Fig. 1.1Almost every box costs nothing to run more often. The argument about speed lives entirely in the one that doesn't.

Now look at what each box costs to run one more time. Queueing another item: nothing. Building another change: cheap and getting cheaper. Running the checks again: nothing. Deploying again: nothing, if you have done the boring work. Every box in the diagram is close enough to free that the marginal cost rounds away.

Every box but one.

The review gate is judgment, and judgment is a person’s attention. It does not get cheaper when you buy more of it, it does not parallelise past the number of people you have, and it degrades when you push it — the twentieth diff of the day is not read the way the first one was. This is the entire argument about speed, and it lives in one box.

Which means the interesting question was never “how much code can this thing produce”. It is “what happens at the gate”, and every serious disagreement in this field turns out to be a disagreement about that.

From the floor

The three layers are not abstractions here; they are files. The factory that built this site is a Claude Code plugin, and it decomposes exactly as described.

The loop is one skill, site-loop: build the pages, run the floor, capture screenshots, submit them to judges, apply the ranked findings, repeat. The harness is everything that loop is allowed to touch — a Commands table in each generated repository that worker agents read instead of hard-coding build tools, two stack templates, and eleven craft-knowledge documents that hold the accumulated taste of about twenty-five hand-built sites. The factory is five gated stages, three of which stop and wait for a person.

What the decomposition bought was not speed. It was being able to say where a failure happened: a run that goes wrong goes wrong at a named stage, in a named loop, against a named gate, which beats “the agent did something odd”.

What it does not buy is any guarantee that a stage catches its own mistakes. On one run the brief claimed a count that contradicted the inventory printed three paragraphs below it in the same document. The brief gate did not notice, because a person approving a brief reads it for intent, not for arithmetic. It surfaced two stages later, during the build loop, by which point pages had already been written against the wrong number. Cheap to fix, and a fair illustration of the limit: naming your stages tells you where a defect was found, not where it was made.

Evidence: website-factory/specs/retro/2026-07-23.md, § “Singletons worth watching”

Why the vocabulary matters

Someone says “we’re building an agent”. Ask which layer. If they mean a loop, the next question is what its condition for stopping is. If they mean a harness, the next question is what it can reach and what it cannot. If they mean a factory, the next question is who reads the output — and every station after this one is about that question.