I Used to Run AI Agents for an Hour. Now They Run for Days

The unlock was not a longer prompt. It was verification.

Three weeks ago, I launched fifty BetaBots and let each one use my product for an hour.

They generated thousands of screenshots, thoughts, and actions. At the end, the report said 50 out of 50 were happy.

I thought this was impressive.

Last week, I launched only three strict BetaBots. Not one was happy. The median score was 49 out of 100, and none of them completed a properly verified activity.

That result sounds much worse. It was infinitely more useful.

The failure kept my main coding agent working through another day. It inspected the product, questioned the test harness, deployed fixes, ran a 989-test backend suite, launched new production canaries, found more problems, and refused to call the product ready.

The prompt that started my longest turn was one word:

Continue

That turn lasted 33.7 hours according to Codex's own duration record. The timestamps span 36.1 hours. It started one evening and was still carrying the same goal two mornings later.

A few weeks earlier, almost none of my agent turns survived longer than an hour.

Something had changed.

Each dot is one root turn: orange means BetaBots-associated; gray means not associated. Most turns still end within an hour. The change is the appearance of a day-scale long tail.

One hour was the ceiling

I did not rely on memory for this article. I analyzed my local Codex history: top-level task starts, completions, interruptions, models, child-agent relationships, and timestamps.

Between June 20 and July 9, I had 820 measured top-level turns. 799 of them, or 97.4%, ended within one hour. None lasted more than twelve hours. The longest was 4.81 hours.

Most were much shorter. The median was about three minutes.

This matches how I experienced agents at the time. I could give them an ambitious task, but I expected one bounded attempt. They would research, implement, run tests, report something, and hand the problem back to me. Even when fifty BetaBots ran in parallel for an hour, the supervising Codex agent mostly launched the batch, watched it, made a few changes, and stopped.

The clock was not the problem. The ownership was.

When a test failed, I got a report. When context became messy, I started another turn. When deployment needed a decision, the agent waited for me. It was still useful, but I remained the scheduler connecting every loop.

In January I wrote Vibe Coding Is Team Leading with AI Agents. My argument was that AI coding is a management skill. The model is not magical autocomplete. It is closer to a very fast, very enthusiastic junior developer. You have to provide context, write specifications, review assumptions, and refuse superficial work.

I still believe that. But I had described only the first transition: from writing code to leading an AI implementer.

I had not yet made the next transition: from leading the agent turn by turn to designing an organization that could keep owning the mission without me.

I designed this before I could run it

In April, I published Designing the AI Startup Factory. It described expert agents that never do the implementation themselves. They listen, decide, delegate, validate, persist, and reflect. Their workers are disposable. Their artifacts survive. Failures retry instead of destroying the mission.

At the time, much of it was architecture and aspiration.

I knew what I wanted. Agents should work in the cloud. They should have access to tools. They should persist progress. Supervisors should spawn specialists. A failed worker should be replaceable. A startup should advance through evidence gates rather than internal confidence.

I even wrote that progress should be checked every sixty minutes.

That detail is funny now. I was designing autonomous companies, but my mental unit of agent work was still one hour.

The first visible break happened after GPT-5.6 Sol entered my Codex history on July 10. Four days later, one top-level turn ran for 22.4 hours and completed successfully.

It was not one model silently thinking for a day. Sol acted as a supervisor inside a much larger work system. It restored a broken PostgreSQL-backed stack, worked with specialist agents, found that the updated BetaBots runner could not reliably preserve state across sessions, modified the runner, added stronger evidence requirements, fixed a product accessibility problem, ran backend and browser suites, built the production workspace, and closed the release only after the matrix became green.

That turn recorded 4,697 tool calls. The surrounding mission spawned 43 descendant Codex threads.

The final report included 805 unit and component tests, 61 real-backend checks, 106 UI-only Playwright checks, and multiple long-term BetaBot journeys.

For the first time, I saw an agent turn behave less like a coding session and more like a temporary engineering organization.

The unlock was verification

On July 19, before I ran this full analysis, I wrote in my weekly update:

This week it was the first time I made AI work for 24+ hours and got good results. The unlocking power was reliable verification layer with Betabots and better model (GPT 5.6).

That is still my best summary.

A better model helped. Sol could hold the supervisory role, recover plans after context compression, coordinate workers, and stay coherent through long sequences of tests and fixes.

But a model does not run for a day just because it is intelligent. It needs a reason to continue.

That reason was verification.

I had already experienced the opposite version. In my 2025 personal review, I admitted that I had let AI put about fifteen supposedly “90% done” features onto the main branch while I barely looked at what it produced. None worked properly. The code was a mess.

That was not autonomy. It was unattended generation.

Before BetaBots, an implementation agent could run its own tests, inspect its own output, and announce that the work looked good. This is like letting a student write the exam, answer it, and decide the grade.

BetaBots use the product as synthetic users. They operate through the visible interface, follow different goals, preserve evidence, and fail when the journey does not produce what a real person needed. They do not replace deterministic tests, security review, accessibility checks, or human research. They add a hostile user-like layer that the implementation agent does not control.

The newer version became deliberately hard to satisfy. It checked real authentication and persistence. It required substantive AI conversations and completed activities. It separated a product defect from a broken test harness and from random browser noise. A pleasant screen was no longer enough.

The effect in my workflow was visible almost immediately.

A failed cohort was no longer the end of a task. It became the beginning of another task that the system already knew how to create:

1. Preserve the failed journey.
2. Classify the failure.
3. Ask a specialist to reproduce it.
4. Fix either the product or the evaluator.
5. Deploy the exact revision.
6. Run deterministic tests.
7. Launch another cohort.

I did not have to read a report and invent the next prompt. The failed evidence created the next loop.

Long-running agents are not agents that never fail. They are agents whose failures can become the next task without immediately becoming my task.

Fifty happy bots versus three unhappy bots

The contrast still makes me uncomfortable.

My older one-hour BetaBots run reported 50 out of 50 happy users. Another reported 50 out of 50 “simulated multi-year completions.” The scale looked amazing. Fifty users! Thousands of actions! A perfect happiness score!

But those were bounded scripted campaigns. They were useful experiments, yet the system could compress a supposed long-term journey into a quick simulation and call it success. There were no descendant Codex agents turning every serious failure into an engineering program.

The newer cohort had only three users, and all three failed.

That failure forced the supervisor to confront something worse than a normal product bug: parts of its own post-run BetaBot analysis were truncating evidence and hallucinating events. The system had been making claims that the immutable journey evidence did not support.

So the agent started repairing the machinery by which it decided whether it had succeeded. Claims had to cite exact evidence lines. Unsupported conclusions failed closed. Test accounts had to be deleted through the same visible UI. Product failures, evaluator failures, and infrastructure failures had to be recorded separately.

Three unhappy bots told me more than fifty happy ones.

I had been optimizing for the number of agents. I should have been optimizing for how difficult they were to fool.

The week-long mission

The clearest example came from a Self-Degree mission that stayed alive for seven days and fourteen hours across several interruptions and continuations.

Over its lifetime, the root mission spawned 527 descendant Codex threads. That does not mean 527 agents worked simultaneously, and it definitely does not mean 527 agents produced useful work. It is a count of spawned thread records across the mission.

Still, the change in operating scale was obvious.

The mission contained autonomous turns of 11.6 hours, 8.8 hours, more than 33 observed hours, 21.4 hours, 10.5 hours, 33.7 recorded hours, and finally a 13.3-hour completed release turn.

Several began with nothing more than “Continue.”

The longest explicit turn recorded:

• 6,203 tool calls;
• 100 started subagents;
• 721 subagent activity events;
• 632 progress messages;
• 20 context compactions.

The compactions matter. This was not one untouched context window with a superhuman chain of thought lasting through the night. State was compressed. Progress was written down. Worktrees, commits, test results, evidence, deployment revisions, and unresolved findings existed outside the model.

The agent could forget details and reconstruct the mission from artifacts.

That is how humans run long projects too. We do not keep a week of work in working memory. We use documents, tickets, commits, logs, tests, and conversations to become the same organization again each morning.

My laptop became the bottleneck

At some point during the Self-Degree work, the agent did not run out of intelligence. My laptop became overloaded.

I told it to move the heavy work to my Hetzner server.

The builds, browser sessions, provider checks, BetaBot cohorts, and deployment monitoring moved to a durable machine in the cloud. My laptop became a control surface rather than the place where the mission physically had to survive.

This was one of the ideas behind the AI Startup Factory: configurations in Git, services in the cloud, reproducible environments, progress that survives restarts.

Without that substrate, “run for days” means “hope my laptop does not sleep, overheat, lose Wi-Fi, or get used for something else.” That is not autonomy. That is a fragile demo.

A long-running agent needs boring infrastructure. It needs a stable server much more than it needs another inspiring system prompt.

I also had to stop being the scheduler

The prompt history shows a change in my own behavior.

My older prompts contained the next task. My newer prompts increasingly said:

Continue

Or:

Sorry for interruption, please continue.

At one point, after too many updates, I told the agent to stop disturbing me and keep working.

That may sound like laziness. It was actually a transfer of responsibility.

Previously, I owned the loop. The agent did work, then returned. I reviewed its report, decided what came next, and sent another prompt. If I went to sleep, the organization stopped because I was the organization.

Now the supervisor owned more of the loop. It could inspect what remained, delegate bounded investigations, reject findings, rerun tests, hold a deployment, and continue from persisted state.

My work moved toward the parts I still wanted to own: the goal, the definition of good, major product boundaries, permissions, and whether the system deserved to continue.

This is close to what I predicted in my vibe-coding article. Senior engineers would move from implementation into architecture, specification, and review. Staff engineers would manage fleets of agents.

I underestimated one more role: designing the feedback system that tells the fleet when it is wrong.

Longer is not automatically better

I can make the numbers sound more dramatic than they are.

Most of my turns still do not last hours. Even in the newest period, more than 90% ended within one hour. The median remained a few minutes.

What changed was the long tail. Before July 10, there were no twelve-hour root turns in the measured window. Four days after Sol appeared, I had a completed 22.4-hour turn. Later I had a turn with 33.7 recorded hours across 36.1 hours on the clock. Two other turns without terminal events show more than 24 hours of associated activity.

This is not “all agents now work for days.” It is “some missions can now keep ownership for days when the problem deserves it.”

And the longest run did not end in victory.

It ended interrupted, without a final completion message. When I asked for the full timeline four seconds later, Codex said production was still on the older revision. The newest fixes had been tested on Hetzner but were not committed, pushed, or deployed. Independent review had found two multilingual P1 issues, so the release remained held.

The product was not ready for ad traffic.

A later 13.3-hour turn completed the corrected release.

I prefer this story to a fake overnight-success story. The value of the 36-hour span was not that it magically finished everything. It was that it could sustain implementation, review, deployment, user testing, and self-criticism long enough to discover that shipping would be irresponsible.

Duration is not quality. Tool calls are not productivity. Agent count is not intelligence.

A bad loop can waste compute for a week.

The stack behind a day-long agent

If I had to reduce the transition to a practical system, I would not start with “use GPT-5.6 Sol.” A model is one component.

I would start here:

Give the mission a falsifiable definition of done

“Make the product good” is not a release gate. A real gate might require successful authentication, persistent data, completed user journeys, deterministic tests, accessibility checks, exact deployed revisions, and no unresolved P1 findings.

The agent needs to know what evidence could prove it wrong.

Separate the builder from the judge

Do not let the implementation agent grade itself. Use independent reviewers, deterministic tests, hostile user journeys, or another model with a different role and context.

The judge can also be wrong. Preserve the raw evidence so the supervisor can audit the evaluator.

Make failure create the next task

A failed test should have a route to classification, reproduction, repair, and rerun. If every failure returns to the human as “what should I do?”, the agent is not autonomous. It is an asynchronous employee waiting for a manager.

Store the mission outside the context window

Plans, acceptance criteria, worktrees, commits, test reports, screenshots, deployment revisions, evidence, and open blockers must survive the model.

Long-running agents are mostly an artifact-management problem.

Use a supervisor and bounded workers

The root agent should own the goal and integration. Specialists should receive narrow work: investigate one failure, review one boundary, implement one isolated fix.

More agents are not automatically better. Every worker adds coordination, stale-state, and merge problems. The supervisor earns its existence by keeping the mission coherent.

Run it somewhere durable

If the mission depends on one laptop window remaining alive, it is not designed for days. Put heavy execution on a server. Make the environment reproducible. Expect processes, browsers, workers, and streams to fail.

Then design recovery before you need it.

What I got wrong

For a long time, I thought better AI autonomy meant giving agents more tools and permissions.

That helped. It was not the unlock.

Then I thought it meant more agents. I designed swarms, expert roles, and a factory full of disposable workers.

That helped too. It was still not the unlock.

The unlock was making failure legible and actionable.

Once the system could independently discover that a user journey failed, distinguish product failure from evaluator failure, preserve the evidence, create repair work, and try again, time stopped being the main boundary.

The agent did not need me to keep inventing reasons to continue.

Failure did that.

This also changed how I think about “good results.” Fifty out of fifty happy bots can be useless if the evaluator is easy to satisfy. Zero out of three can be an excellent result if the failure is real, preserved, and converted into better work.

I am not trying to build agents that run forever. I am trying to build systems that keep ownership until the evidence says the mission is complete, unsafe, blocked, or no longer worth continuing.

Those are different goals.

Try the loop, not the prompt

If you want to reproduce this, do not begin by asking an agent to work overnight.

Give it one real goal. Define evidence that would make you reject its work. Give an independent actor the job of finding that evidence. Persist every artifact needed to resume. Then make every failure enter a known repair loop.

You may discover that your agent still finishes in twenty minutes. Good. Runtime is not the objective.

But when the product is broken, the test is wrong, the browser crashes, a reviewer disagrees, the laptop runs out of resources, and you go to sleep, ask one question:

Does the system still know what it owns?

Three weeks ago, mine did not.

Now, sometimes, it does.

And sometimes the only prompt it needs from me is:

Continue.