Verification & Memory: the heart
A loop without verification is just automation that fails quietly. A loop without memory repeats every mistake. Get these two right and the rest is detail.
Who is allowed to say "done"?
This is the central design question of any loop. A loop doesn't fail loudly — it fails quietly, declaring success on half-finished work. The agent must not be able to satisfy the stop condition just by writing a confident summary.
Worse than nothing — it's a fast, confident way to ship work that's wrong. The verification is the gate the maker cannot fake. Everything else in loop engineering exists to feed that gate.
The abstract-to-verifiable bridge
The single highest-value move in loop engineering: turn a fuzzy intent into a measurable gate before you loop. You don't loop on a vibe — you loop on a number or a pass/fail.
becomes "move coverage from 16% to 95%."
becomes "write tests for invalid inputs, then make them pass."
becomes "write a test that reproduces it, then make it pass."
Each rewrite gives the agent a gate it can't talk its way past. Even non-technical goals can cross the bridge — "draft a reply to every unread email" verifies as "every unread thread has a draft, approved by the writing-voice and fact-check skills."
Two tiers: a judge and a gate
Durable loops verify in two layers, and autonomous work needs both:
Linters, type-checkers, tests, "site returns 200 and contains X." Reproducible and impossible to reason past. (This is why TypeScript beats JavaScript for agents — it encodes more rules to fail against.)
For what no test encodes — "does this actually solve the user's problem?" Scored approved/not-approved or 1–10. Handles intent; the deterministic gate handles correctness.
Self-critique is biased. Give the verifier a different context, ideally a different model. One team layered an LLM judge over deterministic checks because agents got "too ambitious" — refactoring unasked, disabling flaky tests. The judge compares the diff against the original request and vetoes a quarter of sessions; the agent course-corrects half of those.
Memory: the agent forgets, the repo doesn't
Each iteration wipes the conversation context. So durable knowledge has to live outside the model, in files — or the loop keeps hitting the same wall and burning tokens. No memory means no improvement.
A markdown run-log the loop reads at the top of each pass and updates at the bottom — plus git history and the test suite. That's the agent's entire persistent state. Anthropic's own guidance is literally "provide a place to write notes, as simple as a markdown file." Every fix or pattern the loop learns gets rolled into context for next time, so over dozens of passes it stops repeating mistakes.
A status file plus a folder of to-do / doing / done tickets isn't just bookkeeping — it is the loop's memory. That's what turns a loop that repeats into a loop that improves.
Check yourself
The heart of it — three questions.
Your loop keeps reporting "done" on work that's actually half-finished.
The root fix is…
The goal is "fix this bug," but the loop has no way to know when it's fixed.
Best move?
You want the loop to stop repeating the same mistake across iterations.
Where does its memory have to live?
You can verify and remember. The last lesson covers keeping a loop safe and cheap — guardrails — and how to build your first one today.