Agents went from running thirty seconds before derailing to working for hours. The trick isn't one giant session; it's loops: fresh contexts, one task at a time, state kept in files and git, and a check the loop can't argue with. From the Ralph loop to nightly slow loops, here's how to let agents work while you're away.
Key takeaways
- Long runs work as loops of fresh sessions, not one giant session that rots.
- The Ralph loop: run the same prompt again and again, one task per iteration, fresh context each time.
- Keep state outside the context: a task list with pass/fail flags, a progress file, and git commits.
- Loops need back pressure: tests, types and metrics the loop must satisfy.
- Start with slow loops that make one small, verified improvement and open a PR.
Try it with your agent
Design (don't schedule yet) a slow loop:
Propose one nightly "slow loop" for this repo: a job that fixes exactly ONE small thing (a lint warning, a flaky test, a TODO) and opens one small PR. Write the prompt file, the verification it must pass, and how it records progress. Don't schedule or run it yet.
Transcript
Intro
Karpathy says that to get the most out of these tools, you have to remove yourself as the bottleneck. You can't be there to prompt the next thing. So how do you let an agent work for hours without you?
Longer runs
Run lengths have exploded. Boris Cherny recalls that early models could run fifteen or thirty seconds before going off the rails. By 2026, typical unattended runs lasted tens of minutes, some for hours or days. Anthropic's trends report describes a single seven-hour autonomous run that implemented a feature in a twelve-million-line codebase.
Loops, not marathons
But long runs don't come from one giant session. A single session fills up, rots and compacts. Long runs come from loops: many fresh sessions in a row, each doing one piece of work, with the state of the project kept outside the context window.
The Ralph loop
The most famous version is the Ralph loop, by Geoffrey Huntley. In its purest form, Ralph is a bash loop. It pipes the same prompt into a coding agent, again and again. Each run starts with a fresh context, studies the plan, picks the single most important task, does it, and exits. Huntley calls it low control, high oversight.
Engineers in shifts
Anthropic's engineers describe the core problem vividly. Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift. That's what a loop of fresh sessions is.
The shift handoff
Their answer is a disciplined handoff. Every session gets its bearings first, from a progress file and the git log. It runs a quick smoke test. It implements exactly one failing feature, verifies it end to end, commits, and flips that feature's pass flag to true. Then the next shift begins.
Back pressure
Loops only work with back pressure: checks the loop has to satisfy, like tests, types and linters. Dex Horthy's lesson from Ralph: if you can make a problem very verifiable, you can treat it like a black box and loop on it. Karpathy's AutoResearch is the same idea. Give an agent an objective, a metric and boundaries. Overnight, it found tunings in his code that he'd missed.
Slow loops
You don't need an overnight swarm to start. Dex recommends slow loops: a nightly job that runs the linter, fixes one thing, and opens one small pull request, so you wake up to a slightly better codebase. Boris runs dozens of loops: one babysits his pull requests and fixes CI, another hunts flaky tests, another clusters user feedback.
Headless
Loops run headless. Boris describes Claude's print mode as a Unix utility: give it a prompt, get JSON back, and pipe it into anything. And a stop hook can check the tests when the agent tries to finish, and simply tell it: keep going.
Use the boundaries
Mitchell Hashimoto has a simple habit. He spends the boundaries of his day, when he wakes up and before he stops, deciding what slow task an agent can do while he's away: library research, edge case analysis, triage. Those agents write reports. They aren't allowed to respond to anyone.
Caveats
Some caveats. Geoffrey Huntley warns you'll sometimes wake up to a broken codebase, so commits and tags are your restore points. Peter Steinberger thinks heavy upfront plans for loops are waterfall in disguise. And OpenAI's harness team says their end-to-end autonomy depends heavily on their repo's structure and tooling, so don't assume it transfers for free.
Quick check
Quick check. Which task is the best fit for an overnight loop? Tap your answer.
Try it
Design your first slow loop. This prompt has the agent propose a small, nightly improvement with a strict check, without scheduling anything yet.
Recap
Recap. Long runs are loops of fresh sessions. One task per iteration, with state kept in files and git. Loops need back pressure, so make the problem verifiable. Start with slow loops and restore points. Next: harness engineering, building the whole factory.