Agent Engineering

Loop Engineering: Build the Loop That Catches You

Prompt engineering asks what to say. Loop engineering asks how a system finishes the job — and, on its best days, how it convicts you.

The short version

For two years we learned to write better prompts. A prompt is a steering wheel. It is not a car.

Real work needs the rest: a goal you can check, a place to write things down, brakes, a thermometer, a mechanic, a grown-up who signs off, and a notebook so tomorrow starts smarter than today. That is a loop, and building one is engineering.

The part nobody writes about is the good part: a loop built properly will eventually tell you that you were wrong. Mine did that four times in one week. Those four stories are the evidence in this piece, and they cost more to earn than the diagram.

The treehouse

Your dad says: build a safe treehouse.

You do not shut your eyes, say one magic sentence, and wake up with a treehouse. You run a loop. What does "safe" mean? What wood do I have? Did the board fit? Does the ladder shake? What broke? Can my little brother climb it?

Now swap the nouns. Treehouse becomes software. Boards become code. Screws become API calls. The safety check becomes tests. Dad becomes human review. The notebook becomes memory. Mistakes become feedback.

An agent is not powerful because it answers once. It is powerful because it can try, look, judge, fix, and try again.

One-to-one map

That table is the whole architecture. Everything below is detail.

Why a prompt is not enough

A prompt can say fix this bug. A coding agent must read the issue, inspect the repo, find the files, form a hypothesis, edit, run tests, read the failures, patch again, re-run, summarise the evidence, open a pull request, and wait for review.

That is not one prompt. That is an operating system with a steering wheel attached.

The spine

User intent → Goal Contract → State Ledger → Planner → Tool Router
→ Policy Gate → Executor → Observer → Evaluator → Recovery
→ Human Gate → Memory → next loop or delivery

Goal Contract — the order ticket

A restaurant ticket says: table 7, chicken, no peanuts, medium spicy, twenty minutes. Without it the kitchen guesses.

Bad: fix the checkout problem. Good:

{
  "objective": "Fix timeout during checkout payment confirmation",
  "success_criteria": [
    "Payment confirmation completes under 3 seconds",
    "Existing payment tests pass",
    "No duplicate charges are created",
    "Pull request includes test evidence"
  ],
  "constraints": {
    "max_iterations": 8,
    "max_cost_usd": 10,
    "forbidden_actions": ["deploy_to_production"],
    "requires_human_approval": ["database_migration", "payment_logic_change"]
  }
}

Most agent systems do not fail because the model is stupid. They fail because the goal was vague. Vague goal, vague plan, random tool use, expensive chaos.

State Ledger — the whiteboard

Fixing a bike, you write down what you tried. The model is the brain; the ledger is the whiteboard. Do not ask the brain to also be the whiteboard — context degrades, tool output is noisy, and old reasoning goes stale.

Log every tool call with: status, iteration, current hypothesis, completed steps, open questions, last error.

Policy Gate — the brakes

A teenager can use a kitchen knife. A teenager should not use a chainsaw alone. The policy gate is the adult standing beside the chainsaw, and it must be code:

def policy_gate(tool, args, state):
    if tool == "process_refund":
        if not state.get("verified_customer_id"):
            return {"allowed": False, "next_action": "lookup_verified_customer"}
        if args["amount"] > 500:
            return {"allowed": False, "next_action": "escalate_to_human"}
    if tool == "deploy_to_production":
        return {"allowed": False, "next_action": "request_approval"}
    return {"allowed": True}

Prompt instructions are probabilistic. Gates are deterministic. If the action touches money, production, privacy, safety or legal exposure, probability is not good enough.

Evaluator — the thermometer

You do not guess whether chicken is cooked. Prefer deterministic checks — tests pass, schema validates, types check, the numbers add up — and use a model to judge only what genuinely needs judgement.

Never ask is this good? Ask which criteria passed, which failed, and what evidence supports the verdict? An evaluation that does not produce the next action is an opinion.

Recovery — the mechanic

Your chain falls off; you do not buy a new bike. Classify first, then act: transient failures retry with backoff, validation failures revise the input, permission failures request access, business-rule failures stop or escalate, and the same failure three times means change strategy.

Retry is not a strategy. It is a tool. A good agent does not try harder; it tries differently.

Stopping — control, not failure

You stop building when the frame is stable, the ladder is safe, and dad approves — not when you are tired. Define five stops before you run anything: success, failure, escalation, budget, safety. A loop that cannot stop is not autonomous. It is lost.

Human Gate — the responsible adult

Escalation is not the agent failing. It is how serious systems stay safe. But "need human help" is a useless escalation. A good one carries the decision required, the recommendation, the evidence, the risk, and the alternatives — and a human should be able to decide in under two minutes.

Memory — curated, never automatic

Bad memory compounds error; good memory compounds wisdom. So memory is proposed by the agent and approved by a human or a gate. Save only lessons that are specific, evidence-backed, reusable, and attached to a future action.

Four times the loop caught me

Here is the part I could not have written a year ago. These are from one week of building my own fleet, and each one is a case where the machinery I built told me I was wrong. That is the return on loop engineering — not speed, correction.

1. The gate's first conviction was its author

I added a new blocking rule to a validator, shipped it, and the build went red. Not because the rule was wrong — because I had added the rule to the code and not to the spec the code is checked against, and a parity test caught the drift. The first thing my new gate ever blocked was me.

Law: a validator that has never fired on its author is probably not checking anything.

2. The router that silently dropped every stem

I built a deterministic router that decides which of my repos a new article or repo would help. It looked correct and passed its tests. Then I ran it on four real sources and it routed one.

The cause was mine: the registry it reads documents its trigger words as substring matches and several are deliberate stems — self-improv, portfolio rebalanc. I had implemented whole-word matching, so a page describing "self-improving pipelines" matched nothing. The tests passed because I had written the tests to match my implementation, not the data.

Law: run it on real inputs before you believe your own green.

3. The grader refused my report card

Every delivery in my system gets a report card, scored by an independent grader. I submitted one and it came back 0.00 — capped for "significance unstated". I had described what I did and never said why it mattered or what number it moved.

Later the same grader gave a small change 1.00 and flagged it (sandbagged?) — telling me the bar I had set for myself was too low. Both verdicts were right and neither was flattering.

Law: if your evaluator cannot give you a bad grade, it is decoration.

4. The plan that could not explain its own goal

I built a critical-path router for a 360-day revenue plan. It computed the plan as comfortably feasible — finish in forty days against a ninety-day milestone — while actual revenue was zero.

The arithmetic was fine. The graph was the problem: not one node in it declared that it produces revenue. It was a dependency graph of repositories wearing a plan's clothes. That is now a blocking rule: if the target is measurable and nothing contributes to it, no route is served at all.

Law: a plan that cannot explain its own goal is a wish with a Gantt chart.

The twelve laws

1. No clear goal, no reliable agent. A vague goal creates a wandering loop.
2. State lives outside the model. The model thinks; the system remembers.
3. Tools need contracts. Purpose, inputs, outputs, boundaries, failure modes.
4. Critical rules need gates. Prompt guidance is not control.
5. Evaluation must produce evidence. No evidence, no trust.
6. Retry only retryable failures. Trying harder is not recovering smarter.
7. Stop conditions are architecture. A loop that cannot stop is a bug.
8. Memory must be curated. Bad memory compounds error.
9. Humans belong at high-leverage gates. That is responsibility, not weakness.
10. Observability creates trust. If you cannot inspect it, you cannot operate it.
11. More agents is not more intelligence. Coordination is the hard part.
12. The loop should compound. Every run should improve the next one.

And the thirteenth, which the four stories above bought: build the loop so it can convict you. A system that only ever validates its author is a mirror.

Thirty days, honestly labelled

Everything in this section is a target to aim at, not a result I am reporting. I have not run a controlled study; these are the bars I set for my own builds.

Week 1 — the minimum loop. Goal contract, state schema, tool-result schema, controller, one planner, two tools, one evaluator, an iteration cap. Aim: it finishes simple tasks without you touching it.

Week 2 — reliability. Error categories, an is_retryable flag, a recovery policy, repeated-error detection. Aim: it distinguishes transient from validation from permission from business-rule.

Week 3 — the brakes. Risk tiers, a policy gate in code, an approval packet, an audit log. Aim: every restricted call in your test suite is blocked.

Week 4 — compounding. Memory candidates, human review before anything becomes permanent, failure-mode tracking. Aim: the same failure stops recurring.

What this article does not claim

• No benchmark. I have not measured this architecture against an alternative. The four stories are incidents, not a study.
• The numbers above are targets. Where the original draft of this piece read like measured outcomes, that was a mistake — corrected here rather than quietly deleted.
• One fleet, one operator. Everything I have learned comes from my own repos and my own agent. Your failure modes will differ.

Sources

My own rule is: no source, no claim. An earlier draft of this article broke it — it demonstrated the rule with an uncited claim about the Tree-of-Thoughts paper, which is exactly the failure the rule exists to stop. So:

• Tree of Thoughts: Deliberate Problem Solving with Large Language Models, Yao et al., 2023 — arXiv:2305.10601. It reports a substantial margin over chain-of-thought on search-and-planning tasks. I have deliberately not reproduced the exact figures here, because I did not re-verify them at publish time.
• The four incidents are from my own repositories, in commit history, between 2026-08-05 and 2026-08-11.

The takeaway

Prompt engineering made AI useful. Loop engineering makes it dependable.

A prompt can produce an answer; a loop can produce work. A prompt can sound smart; a loop can be tested. A prompt can impress; a loop can compound.

Build the goal, the state, the tools, the gate, the evaluator, the recovery, the human, the memory. Then build the one thing most people skip: the part that is allowed to tell you that you were wrong.