The Elastic Loop · A framework for delegating work to machines robert-glaser.de ↗

Helping software build itself<br>The Elastic Loop<br>A framework for everyone delegating work to machines.

We are sitting in the best restaurant in the world. Every dish is suddenly affordable, every once-scarce ingredient abundant, and the kitchen can execute anything you name. There is just no menu. So out of safety, risk aversion, and a plain lack of imagination, most people keep ordering what they know. The schnitzel was fine last time. Let’s do the schnitzel again.<br>That is about where building software landed this year. Once the kitchen can cook anything, the meal turns on two judgments: what is worth ordering, and whether the plate that came back is any good. In the actual work, that is what is worth building, and whether what came back is any good. The Elastic Loop is a working model for those two judgments, for everyone delegating work, specifically building software products, to AI agents. It is for you if you want to learn when to keep the loop tight, when to let it stretch, and what has to be in place before you let go. It is for engineers, but just as much for the people who decide what gets built and judge whether it is any good: product, design, the domain experts. And for the people who set the conditions, whoever shapes how a team works and whoever decides where the money goes. The breadth is the point: both judgments are spread across every one of those roles, not concentrated in whoever sits at the keyboard.

How far can you let go?

Chances are you have done this today: you asked an AI for something, read the answer, winced, rephrased, read again. That round trip is the loop, and it is the unit everything here is built from. You put in intent, the agent does some work, you check what came back, and what you learned shapes the next ask. The size of a loop is how much work happens between two of your looks: a sentence, a feature, a week of output.

The version you ran this morning is the tightest one. Every turn under your eyes, every result checked before it counts, and that mode works well. The question this framework keeps circling is how far the loop can stretch beyond it: first elastic, where you hand over a bounded chunk of work and check in at agreed points, then loose, where the agent works for multiple hours on its own while you do something else. And what has to be in place before you can let go that far.

The whole framework in one sentence

Intent opens the loop. Context grounds it. Backpressure keeps it useful . Verification closes it.

Opens. Somebody decides to delegate and states what good would actually look like.

Grounds. Context is what lets the agent stop guessing and start working from your specifics: your codebase, your customers, your constraints.

Keeps it useful. BackpressureBackpressureThe 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. is the word that stuck in agentic engineering for resistance: anything an agent’s output has to survive before it counts (Geoffrey Huntley and Moss Banay did much of the early work on it). A failing test is backpressure, and so is a designer’s critique or an acceptance scenario from someone who knows the domain. Plenty of the resistance that matters never touches a compiler. The challenge is how much of this backpressure can be automated, so it does not need a human in the loop stopping the belt.

Closes. The outcome gets checked, and what the loop learned survives it. How expensive that check is for the human decides how many loops you can run at once; more on that in Harness.

Where does your next task belong?

Two questions decide where a task sits: how much leash does the agent get, and what holds the output other than you? Read the grid on those two axes. Each step up adds one more dam between the agent and shipped product.

Tight<br>every turn supervised &middot; minutes

Elastic<br>checkpoints at agreed points &middot; minutes to hours

Loose<br>multiple hours of autonomy &middot; outcomes only

Full backpressure<br>technical + product / domain

High-risk work, research, regulated change<br>A delegated feature with product backpressure<br>A (dark) factory: agents delivering asynchronously against automated checks, humans reviewing outcomes<br>Technical only<br>tests, CI, linters

Pair coding with tests, linting etc.<br>Delegated...