You wrap the agent in a loop. Every hour it wakes up, reads the new bug reports, and files what it finds. You watch two runs go by, they look right, and you close the laptop for the weekend. Monday morning the queue is empty. No error, no crash, no half-finished run, just three days of nothing. The loop did exactly what you wrote. It reran a prompt on a machine that was asleep, which is not the same thing as work getting done. The mistake was made before the first iteration, when you decided what starts the loop.

A house has four kinds of switch

Underneath, every loop is the same three moves: look at the state of the world, act, check whether you are finished. What differs is who says go, and what says stop. Think of the switches in a house. Some you flip yourself, one at a time, and nothing happens in between — that is the conversational turn, where you type, the agent answers, and the next move waits for you. Some run on a timer, like a porch light that comes on at seven whether or not anyone is home. Some sit on a sensor and fire when something outside happens, a door opening, a report arriving. And some are a thermostat: it runs not for a set time but until the room reaches the temperature you asked for, then stops on its own.

The thermostat is the one worth wanting, because it has a criterion you can check. “Every bug report found has been triaged and answered” is a thermostat. “Keep going until the result feels good enough” is a switch nobody ever flips off. And in a real house every switch sits behind a fuse. A loop needs the same thing: a declared ceiling on attempts, tokens, or minutes, so a stuck run trips rather than burns.

Cost and silence both follow from the trigger

The choice is not stylistic; you feel it in the bill and in the failure mode. A timer reruns the whole prompt on schedule, so you pay for every wake-up, including the many where nothing changed. A criterion stops the moment the work is verifiably done, and never runs the extra pass. A loop with neither a criterion nor a fuse simply spends until someone notices.

The silence has its own cause. A timer on your own machine dies with the machine, so anything meant to run while you are not there has to live in an environment that outlasts your laptop. That is a decision about infrastructure, not about prompting, and no model will make it for you.

The primitives combine, which is where the real designs live. An hourly schedule pulls in new bug reports. A goal insists that every report found gets triaged and answered before the run counts as finished. The fixes themselves go through a parallel workflow and a review step before anything closes. That review step is where you draw the line between what the system may do alone and what still waits for a person, and drawing it is the same kind of work described in The Loop Is the Product, Not the Model.

The clock belongs outside the model

There is one more trigger that people forget: the deadline. A model has no sense of elapsed time. It knows what you told it at the start and nothing since, so it will pursue a perfectly sound strategy straight past the point where a slower plan stopped being affordable.

The fix is to treat time as part of the observable world. In a simulated ten-minute negotiation, the harness computes the remaining budget and injects it before each decision, so the agent is told, plainly, that ninety seconds are left. It stops hunting for marginal alternatives and puts a closable offer on the table. Without that update it keeps exploring, sensibly and far too slowly. Announcing the limit once at the start does not work, and neither does a warning that never says which behaviour should change as the budget shrinks. Strategy and clock-watching are separate skills, and only one of them belongs to the model.

Pick the wrong loop and you pay for it twice, in money and in silence.