Short answer
The paper 'How Fast Do Agents Rot?' (arXiv:2609.01660) studies long-horizon degradation in LLM agents and reports geometric reliability degradation across dependent steps: per-step success rates compound multiplicatively, so a trajectory of dependent steps loses reliability fast even when every individual step looks solid.
The finding Ernesta Labs took most seriously: bigger context does not fix dependence failure. Degradation is driven by the structure of dependent steps, not by the amount of text the model can hold. More context changes how much the agent can remember, not how reliably a chain of dependencies executes.
The engineering answer is a reliability budget and checkpointing: know your per-step reliability, know how many dependent steps you are asking for, and cut long chains into bounded durable episodes with validated checkpoints between them.
The failure mode: the immortal reasoning chain
The default architecture for long tasks is deceptively simple: keep the agent running, keep appending to its context, and let it reason its way to the end. The implicit assumption is that a reasoning chain which works for five steps will work for five hundred - that the agent's chain of reasoning is immortal, and the only real constraint is how long you can afford to let it run.
This assumption fails quietly. Nothing in the system announces that the chain has gone bad. The agent keeps producing fluent, confident steps long after its grounding in the actual world has decayed. By the time a human notices, the failure is many steps old, and everything downstream of it is contaminated.
The failure mode has a name once you measure it: degradation across dependent steps. Every step that depends on a previous step inherits that step's probability of being wrong. Dependence is the mechanism; long trajectories are just where dependence gets enough room to destroy you.
What the paper actually did
PRIMARY SOURCE RESULT: 'How Fast Do Agents Rot?' (arXiv:2609.01660) is an empirical study of long-horizon degradation in LLM agents. It measures how agent reliability behaves as trajectories get longer and as steps become dependent on earlier steps, rather than evaluating agents on isolated short tasks.
PRIMARY SOURCE RESULT: the paper's central reported finding is geometric reliability degradation across dependent steps. Reliability does not decay linearly with length - it compounds, the way a per-step failure probability compounds across a chain of dependent operations. The paper also reports that increasing context capacity does not repair this dependence failure, which we treat below as its most consequential finding.
We deliberately do not quote specific numbers from the paper in this article. The shape of the result - geometric degradation, context does not fix it - is what transfers to engineering decisions. Exact figures are tied to the paper's specific tasks and harness, and copying them onto your system would be false precision.
What they found: the arithmetic of dependence
The mathematics here is old; the paper's contribution is showing that agents obey it in practice. If each step succeeds with probability p and steps are dependent, then a trajectory of n steps succeeds with roughly p raised to the n-th power. At a per-step success rate of 99%, a hundred dependent steps succeed about 63% of the time. At 95% per step - a rate most teams would celebrate on a demo - a hundred dependent steps succeed about one time in two hundred.
Read that against a commercial horizon. A sales agent that touches a relationship daily for a month executes roughly thirty dependent days of interaction, and each day is not one step but a chain: read state, decide, act, record, verify. The number of dependent steps in a month of real work is not large. It is absurd. And every one of them multiplies into the final reliability.
This is why the paper's framing - rot - is the right one. The agent does not fail at a single identifiable moment. Its reliability decays continuously as the chain lengthens, invisibly, while the agent's output stays fluent the whole time.
Why bigger context does not fix it
PRIMARY SOURCE RESULT: the paper reports that expanded context does not arrest the geometric degradation of dependent steps. This deserves its own section because it kills the industry's favorite assumption.
The intuition behind the assumption is that degradation is a memory problem: the agent forgets earlier steps, so give it a bigger window and it will remember. But dependence failure is not forgetting. The chain of 'this step assumes the last step was correct' is a structural property of the workflow. A model that can hold ten times more text still executes dependent steps one after another, each one inheriting the accumulated probability that something upstream went wrong. More context lets the agent remember more about a chain that is already broken; it does not make the chain unbroken.
The builder-level translation: context size buys you recall, not reliability. If your reliability plan is 'a bigger model with a bigger window,' you do not have a reliability plan.
Limitations, stated plainly
The paper is an empirical study, which means its specific numbers belong to its tasks, its harness, and its models. Long-horizon agent research is young, and a single study does not establish a law of nature; the geometric-degradation finding should be treated as a strong empirical pattern, not a theorem.
The paper studies degradation within trajectories. It does not, by itself, prescribe an architecture, and its checkpointing-relevant implications are ours to draw - see the LABS RECOMMENDATION below, which is Ernesta Labs' engineering position, not the paper's claim. We are also careful about scale: results measured in the paper's experimental setting may be better or worse in a live commercial environment, where counterparties introduce noise the study cannot contain.
Why builders should care: the reliability budget
The paper hands builders a planning tool whether they want it or not: the reliability budget. Take your honest per-step success rate - measured from logs, not from hope - and raise it to the power of your real chain length. That number is your system's reliability budget for the workflow. If it is smaller than what your customer can tolerate, the workflow is not production-ready, no matter how good the demo looked.
Almost every long-horizon system fails this calculation at first, and most teams never run it. They ship a system whose per-step reliability implies an effective lifespan shorter than the relationship it is supposed to maintain, then experience the resulting failures as mysterious flakiness rather than arithmetic.
The good news is that the same arithmetic shows the exit. You cannot improve per-step reliability to perfection, but you can shorten the chains. Bounded episodes with validated checkpoints reset the dependence counter: a failure in episode twelve does not inherit from episode eleven if the checkpoint between them is verified rather than assumed. This converts one long chain with a tiny end-to-end reliability into many short chains whose reliabilities you can measure and improve independently.
Ernesta Labs interpretation
LABS INTERPRETATION: the paper converts a vibe - 'long agents get flaky' - into structure: degradation is geometric, it is driven by dependence, and context capacity does not touch it. Ernesta Labs reads this as the strongest single argument in the field for durable-episode architectures: if the rot is in the chain, cut the chain.
We also read it as a discipline for honesty about claims. Any statement of the form 'our agent is reliable' is meaningless without two numbers attached: over how many dependent steps, and measured how. This article and the sources it cites give us those two questions as a standing policy for evaluating our own work and everyone else's.
What we would implement, and what we would not
LABS RECOMMENDATION: do not model a month-long relationship as one immortal reasoning chain. Model it as bounded durable episodes - short, individually verifiable units of work - separated by checkpoints that validate state before the next episode starts. Concretely: define a maximum dependent-step budget per episode, persist verified state at each episode boundary, and refuse to start a new episode on top of unvalidated state. Keep a measured per-step reliability per episode type, and compute the reliability budget before adding any chain length to a workflow.
What we would not implement: we would not pursue reliability by growing context - bigger windows, longer transcripts, more history in one prompt. The paper's evidence says that does not address the failure mechanism. We would also not implement checkpointing without validation: a 'checkpoint' that just saves whatever the agent last believed, and trusts it on resume, is not a boundary in the dependence chain - it is a bookmark inside the same chain, and the rot passes through it. And we would not accept per-step reliability numbers measured on fresh demo runs as representative of long-horizon behavior; that measurement regime is exactly what this paper shows to be insufficient.
CASE STUDY - NIKO: Experiment Zero runs on bounded episodes
NIKO, the autonomous sales system Ernesta Labs studies, faces the paper's problem in its purest commercial form: a sales relationship unfolds over weeks, across replies that arrive days apart, with every outreach depending on the state of everything that came before. Modeled as one continuous reasoning chain, a month of selling is exactly the immortal chain this article argues against.
NIKO's Experiment Zero is therefore built on bounded episodes with checkpoints: each interaction unit is a short, durable episode whose state is persisted and validated before the next episode begins, instead of one long-lived reasoning context. This is a design commitment, not a result. Ernesta Labs studied the paper; NIKO did not research anything.
And the epistemic line holds as everywhere in this library: a signup is not a customer. A sent email is not a sale. Bounded episodes are designed and implemented in Experiment Zero; whether they produce sustained, reliable long-horizon selling is exactly what has not been demonstrated yet.
DESIGNED: bounded durable episodes with validated checkpoints between them. IMPLEMENTED: the episode boundaries and durable state in Experiment Zero. TESTING: degradation behavior across episodes in real usage. NOT YET PROVEN: that the bounded-episode structure prevents rot in NIKO's domain at commercial reliability.
Practical test: compute your reliability budget and pull the plug
You can run this today with nothing but your logs and a terminal. Step one: from your agent's recent logs, compute an honest per-step success rate for your most common workflow - count every reasoning step, tool call, and state update that could fail, and mark each one succeeded or not. Step two: count the dependent steps in that workflow and raise your success rate to that power. That number is your reliability budget. Compare it to the reliability your use case actually requires. Most teams doing this for the first time discover their budget is several orders of magnitude too small.
Step three, the harder half: take a running long task and kill the process mid-stream - or deploy a code change mid-run, which is the same thing. Then check what happens on resume. If the system restarts from a validated checkpoint and re-verifies state before acting, you have bounded episodes. If it resumes from whatever was in the context window, or replays a transcript and assumes it is true, you have an immortal chain with a bookmark in it - and the paper says precisely which one of those rots.
What remains unknown
- How well geometric-degradation findings from the paper's experimental tasks transfer to commercial domains like sales, where human counterparties add noise the study cannot contain.
- The right maximum episode length - where the trade-off between checkpoint overhead and dependence-chain risk actually lands in production.
- What validation rigor a checkpoint needs in order to truly cut the dependence chain, versus merely bookmarking a contaminated one.
- Whether NIKO's bounded-episode design measurably reduces long-horizon degradation - designed and implemented, but not yet demonstrated in commercial outcomes.