While at Cal, I had the chance to visit the A-Lab, an autonomous research laboratory built to accelerate the discovery of sustainable materials. Its robots could operate around the clock, adjusting subsequent experiments based on earlier results. What interested me wasn't whether the system could outperform a scientist, but the architecture: machines could do work, interpret the results, and direct what other machines did next.
Software development is beginning to ask a similar question: What has to be true for a software agent to work autonomously for 24 hours?
Only a year ago, that question would have sounded premature. In early 2026, Anthropic reported that the longest 0.1% of Claude Code interactions had nearly doubled from under 25 minutes to more than 45 minutes in just three months. Since then, developers have begun handing off far longer tasks. Cursor reports that its long-running coding agents commonly operate for more than a day, with one user describing a 52-hour task completed without supervision.
So perhaps 24 hours is no longer the right threshold. The more important question is: what has to be true for an agent to work autonomously for 24 hours on the messy software projects that actually exist inside an enterprise?
Consider four examples:
✦ Delivery Hero: Uses its Herogen coding agent to complete engineering tickets - locating relevant code, implementing changes, testing and fixing issues, and submitting the work for review.
✦ Spotify: Uses agents for large-scale code migrations - identifying code on older frameworks, rewriting it to newer standards, testing changes, and submitting them for review.
✦ Sentry: Uses agents to investigate and fix software errors - analyzing error data, identifying the responsible code, implementing a fix, and submitting it for review.
✦ Caylent: Uses hundreds of agents in parallel for large enterprise migrations - dividing thousands of database procedures among agents, rewriting them for new systems, and validating the converted software.
Across these cases, companies are trusting agents with bounded software work: implementing engineering tickets, rewriting existing code into new formats, diagnosing and repairing production errors, and executing migrations across large numbers of files or systems.
One layer down, companies are already building infrastructure around these agents to address the problems that emerge as autonomy increases. Spotify built Xirp to cut duplicated work, inconsistent outputs, and wasted tokens, including agents rediscovering context others had already learned. JPMorgan, focused on access control and auditability, has developed sandboxed environments that limit what agents can access and change while preserving a record of their actions.
So what’s next?
Earlier this year, Stripe tested agents on complete payment integrations and found that some of the remaining failures had nothing to do with writing code. In one test, agents upgraded Stripe's SDK but mistook an error caused by invalid test data for proof that their work was functioning. In another, an agent testing an upgraded Checkout integration accidentally selected the frame around the form while entering address and card details, preventing it from typing into the fields. Rather than clicking elsewhere or refreshing the page, the agent concluded it was stuck.
Stripe's tests highlight two separate capabilities. The first is evaluation: knowing whether the work actually achieved its goal. The second is recovery: getting back on track when execution leaves the expected path. A-Lab ran into the first problem. Researchers later challenged some of its reported discoveries, arguing that its automated analysis had misidentified experimental results. A closed loop is only as trustworthy as the step that interprets the results.
Better models will likely solve many failures like these. But longer-running work introduces a different problem. An agent working alone can keep more of the task in its own context; a group of agents working for days cannot rely on each agent independently knowing what the others have learned or changed. If one agent discovers that an API needs to change, that decision may invalidate work already underway elsewhere. Someone - or something - has to record the decision, identify the affected tasks, and redirect them. As the number and duration of parallel tasks increase, coordination becomes a problem separate from the intelligence of any individual agent.
There is another reason the volume of this work could grow quickly. As agents lower the cost of development, companies can increasingly build small, low-risk, company-specific software that previously would not have justified engineering resources. A finance team might automate a peculiar reconciliation process; an operations team might connect three internal systems; a sales team might build around its own CRM workflow. The cheaper software becomes to produce, the smaller the problem worth solving with software.
This changes what is worth building a software company around. If customers can generate narrow workflows internally, simply turning those workflows into software becomes less defensible. The more durable opportunities may sit around that software: infrastructure for creating and managing it, proprietary data and networks that cannot be generated on demand, or systems important enough that customers would rather outsource the responsibility than maintain them themselves.
The first of these becomes especially important as companies hand more development to agents. Today, much of that coordination still sits with engineers and technical program managers. Every case study above eventually reaches some version of the same step: submit the work for review. Better models may push that review further out, but if agents produce more work in parallel, people cannot remain the routing layer between every task indefinitely. The question behind 24-hour autonomy is therefore not simply how long an agent can keep writing code, but whether the broader system can manage that work without constant oversight.