We test AI agents like sprinters: how fast and how accurate on one short task. But the work we really want from them — fix a bug across a big codebase, run a research loop for hours, use a computer all afternoon — is a marathon, not a sprint. And marathons aren’t won by the fastest runner. They’re won by the one who paces themselves and doesn’t fall apart near the end.
Here’s the encouraging part. Today’s best models can work on their own for about 5 hours before they need help — and that number keeps doubling every few months. But there’s a catch worth knowing: the length of task a model can finish reliably (8 times out of 10) is about 5× shorter than the length it can finish just half the time. So “it can do a 5-hour task” really means “it can do a 1-hour task you can count on.” Closing that gap is the whole opportunity.
01Why agents run out of steam
Three things make long tasks hard. Each one has a fix.
1. Small mistakes pile up
A step that works 99% of the time sounds great — until you chain a few hundred of them together. Miss once and the whole run can end.
| Number of steps | Chance the whole task finishes |
|---|---|
| 10 | 90% |
| 50 | 61% |
| 100 | 37% |
| 200 | 13% |
The fix is to catch that first slip early — before it snowballs. That’s what good checkpoints are for.
› Go deeper: real mistakes are even worse than the table
That table assumes every mistake is independent. Real agents are worse: one wrong move makes the next wrong move more likely. In a 2026 study across 10 models, success fell from 76% on short tasks to 50% on long ones — a bit faster than the clean math predicts. One paper even measured it: a single off-track action raises the odds the next one is off-track by +23 points. The takeaway is the same — stop the first error and the cascade never starts.
2. A full memory slows it down
An agent keeps a running memory of everything it has done. The fuller that memory gets, the more its accuracy quietly drifts down — even on easy work. So a bigger memory isn’t automatically better. What you keep in it is a dial you control.
› Go deeper: the evidence that long context hurts
Researchers at Chroma tested 18 top models and found every one got worse as its input grew — eventually slipping even on a plain copy-the-text task, where no thinking is required. An earlier result called “Lost in the Middle” showed the same thing: information parked in the middle of a long context gets under-used. Length alone is a load the model has to carry.
3. Doing it once isn’t doing it every time
There’s a big gap between finishing a task once and finishing it reliably. Running one fast mile isn’t the same as holding pace for all 26 — and consistency is the part you can train for.
› Go deeper: the consistency numbers
On one agent benchmark (τ-bench), GPT-4o finished the task on a single try about 61% of the time — but got it right on all 8 identical tries only about 25% of the time. If you’re shipping something people rely on, that second number is the one that matters.
02How a good agent runs the race
Here’s the fun part. Runners have spent decades learning how to survive a long race — and almost every trick has a direct match in how a good agent should work. Here’s the cheat sheet, with the proof in the last column.
| Marathon technique | The sports science | The agent move | Evidence it works |
|---|---|---|---|
| Even / negative splits | Going out too fast burns glycogen early and forces a collapse later | Don’t front-load; take steady, verified steps instead of one greedy mega-action | Even-paced races produce faster times and more PRs |
| Fuel, then resupply | Carb-load before, then take gels during — the gut absorbs only so much at once | Manage the context “tank”: don’t dump everything in; top up with compaction + external memory notes as you go | Context editing + memory tool: +39% on long-horizon evals (Anthropic) |
| Know where the wall is | Glycogen ≈ 2,000 kcal ≈ 20 miles — the wall is fuel-budget math, not bad luck | Treat the window as a finite fuel tank — forecast when it fills and checkpoint before you bonk | Chroma “Context Rot”: reliability tracks how full the tank is |
| Aid stations | Refuel and check in at every mile marker | Checkpoint + verify each segment with a real test or tool — not just “double-check yourself” | Step-by-step verification solves 78% of MATH; Reflexion 91% vs 80% with a feedback signal |
| Taper to peak | Cutting training volume 40–60% before race day adds 2–3% | Less context = higher reliability. Prune aggressively; a clean working set beats a bloated one | My simulation below: resetting context beat carrying it, every time |
| Relay team + pacers | Fresh legs per leg; drafting cuts ~6% of energy cost | Orchestrator + fresh sub-agents, each with a clean, isolated context window | Multi-agent beat a single agent by +90.2% (Anthropic) |
| Train the engine, not top speed | Lactate threshold (the % of max you can hold) predicts marathon time better than raw VO₂max | Optimize for reliability@k, not peak pass@1. Deployable means sustained | The 61% → 25% τ-bench gap is exactly this |
| Chunk it + self-monitor | Elites split 26.2 miles into segments and read their body to hold pace | Decompose long tasks into sub-goals; run a watcher / critic that catches drift early | A watcher is what neutralizes the +23-point cascade |
03I tested it with a simulation
To check the idea, I ran a simple simulation — 20,000 mock tasks of growing length — and raced three strategies against each other:
- Sprint — one long run, no checkpoints.
- Paced — checkpoints and retries, but it keeps its whole memory.
- Marathon — checkpoints plus a fresh start with a clean memory for each leg.
N=40 Sprint 0% | Paced 3% | Marathon 92%
N=160 Sprint 0% | Paced 0% | Marathon 72%
N=320 Sprint 0% | Paced 0% | Marathon 53%
Two things stand out. First, the marathon strategy’s lead grows the longer the task — on a short job nobody needs pacing, but on a long one it’s the only thing that finishes. Second, and more surprising: checkpoints alone aren’t enough. “Paced” still fades, because retrying a step while carrying a full memory is like refueling without ever resting your legs. The winning move is to reset — a fresh runner, a clean memory, and a short summary handed off like a baton. That’s the strongest case for splitting long jobs across fresh sub-agents instead of one long-running agent.
› Go deeper: how the simulation works
It’s a Monte-Carlo model (20,000 trials per setting) of a task with N steps, built with the two forces from Section 1: a run can fail outright on a bad step, and each step’s success rate drops as the memory fills up. Sprint runs straight through with a growing memory. Paced checkpoints and retries every few steps but never clears its memory. Marathon does the same checkpoints and resets the memory each segment by handing off to a fresh agent with only a short summary. The full script and plot are reproducible — the numbers above are the raw output.
04Where pacing doesn’t save you
Pacing is powerful, but it isn’t magic. Three honest limits:
· On really long tasks, even the marathon agent drops to a coin-flip. Pacing buys a lot of room — but past a point you also need a better model (more reliable per step) or a simpler task (broken into cleaner pieces).
· Running a relay is expensive. Using fresh sub-agents can burn around 15× the tokens of a single agent, so it pays off mainly when the work splits into parts that can run in parallel. For tightly linked work, one strong agent with a tidy memory often wins. (It’s an active debate.)
· “Check your work” needs something real to check against. Asking an agent to review itself helps most when there’s a test or a known answer behind it. Without one, it can just confirm its own mistakes.
The takeaway
Stop optimizing your agent’s top speed. Optimize its fuel curve. Short legs. Hard checkpoints with real verification. Ruthless context resets. Fresh sub-agents spawned on demand and retired when spent. Effort spent where the course is hard, conserved where it’s easy.
The agents that win the long tasks won’t be the smartest. They’ll be the ones that paced.