The fifty-percent cliff: why agents fail at the second hour

Last month Philippe Laban, Tobias Schnabel, and Jennifer Neville at Microsoft Research published DELEGATE-52 — a benchmark for what happens when you hand a long task to an agent and walk away.

The result is the most honest thing I have read about long-running agents in 2026: frontier models corrupt 25% of document content by the end of long workflows, and giving them tools makes it worse by another 6%. Only one of fifty-two professional domains crossed the 98% readiness bar. That domain was Python programming. Everything else — crystallography, music notation, legal drafting, financial modeling — falls off the cliff somewhere between turn ten and turn twenty.

The conventional response is "bigger context windows will fix it." That response is wrong.

The finding everyone is misreading

The Microsoft paper is being shared with the takeaway "models need more context." That is not what the paper says.

Read it carefully and the actual finding is this: stronger models do not avoid small errors better; they delay critical failures and experience them in fewer, larger steps. Gemini 3.1 Pro, Claude 4.6 Opus, and GPT 5.4 are the three frontier models tested. They all converge to roughly the same 75% document integrity at turn 20 — not because they forget more, but because when an error finally lands, it lands hard.

Errors are not gradual. They are punctuated. A model holds the line for fifteen turns and then loses ten to thirty points in a single round-trip. That's not a context window problem. That's a hand-off problem.

Why agentic tool use makes it worse

Here is the part of the paper that should have been the headline:

"When operated agentically with tools, the four tested models perform worse, incurring an average additional degradation of 6 percent by the end of simulation."

More tools means more places to silently lose state. Every tool call is a new hand-off contract. Every hand-off is a new place where the model decides "this output is good enough to pass to the next step" and is wrong.

The teams shipping long-running agents in 2026 are not solving this by adding tools. They are solving it by adding structure between tools.

What the production teams actually do

I have watched four patterns work in production, and one of them is the one nobody talks about.

1. They separate the generator from the evaluator. A model that wrote a thing is the worst possible judge of whether it is done. Anthropic's outcomes feature, shipped at Code with Claude on May 6, lifted task success by up to 10 points for Wisedocs and 8.4% on .docx outputs by making a separate model judge completion. The generator never gets to declare done.

2. They write checkpoints, not memory. LangGraph writes a checkpoint at every super-step keyed by thread_id. If a worker crashes, another picks up the run from the latest checkpoint. This is not memory in the brain-of-the-agent sense. It is durable state in the database-of-the-runtime sense.

3. They consolidate between sessions, not during them. Anthropic's "Dreaming," shipped the same week, is a scheduled process that runs after an agent finishes a job — reads the session, finds recurring mistakes, and writes them back into the memory store for the next session. Harvey reported roughly 6x task-completion improvement after enabling it. Wisedocs cut document review time 50%. The pattern is not "remember more inside the run." It is "consolidate between runs."

4. They treat the runtime as the supervisor. Temporal raised $300M in February 2026 at a $5B valuation specifically because the durable-execution pattern from 1985 is the answer to the 2026 problem. The model is the function. The runtime is what re-runs the function from the right place when the function panics.

The 1985 pattern

If the answer is durable execution, supervised retries, and explicit hand-off contracts, that should sound familiar.

It is systemd. It is supervisord. It is kubectl rollout. We solved the problem of "how do you keep a long-running process alive across crashes, restarts, and partial failures" in the 1980s, refined it in the cloud era, and are now relearning it because we keep treating the model as the runtime.

The model is not the runtime. The model is a function the runtime calls. That function happens to be probabilistic and occasionally lies about whether it succeeded. The job of the runtime is to assume that and design around it: explicit completion criteria, append-only event logs, generator/evaluator separation, deterministic re-entry from checkpoints.

runtime:
  checkpoint_every: tool_call
  on_crash: resume_from_last
  evaluator:
    separate_model: true
    must_pass: ["completion_criteria_met", "no_silent_corruption"]
  event_log:
    append_only: true
    storage: postgres

When you write the agent's surrounding contract like that, the 50% cliff disappears — not because the model got smarter, but because the runtime stopped trusting the model to know when it is done.

What this means for your roadmap

If you are building agents that run for more than fifteen minutes, three things are non-negotiable in 2026:

1. A checkpoint store the agent does not write to directly. The runtime writes after each tool call, the agent never sees the write.
2. An evaluator that is a different model from the generator. Self-grading is the failure mode.
3. A supervisor process that owns the retry policy. When a checkpoint fails verification, the supervisor decides to re-run, escalate, or stop — not the agent.

The agents that survive past hour two in 2026 will not be the ones with the largest context windows. They will be the ones running inside a runtime that assumes the model is going to lie, and is structured to catch the lie before the document is corrupted.

Long-running agents are the new long-running processes. The Unix folks solved this problem forty years ago. The 2026 agent stack is going to either rediscover the answer or keep falling off the cliff at turn twenty.