We Let an AI Agent Build for Ten Hours Unattended

Every AI builder shipped the same feature this year. Give the agent a goal instead of a task, close the laptop, and come back to a finished app. The demos are genuinely impressive, and the number in the headline is always the duration — four hours, eight hours, ten.

Duration is the least interesting number in the system. An agent that runs for ten hours is trivial to build: put a turn in a while loop. The hard part, and the only part that decides whether you would ever leave one running against a real project, is what makes it stop.

Why one turn was never enough

A chat turn ends when the model stops calling tools. That is exactly the right shape for "make the header purple" and exactly the wrong shape for "build the booking flow". The work needs more steps than one turn allows, and — this is the part people miss — the agent has no way to notice it is only a third done. It stops, reports what it did, and waits. You read the message, type "keep going", and become the loop yourself.

So the loop moves into the product. Each round is an ordinary turn: it shows up in the transcript, it commits, you can interrupt it. Between rounds, something has to decide whether the goal is met and what the next instruction should be. That decision is the whole feature.

Three ceilings, not one

An unattended agent is spending money by the hour on your behalf. One limit is not enough, because the three ways a run goes wrong are different from each other:

Whichever arrives first ends the run — and the run says which one it was. "Reached the $3.00 budget for this run" is a sentence you can act on. "Stopped" is not.

The checkpoint is the product

Between rounds, a small, cheap model reads what the build agent reported, looks at the result of a browser check against the running app, and answers three questions: is this done, what changed, and what is the single next instruction.

Using a cheap model here is not a cost dodge — although it is a rounding error next to the round it just graded. It is that asking the builder model to grade its own work mid-stream reliably gets you the answer it hopes for. A separate judge with no stake in the previous round is a different question being asked.

The failure mode this creates is worth naming, because it is not obvious. If the checkpoint call itself starts failing — a bad model id, a provider having a minute — the honest fallback is "assume there is more to do". Do that twice in a row and you no longer have an agent deciding when to stop. You have a loop that repeats until the budget is gone, and the budget was never meant to be the control you rely on. So a run that goes blind two rounds running stops and says so.

The expensive failure is repetition, not error

An agent that breaks the build is fine. It notices, it repairs, you watch it happen. The expensive failure is subtler: a run that keeps working, keeps committing nothing, and keeps re-explaining the same misdiagnosis in slightly different words. That is ten hours of paying to watch a model be confidently stuck.

A few rounds that change no files is the signal. One is a bad patch; three in a row is a pattern, and the right response is to stop and hand it back with the last thing it tried — not to spend the remaining seven hours finding out whether the fourth attempt is different.

"Unattended" has to be a decision you made

Here is where long runs collide with approval gates. If the agent pauses for your review before shell commands and deploys, and you are asleep, the run stalls on the first one and the ten hours become nothing.

The tempting fix is to quietly drop the gates for long runs. That trades the product's one real safety claim for a demo that finishes overnight. The honest fix is to make it a decision the person makes once, deliberately, when they start the run — and to record it against that run, so a setting changed at lunchtime cannot silently re-govern something already in flight.

If you leave the gates on and an approval goes unanswered, the run should pause and tell you what it is waiting for. Not press on with the action denied and quietly build the wrong thing on top of it.

The run is not your browser tab

The whole promise is that you leave. That means the run cannot live in a browser tab, and its history cannot live in a JavaScript array. Close the laptop, open your phone two hours later, and the run has to still be there with enough of its story intact to make sense of.

Not all of it, though. A ten-hour run emits tens of thousands of tool calls, and "Read App.tsx" forty times over tells a returning reader nothing. What you keep is the milestones — each round, each checkpoint, each commit, each thing that went wrong — and what you drop is the noise.

What to ask a vendor about their long runs

• What are the limits, and can I set them per run? A product with one hardcoded ceiling has thought about the demo, not the bill.
• What happens when it hits one? "Stopped" is not an answer. It should name the ceiling.
• Does the daily cap still apply during a long run, or does the run route around it?
• How does it decide it is finished, and what happens when that decision fails?
• Does it verify the app between rounds, or only that the code compiled?
• If it needs my approval at 3am, does it wait, or does it proceed without me?
• Can I close the tab? Can I watch it from my phone? What survives a deploy of your own service?

Ten hours is easy. Ten hours you would leave running against a repository you care about is a different product.