The first post in this series argued the harness beats the model. The second mapped the tools. This one is the hands-on part: once you've got a harness, how do you make it reliable?
The answer got a name in June 2026 — loop engineering — from a single idea that reorganized how people talk about working with AI: stop hand-prompting your agent for every task, and start designing the loop that prompts it for you. You're no longer writing instructions. You're building the machine that writes them. Here's what that machine is made of.
Instruction files: the checklist, not the manual
Every serious harness reads a project instruction file each session — CLAUDE.md, AGENTS.md, or similar. It's the single highest-leverage thing you control, and almost everyone gets it wrong the same way: they write a novel.
The teams who get reliability treat it like a pilot's pre-flight checklist. Two rules:
- Keep it short — under about 60 lines. Every line competes for the model's attention; a bloated file dilutes the rules that matter.
- Earn every rule. Don't add rules speculatively. Add them when a real failure demands it.
# AGENTS.md
- Run `pnpm test` before calling any change done. No exceptions.
- Never edit files under /generated — they're built, not authored.
- API responses are snake_case; the frontend is camelCase. Map at the boundary.
- If a migration is needed, stop and ask. Never auto-migrate.
Every one of those lines is a scar. Which brings us to the pattern that produces them.
The ratchet: mistakes become permanent
The ratchet is the discipline that separates a harness that gets better over time from one that repeats itself forever. The rule: treat every agent mistake as permanent signal.
The agent deletes a file it shouldn't have. The junior move is to fix it and move on. The loop-engineering move is to ask how does this never happen again — then encode the answer, either as a line in the instruction file or, better, as an enforced hook. A ratchet only turns one way. Each turn, the space of possible mistakes gets smaller.
flowchart LR A[Agent makes a mistake] --> B[Fix it] B --> C[Encode a rule<br/>instruction file or hook] C --> D[That class of mistake<br/>can't recur] D --> A
Hooks: enforcement the model can't skip
Instructions are advice; the model can ignore advice. Hooks are enforcement — deterministic code that fires at fixed points in the loop, before or after an action, that the model cannot route around.
A PreToolUse hook can block a dangerous command before it runs. A PostToolUse hook can run your test suite after every edit and feed failures straight back into the loop. The design principle that makes this cheap: success is silent, failures are verbose. A hook that passes says nothing; only failures surface. So the feedback loop costs almost nothing in the common case and screams exactly when it should.
# PreToolUse hook — refuse a destructive command
if echo "$COMMAND" | grep -qE 'rm -rf|DROP TABLE|force push'; then
echo "Blocked: destructive command requires human approval." >&2
exit 1
fi
Context management: keep the agent from forgetting the goal
Long tasks generate mountains of text — file contents, command output, error logs. Left alone, that floods the model's context window and the agent starts forgetting what it was doing. Three techniques handle it, and mature harnesses do them for you:
- Compaction — summarize old history when the window fills, keeping the gist and dropping the transcript.
- Offloading — keep big outputs (a 5,000-line log) out of context, and let the agent fetch only the part it needs.
- Progressive disclosure — reveal a tool or skill only at the moment it becomes relevant, instead of describing all fifty up front.
For long-horizon work, teams add planning files that decompose a big goal into an ordered checklist the agent works through — so the plan lives on disk, not in fragile short-term memory.
Planner and evaluator: don't let the agent grade itself
The most reliable single upgrade to a loop is also the least intuitive: split the do-er from the checker.
Agents are optimists. Ask one to both write code and judge whether it's correct and it will grade its own homework generously — every time. Put a separate agent (or a separate pass with a different prompt) in charge of evaluation and quality jumps, because the evaluator has no ego investment in the work being done. Planner proposes, worker executes, evaluator judges. Three roles, not one hero.
Putting it together
None of these patterns is exotic. Together they're the difference between a demo and a dependable system:
- A short instruction file that reads like a checklist.
- A ratchet that turns every mistake into a permanent rule.
- Hooks that enforce what instructions only suggest.
- Context management so the agent never loses the plot.
- A planner/evaluator split so nobody grades their own work.
That's loop engineering. You're not chasing a smarter model — you're building a loop that makes the model you already have reliable. A whole category, harness-as-a-service, is now forming to sell exactly this as pre-built machinery. But the patterns are learnable, and once you have them, they transfer to whatever harness you use.
Part three of our series on the AI harness era. Next: a close look at Pi — the minimal harness betting that primitives beat features.
