The Elastic Loop
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.
Agents make it easier to build software, which gives us more choices about what to attempt. The Elastic Loop helps with two decisions: what is worth building, and how to judge what comes back. It’s for everyone delegating work to machines, especially teams building software products. Engineers, product people, designers, and domain experts contribute throughout that work. The people responsible for the team’s process and budget decide how to support it.
What readers say
Christoph Eckerle Cloud Software Architect · EnBW “It’s compact, sharp, and edge, and in some points unconventional, which makes it fresh to read.
For me, it’s not really a book, it’s more of a companion. I use it as one of my bases for trainings.
Even just the idea of hooking the material into any agent harness to have a team consultant is great!”
Benedikt Stemmildt CEO, Co-founder · hackers&wizards “Tight and loose loops, backpressure, and how they work together. I haven’t seen these ideas explained this clearly anywhere else.”
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, an experiment, a working feature.
The version you ran this morning is the tightest one. You inspect each small result before the agent continues. 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 carries a task through to its outcome gate. 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 gives the agent information about your codebase, customers, and constraints.
Keeps it useful. BackpressureQuick, inexpensive feedback from checks built into the agent’s workflow. As the agent works, these checks report problems it can correct immediately.When the agent tries to save a code change as a commit, an automatic check rejects a variable name that breaks the project’s naming rules. The agent corrects the name. Its next commit attempt triggers the check again. is quick, inexpensive feedback an agent can act on while it works. A focused test or code-style checker reports a problem, and the agent corrects it. Context explains the requirements; permissions limit actions; reviews assess the result at agreed gates. Product and domain knowledge can inform each of these. Harness explains how they work together.
Closes. The reviewer evaluates the outcome, and useful feedback is retained for later work. The time and attention needed by the authorized reviewer affect how much work the team can handle; more on that in Harness.
Where does your next task belong?
Two questions organize the grid: how much work happens between human decisions, and which requirements are covered by checks and review? The second axis describes coverage. Fast backpressure and review gates contribute in different ways.
What is context?
The agent needs access to the information relevant to the task. With more independent work, it has to find more of that information without you supplying it at each step.
Context includes the business rules, product decisions, and technical information relevant to the task. An agent may need current API documentation, an approved design component, or the reason a customer rejected an earlier approach. Some of that knowledge lives only in conversations or people’s heads. Record what later work will need and make it accessible. Margaret-Anne Storey calls the accumulation of undocumented rationale and constraints intent debt.
Stale guidance can misdirect work at any loop size. Checks and checkpoints help reveal the problem, provided they assess the result against current requirements.
Making this information accessible and keeping it current is part of context engineering. It needs maintenance as the product and its requirements change.
Two ways this goes wrong
Delegated work can exceed what a team can use or review. It can also satisfy generic expectations while missing the product’s requirements. Constraints, checks, and review help address both problems.
An agent explores a Search spaceThe set of candidate solutions an agent can explore for a task.Several implementations can satisfy the same requirement. Constraints help narrow the choice. of possible solutions. The task, context, and feedback help it choose among them (see Why).
Sprawl
Sprawl is work generated beyond what the team can use or review. It might be an unrequested refactoring or 30 landing-page variants with nobody assigned to compare them. Agree the scope and who will assess the result before asking for more work. Review queues and unused proposals can show where generation has exceeded the team’s capacity to make decisions.
Slop
SlopPlausible, generic work that misses what makes it fit a particular product or task. It can ignore local coding conventions, architectural decisions, or brand requirements.A dashboard invents visual styles despite an existing set of approved components. looks plausible but misses what the product needs. An onboarding page might read smoothly while omitting the explanation new users need to get started. Give the agent relevant decisions and examples, then assess its work against those requirements. Track recurring misses across comparable tasks and use them to improve the context and mechanisms. Factory shows this through code style, architecture, and brand adherence.
The grid shows how much work is delegated and how well checks and review cover its requirements. Weak coverage can allow defects and architectural DriftIn this book, the gradual movement of work away from its intended requirements or design.Successive changes introduce conflicting design choices across the product.. Even with extensive checks, work can accumulate if nobody has responsibility or time to accept it. That need for an acceptance decision applies across the grid.
Three images I keep reaching for
The truffle
Judgment develops through experience. The truffle image in my talk How Does Truffle Taste? makes that familiar: descriptions mean more once you’ve tasted one. Reading changes, investigating mistakes, and watching users struggle give you a better basis for assessing agent work. Engineers can develop that judgment through close involvement; designers and domain experts bring experience of the product and its use.
The mirror
An agent depends on the team’s available information and decision process. Missing ownership or conflicting requirements can become visible when the agent gets stuck or produces the wrong result. Teams choosing tools should also examine these working conditions.
The pressure reactor
A HarnessThe software around a model that lets it act, inspect results, and continue working: its execution loop, tools, context management, and controls. Harness engineering also covers checks and review arrangements across technical systems.An agent that can read files, run checks, and correct its work uses a harness. combines feedback with controls that limit what an agent can do. In the reactor image, containment stands for enforced boundaries. Backpressure supplies quick correction during the work; gates govern whether it may proceed.
Where to start
If you are new to all of this, start with Loops.
A framework for everyone delegating work to machines. Even machines.
Agents can help inspect their own working conditions: find missing context, propose a check, or compare alternative configurations. Those proposals need evaluation too. Harness describes how to assess changes to the setup; Factory explains who makes that improvement a regular responsibility.