The practical guide to designing AI loops that stop only when a real check passes.
The guide is long because the edge cases matter. Your first pass only needs these five decisions.
Use it like a workshop. Pick one real workflow, choose the loop shape, fill the canvas, then run the smallest safe version.
Skim the use cases, choose a loop shape, and decide if your task qualifies.
Fill the loop canvas and pick the verifier rung. Stop before building tools.
Run the build track, record failures, add rules, then decide whether to schedule it.
Use loop engineering when AI is allowed to do work, but only trusted after an external check passes. The loop can run once for a single task, or it can run repeatedly from a trigger.
You trigger it once. The agent may still loop internally: act, check, fix, rerun. It stops when the check passes or the retry limit is hit.
Fix this failing test.
Loop until the test passes.
Stop after 3 attempts or if the fix touches auth.A schedule, webhook, queue, inbox item, or new file starts the same task loop again. The trigger repeats. The proof gate stays the same.
Every weekday at 8:00:
Read new replies.
Draft follow-ups.
Send nothing until the voice gate passes and I approve.Run tests, patch one failure, rerun, stop at green or handoff.
Collect sources, reject dead links, keep only items that match criteria.
Draft, validate banned phrases, score, revise until the threshold passes.
Normalize rows, validate schema, quarantine records that fail checks.
Inspect logs, classify incidents, propose action, escalate on risky cases.
Create page, wire registry, check routes, build, then stop.
The best agent systems start simple. A single prompt is enough until the work needs memory, tools, branching, evaluation, or a recurring trigger.
The work has fixed steps, like outline, draft, edit, publish.
Inputs arrive in categories, like support, sales, finance, or urgent.
Quality improves when a separate check gives feedback and asks for revision.
The agent must search, read, write, calculate, update a CRM, or inspect a system.
The agent can prepare work, but a person must approve the final action.
The same loop should run from a calendar, inbox, webhook, queue, or file drop.
Trigger: What starts the loop?
Goal: What should be true when it finishes?
Context: What does it need to read first?
Tools: What is it allowed to do?
Check: What outside signal proves it worked?
State: Where does it record what happened?
Fail path: What changes before the next attempt?
Stop: When does it stop or ask a human?This is the one-page version. If you cannot fill every box, the loop is not ready for tools, scheduling, or autonomy.
What starts it? Manual click, schedule, webhook, inbox, file, or queue.
What should be true when the loop finishes?
What must the agent read before acting?
What is it allowed to change, draft, update, or send?
What external signal rejects bad work?
What changes before the next attempt?
Where does it record decisions, failures, and lessons?
Which cases must pause for approval?
When does it stop because it passed, failed, or timed out?
Loop name:
Owner:
Trigger:
Goal:
Context:
Allowed actions:
Verifier:
Retry rule:
State file or log:
Human gate:
Stop condition:
Rollback or recovery path:Replace the bracketed parts with your tools, data, and approval rules. These work in no-code automations, Claude projects, Zapier agents, custom scripts, or a human-run checklist.
Trigger: New reply or manual review.
Goal: Produce one accurate next message.
Context: Thread history, CRM notes, offer, last promise made.
Action: Draft the reply and identify the next step.
Check: Facts match the thread, tone fits the relationship, no unsupported promise.
Retry: Revise once using the failed check.
Human gate: Always approve before sending.
Stop: Approved draft queued or escalated to owner.Trigger: New research question.
Goal: Produce a short brief with evidence.
Context: Question, date range, allowed sources, disallowed sources.
Action: Search, collect sources, summarize claims.
Check: Every important claim has a live source and source date.
Retry: Replace weak links and remove unsupported claims.
Human gate: Required before using the brief in public or paid work.
Stop: Brief saved with source list and open questions.Trigger: New support ticket.
Goal: Classify the ticket and prepare the safest next action.
Context: Customer record, product docs, refund policy, previous tickets.
Action: Classify, draft reply, suggest account action.
Check: Category is valid, policy is cited, risky actions are flagged.
Retry: Reclassify if policy or customer status does not match.
Human gate: Refunds, angry customers, legal language, or account changes.
Stop: Reply queued, ticket routed, or human escalation created.Trigger: Draft ready for review.
Goal: Produce a publish-ready draft.
Context: Source notes, audience, voice rules, banned phrases, target format.
Action: Edit the draft.
Check: Validator passes and quality score clears the threshold.
Retry: Fix only the failed criteria. Preserve sections that already pass.
Human gate: Final taste, claims, and offer positioning.
Stop: Draft queued with validation results.Trigger: Draft or research brief is ready.
Goal: Make every factual claim defensible.
Context: Draft, source list, date range, allowed sources.
Action: Extract every factual or trend claim.
Check: Each claim has evidence strength: strong / medium / weak / missing.
Retry: Cite, narrow, qualify, or remove weak and missing claims.
Human gate: Required before public or paid use.
Stop: Every claim is sourced, personal, or narrowed enough to defend.Trigger: New email, receipt, document, or reminder.
Goal: Decide archive, reply, task, calendar, or escalation.
Context: Inbox item, calendar, existing task list, preferences.
Action: Extract needed action and draft the next step.
Check: Date, person, amount, and commitment are present when needed.
Retry: Ask for missing information or mark as unclear.
Human gate: Money movement, contracts, medical, travel purchase, or sensitive reply.
Stop: Item archived, task created, event drafted, or human review requested.Write the loop in one sentence: When X happens, AI does Y, checks Z, and stops when Q is true.
Look at the canvas and mark the weakest box. Most failed loops have weak context, weak verifier, or missing stop condition.
Before scheduling anything, run the loop manually with the agent and record every place you had to intervene.
A useful AI loop has a goal, the context it needs, an action it takes, a check on whether the action worked, and a retry rule if it failed.
What result should exist?
What must the agent read first?
What does it do?
What proves it worked?
What changes before the next attempt?
The verifier passed or the human gate approved.
What result should exist?
What must the agent read first?
What does it do?
What proves it worked?
What changes before the next attempt?
Goal: [specific output]
Context: [files, data, rules, examples]
Action: [what the agent does]
Verifier: [lowest check that proves the output is valid]
Retry: [max attempts + what changes each retry]
Stop: [time, spend, attempt, or human gate]Most tasks do not deserve automation. A loop earns its setup cost when the work needs iteration until proof passes, or when the same proven loop should rerun from a schedule, webhook, inbox, or new file.
Runs once, but may cycle through action, check, and retry several times before it stops.
Runs the same task loop again when time, an event, or a queue item triggers it.
The task can run once, but the agent may need several attempts before the verifier passes.
Manual click, schedule, webhook, inbox item, or file drop. No hidden always-on behavior.
A test, build, linter, link check, schema check, or fixed rule can reject bad output.
The agent can read the system, run the code, inspect logs, or touch the workflow it should improve.
Attempts, time, spend, token budget, or human review stops the loop before it wanders.
Verifiers sit on a ladder from dumb and certain to smart and arguable. Your goal is to stay as low as the task allows.
Use this when the loop's first promise is simple: create a report, export a CSV, write a summary file, produce an invoice, save a screenshot.
test -s deliverables/report.htmlThis does not prove quality. It proves existence. That is still better than accepting the agent's word.
The first loop automates work. The outer loops make it reliable, always-on, and able to improve from its own traces.
Model calls tools until the task is complete.
A grader or rule checks output and sends failures back for retry.
A manual click, schedule, webhook, Slack message, or new file triggers the task loop.
Traces from production runs improve the prompt, tools, rubric, or context pack.
Start with a pattern before you invent a custom system. Most useful loops are one of these shapes with different tools attached.
Classify the request, gather account context, draft a reply, escalate refunds or angry customers.
Read the thread, draft the next message, check voice and accuracy, queue for approval.
Collect sources, reject weak links, summarize only claims backed by evidence.
Draft, run a validator or rubric, revise until the score clears the line.
Normalize rows, check required fields, quarantine anything the schema rejects.
Run the failing proof, patch one cause, rerun, stop at green or hand off.
Best for content and knowledge work where quality is graded. The score must clear a hard line before output moves forward.
Best for code, security, data integrity, and anything where one failure should block shipping.
A proof contract turns vague acceptance criteria into checks the loop can run and artifacts a reviewer can inspect.
Intent: Add a new gated resource page.
Acceptance criteria:
1. Landing page and access page exist.
2. Email capture accepts the new resource slug.
3. Resource appears in navigation, sitemap, OG preview, and outreach manifest.
4. TypeScript and production build pass.
Proof mode:
1. File existence check.
2. Unit test for resource slug and email subject.
3. Static route and registry inspection.
4. tsc plus npm run build.
Evidence:
- Changed file list.
- Passing test output.
- Build output.
Review:
- Separate reviewer checks one criterion at a time.
- Verdict is PROVEN, NOT_PROVEN, or INCONCLUSIVE.
Outcome:
- Ship only when every criterion is PROVEN.Known input, known steps, known check, clear stop condition. Start here.
Each morning:
1. Read inbox notes
2. Extract tasks
3. Rank by deadline and value
4. Verify every task has an owner and next action
5. Stop after one daily plan is writtenBroad goal, fuzzy finish line, lots of exploration. Useful, but expensive and harder to trust.
Bad: Research the market until you find something interesting.
Better: Find 10 recent examples, discard dead links,
score each against 5 criteria, and stop.A self-running system can produce more than you can read. That feels productive until you approve work you no longer understand.
Review a random sample from every loop run, even when the gate passes.
Keep the verifier rules in a human-owned file the agent cannot quietly rewrite.
Set max attempts, time, spend, or tokens before the loop starts.
Write restart, replay, and rollback instructions before the first unattended run.
Loop name:
Owner:
What it may change:
What it may never change:
Max attempts:
Max spend:
Verifier:
Human gate trigger:
Rollback path:
Last spot-check date:Tomorrow's run restarts from zero. Keep a markdown file, issue, board, or database row with last run, failures, lessons, and next action.
The agent that wrote the output is too generous reviewing it. Use a fixed rule, separate verifier, or human gate for anything important.
The loop says done before the work is done. Soft completion words are not gates. Use a test, build, type check, file check, or substance check.
A loop tested read-only gets one write permission for convenience, then never gets re-audited. Review tools, secrets, and write access on a schedule.
Loop name:
Last run:
What changed:
What passed:
What failed:
Human review needed:
Next run should:
Lessons added:Pick one repeated task with a clear output.
Write the loop skeleton: goal, context, action, check, retry, stop.
Choose the lowest verifier rung and write the exact check.
Add the context pack: files, examples, rules, and source data.
Run once with a human gate. Record every failure.
Turn the failures into rules, tests, or checklist items.
Run again with a cost cap and spot-check the output.
Loop engineering does not replace the rest of the system. It sits between context, agents, memory, and review. Use these resources when the playbook points at a missing layer.
Embed this before the loop. It covers CLAUDE.md, memory, MCP, skills, hooks, and progressive disclosure. A loop with weak context just repeats weak work faster.
Open guideEmbed this inside the loop when the work needs a repeatable cadence: Plan, Work, Review, Triage, Learn. It is the operating rhythm for complex AI work.
Get skillStart from the Daily Overview template. It is already a scheduled monitor over calendar, email, pipeline, and priorities.
Open resourceStart from the AI Chief of Staff template. It turns metrics, meetings, decisions, and follow-ups into a reviewable cadence.
Open resourceUse this when the loop needs a named agent, tools, and a small job description instead of a checklist.
Open resourceWatch the Second Brain demo when you need to see memory, routing, agents, and workflows working together.
Open resourceUse this when you need the practical substrate: files, terminal, agents, skills, hooks, MCP, and repeatable project workflows.
Open tutorialStudy a real binary gate in code: PROVEN, NOT_PROVEN, or INCONCLUSIVE, backed by artifacts. Use this only if your loop is technical enough to need code-level proof.
Open GitHubThe playbook gives you the loop discipline. Second Brain 2.0 gives you the configured repo, memory layer, specialist agents, and tool setup to run it every day.
The complete Claude Code system. 30+ agents, memory that compounds, pre-configured MCPs.
DIY $197 / Kickstart $597 / DWY $2,497
See PackagesThe memory layer your loop writes lessons into. Patterns persist and recall across future sessions.
Free / Standard $199/yr / Pro $349/yr
Get MemoryOS