Loops
Let me start with the word itself, because everything in this framework, and agentic work in general, hangs off it. A loop is the round trip between you and a machine working for you: you say what you want, the agent produces something, you check it, and what you learned feeds the next ask. If you have ever rephrased a prompt because the first answer missed the point, you have closed a loop. The size of a loop is how much work happens between two of your looks: a paragraph, a feature, a week of output. As long as humans did the work, nobody had to build that loop. It just happened. Once a machine does the work, the loop becomes something you build on purpose, and everything below, the three zones, the sizing criteria, the closure question, is the craft of building it deliberately instead of inheriting it from habit.
None of this is new, and I would rather say so myself than have someone say it for me. The feedback loop is the beating heart of every iterative method we have practiced since the Agile Manifesto put it in writing in 2001: build something small, look at it, adjust, go again. A sprint is a loop. Continuous delivery runs the same loop tighter, and build-measure-learn is that shape again under a different name. The loop is old. What is new is two things. One you can feel already: who works inside it, and how fast one person can open one. The other is quieter.
You already run more loops at once than you ever named. You ship a change to production, then wait on the UX team running sessions with real users. Weeks later they come back, in a meeting or over the phone, and what they found sends you to fix the code, cut the feature, or reshape it. That is a loop, interlocked with the fast one you ran while building, and it turns over weeks where the other turned over minutes. Nobody drew it on a wall. A person held it together in their head and their calendar. It was implicit, and it worked because a human was the glue.
That glue is what a machine cannot supply. When the worker is a machine you summon on demand, the loop has to become explicit, something you build, because the machine does not know your users, your release rhythm, or which meeting the real verdict shows up in. You do. So you choose loop size per task where the calendar used to decide for you, and you build the longer loops out to production and back instead of trusting them to memory. The far end of that range, many hours of unattended agent work, is the part most of us genuinely have not done before.
The question worth taking seriously here is the one this whole framework circles: if the tight loop you probably ran this morning (ask, read, wince, rephrase) works so well, how far can it stretch? Tight is the one mode everyone knows from their own hands. The other two zones are the same loop with more leash paid out, and every extra meter changes what has to be in place around the work.
Three zones, none of them a ladder
Tight runs in minutes. You are embedded in the cycle, reviewing every turn, checking hypotheses as they form, working in something close to pair-coding mode. The cognitive load is high and the control is maximal. That trade is exactly right for a whole class of work. Anything high in ambiguity or risk, where a wrong turn is expensive and the path is not clear yet. Legacy brownfield where the documentation lies and problems nobody has seen before, the ground you have to feel your way across. And anything where you are the one who needs to learn something from contact with the material, because handing that off hands off the learning too.
Elastic runs in minutes to hours. You hand over a bounded chunk of work, structured delegation with guardrails and checkpoints, and you come back at agreed points instead of every turn. The work that belongs here is understood enough to hand over, but not safe enough to ignore. (This carries more weight than it looks; most delegation failures I see come from misjudging one of its two halves.)
Loose runs in multiple hours. A single agent or fleets of agents work asynchronously under policy constraints, and the human reviews outcomes rather than turns. You may have heard of the term Dark factoryThe loose loop run to its end: agents delivering on their own against automated checks, with humans reviewing outcomes rather than every turn.Named after lights-out manufacturing, where the line runs without people on the floor. for these kinds of loops.
I want to be blunt about a misreading the three zones invite: tight is not a beginner mode you graduate out of, and loose is not a badge of being advanced. Think gears, not a ladder. You shift to match the road. An engineer who keeps a highly regulated change in a tight loop with almost no BackpressureThe resistance an agent works against while it builds, well before any review at the end: a failing test or type error on the technical side, an acceptance scenario or rubric on the product side. Some of it reaches the agent automatically as a signal in the loop; some it imposes on itself by following a discipline set at the start, like writing the failing test first and working until it goes green. The more of it you can encode, the longer you can let the loop run.A red build is backpressure; the agent reads it and fixes the code. So are acceptance criteria: write them well and the agent works against your definition of good as it goes, instead of a person catching the miss at the end. at hand is in the right gear. A team that pushes everything loose because it feels like progress is about to find out why the criteria below exist. Misjudging the size does not fail loudly. The agent keeps running, sure of itself, while nobody backfills what it is missing, and the bill arrives later as DriftSlow movement away from what is correct or wanted, over time, without any single obvious break.The product or codebase quietly getting less coherent release after release. that has compounded past a cheap fix. The only question the zones answer is how much loop this particular task can carry.
Are your loop sizes choices or accidents?
People keep collapsing two questions into one, so let us keep them apart.
1. What state are the loops you already run in?
Four strategic questions get at it:
- How volatile is the domain?
- Is the context in place for agents to work from?
- Where does trust actually live in the organization?
- And which metrics would catch drift fast enough to matter?
Ask these about a team, and you learn whether its current loop sizes are choices or accidents.
2. The loop size of the task in front of you
For that I use seven sizing criteria.
- Ambiguity: unclear intent pulls the loop tighter.
- Risk and blast radius: the bigger the damage a wrong move can do, the tighter the loop and the stronger the gates.
- Context availability and freshness: undocumented or volatile territory pulls tighter.
- Verification quality: strong tests, evals, and scenarios are what permit looser loops in the first place.
- Reversibility: cheap rollback buys you elasticity.
- Learning goal: if a human needs to understand this deeply afterward (comprehension, or cognitive debt in Margaret-Anne Storey’s terms), do not over-delegate it away from them.
- Agent capability: long task horizons only pay off when the closure infrastructure can keep up with them.
Diagnosis tells you where you stand. Sizing is about the next task, and what to do with it. Mix the two and a team ends up arguing about its maturity, when the fight should be over one task’s blast radius.
Every zone has to close the loop
Whatever size you pick, the loop has to close: the outcome gets checked, and what was learned survives. What changes per zone is the machinery doing the closing.
In the tight loop, you are the iteration mechanism. Hypothesis, attempt, check, correction, over and over, backed by the instant signals you get for free while you sit there: the LSP and compiler, the linter and formatter, the diff in front of you. Direct material contact runs through an interactive agent HarnessThe scaffold that turns a model into an agent, assembled from many parts. Among those: the loop it works in, the tools it can reach, how its context is managed as a run grows long (compression, retrieval), the hooks that fire on what it does, subagents, and guardrails. Backpressure and other resistance attach here, and beyond it.An interactive agent tool like Claude Code, Codex, or Pi is a harness. You have been working inside one all along. like Claude Code, Codex, or Pi, and through tests, UI, and logs.
In the elastic loop, intent-carrying artifacts like specs and user stories become the steering artifacts, carrying boundaries, constraints, and risks. Around it: a reproducible setup with CI, acceptance criteria the work is held to, and review at the checkpoints, by a human and by reviewer subagents.
In the loose loop, the machinery has to stand in for your absence, and there is a lot of it. Containment first, so a bad run cannot escape: sandboxes and worktrees, rollback paths. Then the judgment you would have applied by hand, now encoded: Outcome gradingJudging whether a result is good, precisely enough that the judgment can be applied again and again, by a person or a machine.You already do the simplest version every time you write a test or a definition of done. (RubricA written list of what “good” means for a kind of output, so the same standard can be applied to every result.Acceptance criteria, reused as a grading checklist instead of a one-off., scenarios, GoldenAn output you have blessed as correct and keep around as the answer key, to compare new output against.The trusted fixture in an integration test: the known-good result everything else is measured against. examples, CounterexampleA plausible-looking but wrong output you keep on file, so the system learns never to produce that kind of thing again.The bug you once shipped and then wrote a regression test for.), fix-loops, adversarial agent reviews with their own approval gates, drift monitoring, automated regression gates. And finally the legibility artifacts that make the final human check cheap: screenshots, screen recordings, trace summaries. That last item matters more than it sounds: how many loose loops one person can run in parallel is capped less by containment and more by the cost of verifying each one at the gate (the Harness page takes this apart).
And here is the sharpening that took me a while to see. In the tight loop you supply the micro-iterations implicitly, just by sitting there. In the loose loop nobody supplies them. So the harness, the machinery around the agent described above, has to encode those cycles in advance, decompose, parallelize, verify, iterate, as explicit architecture rather than an emergent property of human presence. Cursor’s First Proof, OpenAI’s harness engineering, and Anthropic’s harness design for long-running apps all arrived at exactly this shape independently.
Some loops you build run for weeks
The loop out to production and back, the one the UX team used to carry, you can now build explicitly too. A background agent reads your production signals and user feedback on a weekly beat, turns what it finds into experiments with a clear measure of success, hands those to build agents to ship, and then watches over the following weeks what became of them. Its loop does not close when the build goes green. It closes when the production verdict arrives.
And you rarely build just one. Different signals move at different speeds, and the loops that watch them inherit that: a crash report closes in a day, a retention question in weeks, architecture decay in a quarter. You match each loop’s cadence to its signal instead of to the calendar. The fast loop tells you the code works. The slow one tells you whether it was worth building, and that was always the more important answer. It just used to live in someone’s head instead of in a loop you built.
Could an agent even work here yet?
One more thing, which sits underneath everything above. Context behaves differently from the choices we have been making so far. Nobody chooses bad context, because it is a maturity state rather than a decision, whether you like it or not. A tight loop survives thin context, because you backfill the missing knowledge turn by turn from your own head; a loose loop has nobody doing that. So bad context collapses the entire loose loop area out of reach, no matter how good your backpressure is.
That is why I treat context as a gate with two layers.
- Layer 1 is agent readiness: can the agent even work here, with the context quality, freshness, availability, and relevance it would need?
- Layer 2 is loop health: does the team trust itself enough to let go? You can fail the second while passing the first, and plenty of teams do. But failing the first is how loose loops produce confident nonsense for hours.
So before you size your next task loose, ask the readiness question honestly: could an agent work here at all yet? Could a new flesh-and-blood colleague work here at all, without endless getting-knowledge-out-of-people’s-heads sessions? And if it could, here is the harder question: would you let it?