The Elastic Loop · Part one

Loops

How much work should an agent do before you look again?

You already make this decision whenever you use one. You ask for something, inspect what comes back, and use what you learned to decide what happens next. That round trip is a loop. Its size is the amount of work you allow between your own checks: a paragraph, an experiment, a working feature.

An agent can carry out many steps in that interval. You need to decide what it can settle for itself and where it needs your judgment. A vague request to rebuild an application gives it plenty to do. It also leaves you with an application’s worth of decisions to inspect afterward. I’d want a few conversations along the way.

Three ways to work

In a tight loop, you stay with the work and respond after each small step. You try an interaction, question an assumption, or ask for another approach while the cost of changing direction is still low. This suits work where you’re discovering what you want, investigating unfamiliar behavior, or making a consequential decision that needs your attention.

An elastic loop gives the agent a bounded piece of work, with checkpoints you agree on beforehand. You might review a proposed approach before implementation and try the first working version before it reaches the rest of the application. Between those points, the agent works and corrects itself using the feedback available to it.

In a loose loop, the agent carries the task through to an outcome you can evaluate. It needs enough context to work independently, checks it can use to correct mistakes, and a clear point at which to stop or ask for help. You also need a way to inspect the result and decide whether to accept it.

These arrangements can span minutes or hours. Their defining feature is where human decisions sit. The same experienced team might work tightly on a difficult product question and loosely on a familiar, well-tested change that afternoon. Either choice can be right.

Tight

you

with the work at every turn

Elastic

you

at agreed checkpoints

Loose

you, at the gate

at the outcome gate

Choose the loop size for the task and the decisions it needs.

Size the task in front of you

I use seven criteria. Work through them for a particular task, with the people who understand its consequences.

Ambiguity. How much is still being discovered? If trying the first version is likely to change the goal, arrange to see it early.
Risk and blast radius. Consider both the consequences of a mistake and how much of the system the change touches. Rebuilding a whole application in an isolated environment still creates a large, interconnected change to understand. Smaller, inspectable pieces and stronger checks make that work more manageable.
Context. Can the agent find the information it needs, and is that information current? When decisions depend on knowledge only you have, you’ll need to stay close enough to supply it.
Verification quality. What evidence would tell you the result is good? Reliable tests and realistic acceptance scenarios support longer delegation. If judging the result requires your direct attention, make room for it.
Reversibility. How would you undo the change? A quick rollback gives you room to experiment. Lost data or commitments to other people may be much harder to reverse.
Learning. What must someone understand or be able to do afterward, and how will they learn it? Choose the learning activity alongside the implementation task.
Agent capability. Has this agent, with this setup, handled comparable work reliably? An unfamiliar combination needs observation before you entrust it with a long run.

An existing codebase can support a loose loop when the agent can follow established conventions and check its work against reliable tests, formal verification, digital twins, advanced reviews, or other appropriate verification mechanisms. I’d delegate a familiar change under those conditions. Elsewhere in the same application, an undocumented business rule may need someone’s attention before work can continue. Choose the loop size for the change you’re making.

You can delegate implementation and still develop a good understanding of the result through an architecture walkthrough, a visual explanation, or experiments you run yourself. Ask yourself to predict what will happen when an input or condition changes, then test that prediction. If the goal is to acquire a skill through practice, keep enough of the hands-on work to learn it. Choose a learning activity that lets you demonstrate what you understand.

One feature can need several loop sizes

Suppose your team is changing a dashboard used to decide which support cases need attention. You have an idea for the new view, but you’re still working out what would make it useful.

Have the agent build a few variants against representative cases. Then try them together. A designer notices that the urgent case is hard to find; a domain expert explains why the apparent priority order would send people to the wrong case. Using the variants changes the requirement. The agent can produce them independently while your cycle of trying, discussing, and revising stays tight. I’d happily spend some of the time the agent saved us here, trying things together.

Once the team has agreed how priority should work, you can delegate a bounded implementation with a checkpoint at the first working view. Later, familiar changes covered by reliable checks might run through to review with little intervention. If an assumption breaks, bring the relevant decision back to the team and shorten the next piece of work.

The specification changes as you learn. The Grading chapter looks at how to turn that learning into criteria the agent can work against.

Agree what the agent may do

For the dashboard task, you might authorize the agent to inspect a reported defect, change code in an isolated workspace, and run tests. Decide separately whether it may merge a change, deploy it, or contact users. Tell it when to report progress and which uncertainties require a decision. A brief update when the first working version is ready can be useful; an unresolved product rule may need your attention sooner.

An event can start work within those permissions. A new bug report may trigger investigation under the team’s existing agreement. Deployment still follows the release policy. Make the trigger, the allowed actions, and the reasons to ask clear enough that people can understand what they have delegated.

Make the feedback work while you’re away

In a tight loop, you supply much of the correction yourself. Longer delegation needs a , the tools and execution environment around the model, that can sustain cycles of attempting work, checking it, and making corrections.

is the quick, inexpensive feedback an agent can act on during that cycle. A focused test reports the failing case, and the agent fixes it. A small product check flags that the urgent case is missing from the dashboard, and the agent adjusts the view. The feedback has to arrive soon enough to steer the work, with a cost in time, tokens, and context that the loop can afford.

An extensive independent review belongs at a review gate. Human approval is another decision point. Instructions provide context, while permissions limit what the agent can do. Plan which feedback runs during the task, what gets inspected at a checkpoint, and who can accept the outcome.

A loop closes when the result has been evaluated and the useful learning is available for what comes next. In tight work, that might be a correction you immediately try. In a longer run, it may require a review against agreed criteria, followed by a change to the tests or guidance the next run will use. Someone needs to own that review.

The cost matters too. A runnable example, an explanation of the important decisions, and evidence from checks can make a result much easier to inspect. A polished demonstration can also leave important behavior unexamined. Give the reviewer enough access to test the claims. Harness goes further into this verification work and its cost.

Build the conditions through experience

A team needs experience with its agents and evidence that the surrounding setup works. How much delegation can that setup support today?

Four questions help diagnose that:

How quickly does the domain change?
Is the relevant context available and current?
Where does trust live, and who decides what can be delegated?
Which signals would reveal , the gradual movement away from the intended result?

These questions concern the team’s working conditions. The seven sizing criteria concern its next task. An answer to one can inform the other: a task that repeatedly stalls for missing business rules has exposed a context problem worth fixing for the whole team.

With an unfamiliar setup, begin with work you can inspect closely. Use what goes wrong to improve it. As the context and checks become dependable, more delegation becomes available for suitable tasks. Keep choosing the size each time.

There are two parts to readiness. Agent readiness asks whether the agent can work here with the information and tools available. Loop health asks whether the team trusts the arrangement and can act on what it learns. Technically capable agents can still sit inside a team that has no agreement about who may let them run or who reviews the result. The readiness skill helps a team examine both.

Some feedback takes weeks

A product loop can stay open long after the agent has finished its implementation task. You ship the dashboard, then observe whether people find and handle the urgent cases. The evidence may take weeks to arrive. It can send you back to the priority rule, the interface, or the original assumption about what people need.

That is a longer feedback cycle, with shorter agent runs inside it. Decide who will collect the evidence, when the team will examine it, and what will trigger further work. Agents can help gather and summarize those signals. The loop still needs a way to turn the findings into a decision.

For your next task, what do you need to see before you’re comfortable letting the agent continue?