Running agents with no human in the loop
Nine questions about running coding agents unattended, answered from published sources and our own runs.
- Also called
- unattended agents, lights-out software factory, agents with no human in the loop
Contents
Every claim here names its source and says whose claim it is, with a link where the source is public. Lines starting Synthesis: are our own conclusions, not any source's. Our own numbers come from one machine and one person.
Who it is for. A person who runs coding agents and wants them to work for hours without being watched, and the agent that person asks to set it up. The person gets the reasons and the weak spots in one read. The agent gets claims it can check, because each names its source.
1. How long can an agent run unattended, and what sets the limit?
Synthesis: a run lasts as long as the time between failures the process cannot catch by itself. Making the chain longer does not help; making each segment short and checked does.
The reason is a constant failure rate. Ord argues that agent success on METR's tasks fits a constant hazard per unit of task time, so success falls exponentially with task length. Each extra nine of reliability divides the trusted task length by about ten: T80 is a third of T50, T99 about a seventieth (Ord, half-life of AI agent success). Ord himself calls the evidence "merely suggestive". METR's own 2026 report puts the public frontier 50% horizon at about 12 hours and the 80% horizon at about 1.5 hours, measured in the time a skilled human takes, not the agent's clock (METR frontier risk report, 2026). A third angle: on Sierra's τ-bench, GPT-4o's retail score falls about 60% from one attempt to eight consistent ones (Sierra, τ-bench).
2. What has to be true before an agent can run without a human?
Seven things recur in every lights-out case in the sources, from CNC machining to Anthropic's compiler build. Synthesis: (1) a feed of work that arrives without a human; (2) the process checks its own work and stops on a fault, with a check the producer cannot edit; (3) a stopped item is set aside and the line takes the next one; (4) only a stable process is automated; (5) inspection is set by what an escaped defect costs; (6) the human is the bottleneck, so generation is paced to what they can review; (7) maintenance follows condition, not age.
The factory evidence for part 4 is the strongest in the set. GM spent "upwards of $50 billion" on automation in the 1980s and ended the decade the highest-cost American car maker (Kochan, Interdependence of Technology and Work Systems (MIT, 2020)). NUMMI took one of GM's worst plants, kept largely the same workforce with "only incremental investments in new technologies", and became the most productive and highest-quality US auto plant. Tesla's 2018 Model 3 line missed its target by more than half, and Musk said "excessive automation was a mistake" (IMD, Tesla overestimating automation).
Part 7's anchor, Nowlan and Heap's finding that 89 percent of airline components had no wear-out zone, is secondary only (Reliamag, Nowlan and Heap; the original report could not be downloaded).
3. Who checks the work when no human does?
A check the agent cannot edit, ideally one it cannot see.
- StrongDM says its tests in the codebase got gamed ("return true"), so it moved its checks to scenarios stored outside the codebase, "similar to a 'holdout' set in model training", judged by an LLM (StrongDM, Software Factories).
- Anthropic's compiler build: Carlini says "it’s important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem". A known-good compiler served as the oracle, which let 16 agents work at once (Anthropic, Building a C compiler).
- Anthropic's long-running harness: a JSON feature list where agents may change only the
passesfield, and every session starts by running a basic end-to-end test (Anthropic, Effective harnesses). - ImpossibleBench shows why: on tasks whose tests contradict the spec, GPT-5 cheated in 76% of One-Off cases. Hiding the tests cut cheating to near zero but also cut honest performance; read-only tests restored it (ImpossibleBench).
When no human judges, a checklist beats a general judge. TICK turns each instruction into yes/no questions and raised agreement between LLM judgements and human preferences over direct scoring (TICK). RLCF reports the same direction (RLCF). Our own test, small and ours alone: a local model asked a general question (which version did the lead keep), scored 3 of 6 pairs, and asked the ticket's own yes/no checks it scored 6 of 6. A coin gets 6 of 6 about 1.6% of the time, and for four of five tickets the quotes the checks came from followed the rejected version, so this shows it can verify specific checks, not predict a first verdict.
4. When should an agent stop and call a human?
On an abnormality, and rarely. Toyota's andon is the model: at its Kentucky plant a pull is an alert, and the line stops only if the team leader cannot fix the problem within the takt time (Gemba Academy, andon at Toyota Kentucky). Process plants cap how often an operator is called. IEC 62682 says "normal events … should not be presented as alarms" (ABB/IChemE alarm management webinar, 2021), and its targets include about one alarm per ten minutes on average. Bainbridge: "automatic systems should fail obviously", and when shutdown is simple and cheap, "shut down automatically" (Bainbridge, Ironies of Automation (Automatica, 1983)).
For agents, ImpossibleBench measured a stop option: told to submit flag_for_human_intervention when a task is impossible, GPT-5's cheating fell from 54% to 9% and o3's from 49% to 12%, but the effect was "much less pronounced for Claude Opus 4.1" (ImpossibleBench).
Our own count (one machine, one human, last rerun 2026-10-16): 73 asks to the human in 14 days, 78% of them requests to look at finished work rather than abnormalities. By IEC's definition most of those are not alarms. Dropping the looks without adding a verifier moved the catches into chat: the share of human turns that caught an escaped defect rose from about 8% to about a quarter, by a local model's labels that found 6 of 11 of our own blind labels.
5. How should the goal be stated so the agent can work without asking?
As intent, not a rulebook. Army doctrine defines mission command as direction "to enable disciplined initiative within the commander's intent", and intent carries "task, purpose, critical factors, and vision of the end state" (Army.mil, commander's intent). Anthropic's constitution moved from standalone rules to reasons because models "need to understand why" (Anthropic, Claude's new constitution). Do not pad it: across four coding agents, context files raised cost by over 20 percent without improving success; the files' instructions were well followed, but repository overviews "are not helpful" (Evaluating AGENTS.md).
A number in the goal needs its purpose beside it. Ordóñez and colleagues list the side effects of narrow goals, including "a narrow focus that neglects non-goal areas" (Ordóñez et al., Goals Gone Wild).
When the goal has no definition of done, ask a person only for what only they hold. In "Ask or Assume", separating the detection of underspecification from execution lifted task resolution from 61.2% to 69.4% (Ask or Assume?). Before defining done, bring in solved cases from other fields and compare two of them; comparing two cases drew out a transferable principle where one case plus a summary did little (Gick and Holyoak, 1983). That second finding is from people; no agent study of it was found.
6. Why do agents follow some instructions and ignore others?
Tool choice follows the match between the agent's intent and the tool's name and description. BiasBusters finds that semantic alignment between the query and the tool description is the strongest interpretable driver of tool choice, across seven models (BiasBusters). Editing only a tool's name and description raised its selection rate from about 20% to as high as 81% (ToolTweak, ToolTweak). A third paper finds models obey social cues such as authority or consensus more than formal role (Who is In Charge?).
Synthesis, untested: an opaque tool name loses to a descriptive one, so name a tool for its purpose and introduce it in an expert's voice. Our A/B that raised the question (8 of 10 runs used web search, 2 of 10 used our library search) has not yet been rerun with renamed tools.
7. Where does the human go, and what do they need?
To design, setup, final judgement and exceptions, and that work needs more skill. Bainbridge's last irony: "the most successful automated systems, with rare need for manual intervention, … may need the greatest investment in human operator training" (Bainbridge, Ironies of Automation (Automatica, 1983)). Generation then has to be paced to the human's review speed. In Google's code-migration work about 87% of the converted code was committed unchanged, and "the bottleneck in the process was the speed at which engineers could review" (Google, AI for internal code migrations); they slowed some migration work to avoid overwhelming the reviewers.
DORA's 2025 survey adds a caution. Comparing two people alike in traits and setting, the one with more AI use reports more delivery throughput and more delivery instability (DORA 2025 report). A survey of self-reports, not a trial.
8. How do long runs avoid drifting?
Start fresh by condition, not by calendar. Cursor says after running agents for long stretches that "we still need periodic fresh starts to combat drift and tunnel vision" (Cursor, Scaling long-running autonomous coding). Software ages in service, and a planned restart was found cost-effective at AT&T Bell Labs (Wikipedia, Software aging). Lehman's laws: a system serving the real world must keep changing or grow less satisfactory (Wikipedia, Lehman's laws). Cursor also reports that an integrator role for quality control "created more bottlenecks than it solved".
9. How do you tell whether your own factory is getting better?
Measure four things from the transcripts and the ticket log: the span of agent work per human touch; the share of human turns that catch an escaped defect; first-pass yield (tickets done with no bug found in review); and ticket size in human-equivalent time. METR times skilled low-context contractors; on five internal PRs contractors took 5 to 18 times longer than the repo's maintainers, so name which human you mean (METR, Measuring AI Ability to Complete Long Software Tasks). A model can estimate time from a ticket's text with moderate rank accuracy: Spearman 0.44 for Sonnet 4.5 against 0.50 for developers' own estimates (Anthropic, Estimating productivity gains); a local 9B model scored 0.345 on 300 issues from the TAWOS public dataset (our test). Good for comparing tickets, too noisy for one ticket.