Answer
How should you run an AI agent for several hours?
As a series of short runs against a written plan, not one continuous session. Duration belongs to the job, not the session.
As a sequence of short runs sharing a written plan and state, rather than one long session. Each run starts with a clean context and the work lives in files, which keeps the last hour as good as the first.
The instinct is to start something and let it work, which produces a session whose later hours are measurably worse than its earlier ones. The mechanism is ordinary: material accumulates, the original brief becomes a smaller share of what is present, and recent steps outweigh the objective. None of it announces itself, so the output of hour four looks like the output of hour one and is not.
The alternative is to let the job be long and the sessions short. A written plan names the stages. Each run reads the plan and the current state, does one stage, writes its result and updates the state, and finishes. The next run starts from files rather than from a conversation, which means it starts sharp. Total elapsed time is the same and the quality does not decay across it.
Three artefacts make this work and they are the same three that make any long work resumable. The plan with stages and their finished conditions. An append-only record of decisions and their reasons. And a current-state file saying where the work is and what the next step is. Everything else — findings, drafts, outputs — goes to its own files and is referenced rather than carried.
The orchestration can be as simple as running the same command repeatedly. Each invocation reads the state, works out what is next and does it, which means the loop needs no memory of its own and can be interrupted at any point. This also makes the work resumable by a person, which matters because at some point somebody will need to see where it got to and continue from there.
Two things need watching over a run of several hours regardless of structure. Cost, which should have a cap rather than a forecast, because the expensive runs are the ones where something went wrong and those are exactly the ones that continue longest. And progress against the plan, since a run that has been working for two hours on a stage estimated at twenty minutes is telling you something, and nothing else will.
One thing to decide before starting: what the agent may do without asking, over a period when nobody is watching. The permission boundary that is comfortable during a supervised ten-minute run is a different proposition across an unattended afternoon, and the answer is usually to keep the run inside a working copy and collect anything consequential for release at the end.
Run the job for hours and the session for minutes, because only one of those two degrades.
Siddharth Sharma, Context Theory
Related questions
Does this apply if the tool handles long sessions well?
The degradation is a property of accumulated context rather than of any product's handling of it, so a tool that manages a long session gracefully is managing the symptom. Where a product compacts automatically the loss is chosen by the compaction rather than by you, which is a reason to prefer written state, not a reason to trust the mechanism.
How long should each run be?
One stage, whatever that takes, and stages should be sized so their output can be checked. If a stage regularly runs long enough for the answers to get vague, it is two stages. The duration is a consequence of the decomposition rather than a target to set.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
2026 speed-to-lead benchmark · verified
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | A continuous session's later hours are measurably worse than its earlier ones because accumulated material reduces the relative weight of the original brief while recent steps gain it, and the output looks identical throughout. | Asking an agent late in a long run to restate its objective and comparing with the brief it received. |
| Software | Consecutive short runs sharing a written plan and state produce the same elapsed duration without quality decay, because each run begins from files rather than from an accumulated conversation. | Running the same body of work continuously and as staged runs, comparing adherence to the brief in the final stage. |
| Response | An orchestration where each invocation reads state, determines the next step and performs it requires no memory of its own, which makes the work interruptible at any point and resumable by a person. | Interrupting the loop mid-run and restarting it to see whether it continues correctly. |
| Buying behaviour | Cost on long runs requires a cap rather than a forecast, because the most expensive runs are those in which something went wrong, and those are also the runs that continue longest. | Comparing the cost distribution of completed long runs against those that encountered a failure. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one