Loop Engineering Fundamentals: The Repeat is the Product

An AI agent can do a task once and still be a bad system. Loop engineering begins when you design what makes it run again, what it observes, and what tells it to stop.

The agent did exactly what I asked. That was the problem.

An agent updated a set of installation instructions after a dependency release, left a clean result, and stopped. The patch was correct. Then another release made the same guidance stale, and I was back at the keyboard writing another prompt.

The agent could do the task. I was still the machinery that noticed the task, decided it was time, supplied the context, checked the result, and asked for the next pass.

I had automated the work, but not the repeat.

That distinction is the starting point for loop engineering. A capable agent can complete one run. A loop decides when another run should exist, what it should inherit, how its result is judged, and whether the system should continue at all.

The prompt is not the product anymore. The repeat is the product.

First, separate the loop from the harness

I wrote Harness Engineering Fundamentals around one dangerous moment: the seam where an agent’s intent becomes a real action. The harness sits at that seam. It governs one run by controlling context, tools, permissions, evidence, and consequences.

Loop engineering works one level higher.

The harness asks: may this run take this action?
The loop asks: should there be another run?

You need both. A loop without a harness repeats risk at machine speed. A harness without a loop gives you a well-governed task that still waits for a person to start it again.

The simplest way I now think about it is:

A harness governs the step. A loop governs the next step.

Harness engineering and Loop Engineering shown as two stacked control layers. The harness governs one run by controlling context, tools, permissions, evidence, and consequences. The loop governs recurrence through the goal, trigger, record, breaker, and human handoff. Together they create bounded repetition.

A loop is not `while True`

The first bad mental model is an infinite cycle around an agent:

while True:
    agent.run()

That is recurrence, but it is not engineering. It has no owned outcome, no fresh observation, no independent check, no durable record, and no reason to stop. It is just a tire spinning off the car.

A useful loop has six parts:

The six-part Loop Engineering contract. A measurable goal admits work; a trigger starts an iteration; a maker produces a candidate; a checker tests it independently; a record preserves the result and state; and a breaker decides repeat, stop, or hand back to a human. The harness runs underneath every stage.

1. Goal: what outcome owns the loop?

The loop needs a measurable reason to exist. “Improve the documentation” is not enough. “Keep installation instructions aligned with the latest released CLI” is closer: it names the object, the condition, and the boundary.

A good goal tells the loop what work it may admit. Without one, every new signal looks important and the loop slowly becomes a general-purpose agent with permission to wander.

2. Trigger: what earns another iteration?

A timer is one kind of trigger, but not the only one.

A schedule: every morning at 7.
A change: a new release was published.
A threshold: test coverage fell below the floor.
A queue: a new item is ready and unclaimed.
A human decision: the pending approval was granted.

The trigger should be evidence that the world changed, not merely evidence that time passed. If nothing changed, “do nothing” can be the correct iteration.

3. Maker: who produces the candidate?

The maker is the agent, worker, or deterministic job that attempts the work. It should receive a bounded task, the minimum useful context, and a clear output shape.

This is where most agent demos begin. In a real loop, it is only one box.

4. Checker: what proves the candidate is good?

The checker is independent of the maker’s confidence. It may be tests, policy rules, a rubric, a second agent, or a human approval. Often it is several of those, ordered from cheapest to most expensive.

The maker can explain why it thinks it succeeded. The checker decides whether that explanation survives contact with evidence.

5. Record: what does the next iteration inherit?

The record is the durable truth of the loop: what ran, what changed, what passed, what failed, what it cost, and what state comes next.

Chat history is not enough. A future run needs inspectable state it can resume without trusting a polished summary of the previous run.

6. Breaker and handoff: why does it stop?

Every loop needs a budget and an exit.

Maximum iterations
Maximum cost
Maximum wall-clock time
No score improvement
Repeated failure
An action that requires a person

The breaker is not an emergency feature you add later. It is part of the loop’s definition. If you cannot say why the loop stops, you have not finished designing it.

A concrete first loop

Suppose you want an agent to keep a project’s dependency guidance current.

The weak version is a weekly prompt: “Check whether our dependency documentation is stale and update it.”

The engineered version is:

Part	Design
Goal	Released dependency guidance matches the versions the project actually supports.
Trigger	A dependency manifest changes or a new release tag lands.
Maker	Prepare a documentation patch with source links and version evidence.
Checker	Build docs, verify links, compare claims with manifests, then request review.
Record	Store the event, diff, checks, sources, cost, and current disposition.
Breaker + handoff	One patch attempt; conflicting sources or a breaking recommendation goes to a maintainer.

Notice what disappeared: “run every Friday because Friday.” The trigger is now attached to a reason. The agent can also conclude that no patch is needed and record that outcome honestly.

That is a loop doing less work because it is better designed.

A practical first-loop blueprint for dependency guidance. A manifest change or release tag triggers one bounded documentation patch. Build, link, source, and version checks verify it. The loop then records no change, proposes a reviewed patch, or hands conflicting evidence to a maintainer.

Three questions before you automate the repeat

What new fact justifies another pass?

If the answer is only “the cron fired,” you may be building noise. Name the signal the loop is waiting for.

What can the maker never approve about its own work?

An agent should not be the sole author and sole judge of a consequential output. Decide where independent evidence enters.

What state must survive a fresh process?

Imagine the worker dies immediately after taking an action. Can the next worker tell whether the action happened? Can it safely retry? If not, the loop is not ready to run unattended.

Start smaller than your ambition

The temptation is to begin with a grand self-improving loop that researches, builds, evaluates, learns, and ships. I would not start there.

Start with one recurring pain that already has a human routine:

Write the goal in one measurable sentence.
Name the real trigger.
Give the maker one bounded output.
Reuse an existing check.
Store one durable receipt.
Set one hard stop and one human handoff.

Then run it in observation mode. Let it propose without acting. Read the receipts. Find the places where your definition was vague. Tighten those before you give it more reach.

Loop engineering is not the art of making an agent run forever. It is the discipline of making repetition deserved, bounded, and useful.

The agent doing the work is the visible part. The system deciding whether the work should happen again is where the engineering begins.

Next in the series: Maker, Checker, Breaker - why autonomy becomes safer when doing, judging, and stopping are three different jobs.