Which Loop Do You Need? A Field Guide to Loop Engineering

It is Tuesday, a little after ten. You have five AI chats open.

One is drafting the investor update. One is chasing a bug your best customer hit on Friday. One is halfway through a feature you scoped on Sunday night. One is redesigning the pricing page. One is meant to be clearing the support backlog, and it has stopped, and it is waiting to ask you something.

Every one of them is good. Every one of them is faster than the person who used to do that job. And every one of them is waiting on you, because you are the part that reads the work, decides whether it is good enough, and says what happens next.

You are the loop.

Part 1 of this series named the discipline: the unit of work is no longer the prompt, it is the loop, and the craft is the stopping rule, how the work knows it is done, wrong, or stuck. This post is the field manual. Six jobs you already hand to AI, and the specific loop each one needs so it can finish without you sitting in the middle of it.

A loop is a task plus a check

Strip away the vocabulary and a loop is two things: a task, and a check on the task. An agent does the work. Something else decides whether the work is good enough to stop, wrong enough to try again, or stuck enough to call you. That something is the check, and everything hard about loop engineering lives in it.

Here is the line to keep. A task without a check is just hope. When you hand a chat a job and read whatever comes back, you are the check. That works while you have the attention to read every word. It stops working the moment you have five jobs running and the bandwidth to properly read none of them. The entire point of a loop is to move the check off you and into the system, so the work can run and finish while your attention is somewhere else.

So the real question, every time you delegate, is not “which AI.” It is: what is the check, and who or what performs it. The rest of this guide is six answers to that question, drawn from the jobs you are already handing out.

Six jobs you already delegate, and the loop each one wants

You do not need new work to try this. You are already delegating all six of these. What is usually missing is not a better model. It is the check. Here is the loop each job is quietly asking for.

1. Write the investor update

You ask AI for the monthly note to investors. It comes back clean, confident, well structured. You ask, is this good? It says yes, and tightens a sentence. You ask again. It says yes again. It will always say yes. The writer is the worst possible judge of its own writing.

The loop this job wants is an evaluator-optimizer: one agent writes, a second agent grades the draft against written criteria, the writer revises, and the cycle repeats until the grader is satisfied. The criteria are the part that matters. Not “make it good.” Write down what good means for an investor update: leads with the number that changed, no hedging, every claim carries a source, under four hundred words. A rubric the grader can actually hold the draft against.

The failure mode to watch is the one you just saw. Ask the writer whether its own work is good and the answer is always yes. Addy Osmani calls it being “too nice grading its own homework.” The fix is not a cleverer prompt. It is a separate grader, ideally one that never watched the draft get written, holding it to a standard you wrote down in advance.

2. Fix this bug

Your best customer hit an error on Friday. You hand it over: find it, fix it. This is the easy case, and it is worth understanding why it is easy, because it is the model for every job you wish you could delegate this cleanly.

A bug has a fact of the matter. Either the error still happens or it does not. That gives the loop a check it cannot argue with: reproduce the failure, make the change, run it again, and the test passes or it does not. The agent runs until the check goes green, then stops. This is the goal-met loop, the simplest pattern in the book, and the name is the whole design: the goal is the stop. No taste, no opinion, no “looks good to me.” Anthropic put it plainly: coding is the domain where agents first genuinely worked, precisely because the solutions are verifiable. A test is not a reviewer you can charm. Geoffrey Huntley calls a test suite “back pressure,” the thing that pushes back on a bad answer without being talked out of it.

The failure mode here is quieter than it looks: an agent that satisfies the letter of the check without the spirit of it. Told to make the test pass, it can sometimes make the test pass and nothing else, a placeholder that goes green and does no real work. The guard is to point the check at the real outcome, the customer’s actual failure gone, not a proxy that is easy to game.

3. Build this feature

Bigger than a bug. You scoped something over the weekend and you want it built, not just sketched. The mistake here is treating it as one big ask. The loop this job wants has three stages, each with its own check: plan it, build it, review it, and do not let the same agent be the only judge at any stage.

The move that earns its keep is the review, and specifically who does it. Have a different model review the work, not the one that built it. Not because the builder is bad, but because every model has blind spots baked in by how it was trained, and a model reviewing its own output shares every one of them. A different model, from a different family, fails in different places. Where the two disagree is exactly where the bugs live. This is the single design choice behind our own build tooling, and Part 1 walked through what it caught on a real release.

The failure mode is the reviewer that never says stop. A critic paid to find problems will always find another problem, so if the only stop condition is the critic running out of objections, the loop runs forever. The check needs a bar it can clear: no showstoppers, no objection to the approach itself, ship. Polish is a separate, later pass, not a reason to keep the plan open.

4. Redesign the website

You want the homepage to look better. You hand it over and get back three versions, all competent, none obviously right. This job is different in kind from the bug, and the difference is the whole lesson: there is no test for “better.” Taste has no green checkmark.

When there is no fact of the matter, you widen the check instead of sharpening it. Run the work a few times and have a panel judge it, several independent looks rather than one, because a single aesthetic opinion from a single model is noisy. But the panel advises. It does not decide. On anything driven by taste, brand, or feel, your judgment keeps the veto. The loop’s job is to bring you three strong options and the reasons behind each, not to pick for you.

The failure mode is pretending taste is mechanical. The moment you let a model’s confident score stand in for your own eye on something that is genuinely a matter of judgment, you have automated the one part of this job you should never have handed off. Use the panel to narrow the field. Keep the final call.

5. Clean up the whole backlog

Not one task. A pile. The support tickets nobody triaged, the forty stale items in the tracker, the inbox of small decisions. The instinct is to hand them over one at a time. The better move is to point a loop at the whole pile and let it drain.

This is a loop-until-dry: the loop pulls the next item off the list, handles it, marks it done, pulls the next, and keeps going until the list is empty. The list itself lives outside the agent, in your tracker or a file, so the loop always knows what is left and never loses its place if it stops and restarts.

The failure mode is a queue that never empties, because the loop creates more work than it closes: every ticket it touches spawns two follow-ups, and the pile grows while it runs. The guard is a stopping rule that is not only “empty,” but “empty, or N items done, whichever comes first,” plus a way to avoid handling the same item twice. A loop that drains a backlog is one of the highest-leverage things you can point at a Monday. It is also the one most likely to quietly run up a bill, which brings us to the last job.

6. Keep it running without me

The most valuable loop is the one you never start, because it starts itself. The morning triage that has already sorted your inbox before you sit down. The weekly summary that is written by the time you want it. Work that happens on a schedule, on infrastructure’s time, not on your attention.

This is a time-recurring loop: it fires on a schedule and never really “finishes,” it just runs again tomorrow. It is the newest and most powerful shape, and the most dangerous, for one reason. Every other loop in this guide runs because you kicked it off and stops when the work is done. This one runs whether or not there was anything worth doing, and it spends money every time.

So the non-negotiable is a hard budget. A cap on how much it can spend or how long it can run before it stops and reports back, every single time. A recurring loop with no ceiling is not an assistant. It is a standing order to spend money you are not watching. Give it a budget, tell it to surface only what actually needs you, and it becomes the closest thing to real leverage you will find: your judgment, applied on a schedule, without your presence.

The three decisions that dominate everything

Six jobs, six loops. Underneath all of them are three decisions that determine whether any loop you build is trustworthy or merely plausible. Get these right and the specific pattern almost picks itself.

This is the decision that separates a loop you can walk away from from a loop making mistakes unattended. Push the check toward hard ground truth wherever it exists: a test, a number, a fact that is true or false without an opinion.

Where it does not exist, and for a lot of real work it does not, do not settle for one model checking itself. Diversify the checker: a different model, a small panel, your own eye at the end.

The weakest possible check is the agent that did the work grading the work, and the research is blunt about why. Left to self-correct with no outside signal, models often do not improve and sometimes get worse, talking themselves out of a right answer as readily as into one.

Picture a three-day project. A few people, a few agents, work spread from Tuesday to Thursday. Everyone closes their laptops on Tuesday night. On Wednesday morning, does the work survive?

It survives only if the state lives somewhere durable: files, a shared document, a tracker, the project board. Not in a chat window that one person has to keep open. The thing practitioners keep relearning is that the agent forgets and the record does not, so the record has to be the real memory. Anything that runs longer than a single sitting needs its state on disk, not in a conversation.

Every loop needs a budget behind its goal: run until the work is done, but never past N rounds or N dollars. And you have to decide, in advance, what happens when the budget runs out before the goal is met. Does it ship what it has, or does it stop and escalate to a human?

That choice is not a technicality. For anything low-stakes, shipping partial is fine. For anything that touches a customer, a client, or money, the answer is always escalate, never force-ship. Decide it before you start the loop, not in the moment it breaks.

The verification ladder

The first of those decisions, the check, deserves its own picture, because “diversify the checker” is really a ladder you climb only as far as the risk demands.

At the bottom rung, the agent checks its own work. Cheapest, weakest, and fine for throwaway tasks. One rung up, a fresh copy of the same model reviews with no memory of having written the thing, which strips out the reflexive self-flattery but keeps the shared blind spots. Up again, a different model from a different family reviews, and now you are catching errors that one model’s training cannot see. Higher still, a deterministic check, a test or a number that cannot be charmed at all. At the top, all of it stacked together with a human at the final gate.

You do not climb the whole ladder every time. That would be slow and expensive. You climb as far as the stakes require. A first draft of an internal note: self-check is fine. A number going to your board, a change touching a customer’s data, a claim going out under your name: climb higher. The rule is simple. Spend your verification where the risk is judgment-shaped, and do not waste it where a cheap check already tells the truth.

One story from our own build, because it changed how I think about this. We have a loop that grades a spec before any work starts, then hands the spec back to be improved, then grades it again. On one spec, the grader scored the improved draft an 18. The next pass, a 58. The pass after that, a 70. And it still refused to pass it. My first instinct was that the grader was broken, stuck, too harsh. It was not. Each refusal was pointing at a real hole in the spec that the higher score had papered over. The number was climbing and the work genuinely was not done. A grader that keeps saying no while the work is unfinished is not a bug. It is the entire reason the loop is worth trusting. A grader that says yes to be agreeable is worth nothing at all.

Where AIOS fits

AIOS is an open-source AI transformation toolkit. It has three parts. The first is a personal, agent-native workspace that each person clones: structured folders, local-first, governance built in from the start. The second is one shared Team Brain that the whole team pushes selected work into, so it becomes searchable team memory instead of chat history nobody can find again. The third is the loop tooling this post has been describing, shipped as commands you run: the plan-build-review pipeline is aios ship, the cross-model plan review is aios relay, and the spec gate is aios spec.

It is built for the person reading this. Founders and teams who already work with AI every day and want the whole organization to work that way too, without the founder becoming the bottleneck that reads and approves everything. Consultancies running client engagements get the same rails, with client-safety built in so the wrong thing never leaves the room.

Here is how it works. You work locally, with whatever agents you already use, Claude Code or Cursor or whatever you like. Nothing leaves your machine until you push it. Every file carries an access tier, and the private tier can never sync: that gate is enforced, not a convention you have to remember. What you do push becomes the team’s shared memory in the brain. And the loops run with verification stacked in, exactly as this post laid out.

Why this, and not something else. AIOS is the operating layer around the models you already pay for. It is local-first, so your data stays yours. Verification is designed into every gate, which is the whole point of this post turned into product. And it is open source, so you can read it, run it, and change it, with no lock-in.

The one line under all of it: verification is the value. Anyone can get an agent to produce something; the reason you can trust the output without re-reading every word is the check behind it. That is the part AIOS ships. Start with the quickstart, or read the decision guide to see which loop fits which job.

The goal was never more chats

Go back to Tuesday morning. Five chats, all waiting on you, you in the middle as the thing that reads and decides. That is not the destination. It is the bottleneck, and it is the state most people who are genuinely good at AI are quietly stuck in right now. They have gotten faster at everything except the one thing that is actually scarce, which is their own attention.

The mature version of working with AI is not the founder answering agents all day, a little quicker than last year. It is the founder back in a long block of deep focus on the one thing only they can do, while the loops run, check their own work, and surface only the two or three decisions that genuinely need a human. The point of a loop was never to open more chats. It was to let you close them and get your attention back. Those five chats from Tuesday morning were five of the six jobs in this guide. The sixth is the one you never had to open.

That is the whole promise. Loops are how you scale yourself without cloning yourself. Start with the quickstart, or read the decision guide and pick the first loop to hand off. Start with the job that is waiting on you right now.