Long-Running Work
Agent runs measured in hours rather than seconds: the workload class that makes every harness and deployment decision matter.

The workload class
A chat completion lives for seconds; a long-running agent works for hours across hundreds of tool calls, unattended. The newest builder cohort treats this as a baseline requirement: in YC's Summer 2026 batch, 17 percent of companies describe long-running, scheduled, or background execution, with machine0 stating the shape plainly in its launch material: "a coding agent debugging a complex issue runs 4-8 hours," and Rex describing "agents run continuously in the background."
The published runs
The customer corpus has real numbers on how long production runs already go:
- Rakuten reports "7 hours of sustained autonomous coding on a complex open-source refactoring project" in vLLM, a 12.5 million line codebase, with the result at "99.9% numerical accuracy" against the reference method. The engineer's account: "I didn't write any code during those seven hours. I just provided occasional guidance." (source)
- Replit reports "Sessions run for 6+ hours without human input, a 10x improvement over previous agent capabilities," and a power user who "generated more than 36,000 lines of production-ready code in a single Agent 4 session" over "roughly 400 minutes of autonomous runtime." (source)
- OffDeal "Built a buyer sourcing agent that runs autonomously for up to 4 hours, researching potential acquirers across 10 different sourcing methods." (source)
- Tasklet runs "long-running, unattended multi-step business automations in the cloud" as its entire product, at "450,000 agent actions executed per day across all customer agents." (source)
What hours-long runs demand
Every concept in this lexicon gets stress-tested by run length. Anthropic's Effective harnesses for long-running agents (November 2025) supplies the harness-side toolkit: an initializer agent that sets up the environment, progress files the agent maintains as an external memory of where it is, and environment management so a dying process does not end the mission. Its context-engineering guidance adds compaction, since no window holds an eight-hour transcript, and warns about context rot, the quality decay of an ever-fuller window. Self-correction is what keeps hour six on course with hour one, and silent failure is what an unwatched run risks the whole time.
The deployment side is just as implicated: a session that runs for hours needs durable state that survives a restart, capacity held for the duration, and, if it runs on a clock, a schedule with per-firing run records.
Why it is the decisive workload
Short tasks forgive weak architecture; long ones do not. This is the workload class where the harness and deployment choice stops being a preference and becomes the product, which is why the stories above cluster on the Agent SDK and Managed Agents rather than hand-rolled loops. If your roadmap ends at runs measured in hours, the architecture conversation starts here.
Further Reading
- The Harness: the loop that has to survive the hours.
- The Deployment: the state and capacity underneath.
- Memory Stores and Scheduled Deployments: continuity across and between runs.
- Self-Correction Mid-Task: what makes run length usable.