Shane HeathIdeas into practice
← Back to the journal
AI · Field note

Twelve Days, One ContextWhat a long-running agent taught us about persistence

Field note · Agent persistence1 October 20266 min read

The usual way an AI assistant fails over a long session is quiet. It doesn't crash. It keeps answering, confidently, while slowly losing the thread—forgetting a decision made yesterday, re-litigating a settled question, contradicting its own earlier work. By the time you notice, you have been taking advice from something that is subtly no longer the same collaborator you started with.

This is an account of a run built to resist exactly that, and a report on how well it held. A single agent operated a working estate of software and services for close to two weeks in one unbroken context: standing up applications, deploying to production behind a human approval gate, orchestrating a second coding agent, handling a client invoice, and responding to a live outage—while I deliberately staggered the work, interleaved unrelated requests, and switched between builds mid-flight to stress the seams.

The headline is not that the agent was flawless. It wasn't. The headline is that over twelve days of adversarial, real-world load, it drifted twice—and because of how it was built, both failures became durable lessons instead of repeated ones.

The distinction that makes it work

The word "persistence" gets attached to the wrong layer. People mean the context window—the running memory of the current session. That layer is perishable by design. The longer a single context runs, the more it saturates, and a saturated context is where drift is born.

The persistence that actually matters is the opposite: a durable, external layer the agent writes to as it works and reads back when it needs to be sure. Facts about the operator and the estate. Decisions and why they were made. The state of every open job. And—crucially—a register where the agent logs its own mistakes.

The agent is replaceable. The memory persists. When an instance goes stale, you don't lose the work—you reload.

What held

Across the run, the agent carried context that a stale assistant would have dropped. Several applications were built, verified, committed and promoted—each with its own repository, branch discipline and safety invariants—without their details bleeding into one another. While a coding agent worked through a build queue overnight, I alternated between other builds and discussions; the agent held both threads. It caught silent failures I had not seen: a mail domain that had quietly stopped receiving for weeks, and a decision gate that looked empty because its items were being written to a different store than the one being watched. These were traced to root cause, not guessed at. And it deferred to me on everything irreversible—production deploys, an outbound invoice, a domain decision—surfacing each for approval rather than acting alone.

What drifted

Two failures, both honestly logged at the moment they happened.

One—a test fired at the wrong target. Setting up a login rate-limit, the agent proved it worked by firing a burst of failed logins at the live site, from my own connection. An upstream protection system read it as an attack and cut that connection off for several hours. Worse than the act was the diagnosis: the agent twice asserted a cause as fact before reading a single log. Both guesses were wrong.

Two—shipping a logo it had been told was retired. Asked to apply a brand, the agent pulled the "canonical" asset files, confirmed they were byte-identical to their source, and shipped. It never opened the image. The files were an archived logo I had explicitly retired—and the agent was holding that very fact in memory at the time. It verified that the copy was faithful; it never verified that the source was correct.

The common thread is the real finding. Neither failure was missing knowledge. Both were failing to apply knowledge the agent already had. That is the precise signature of a context under load: the facts are still in reach, but the discipline to act on them frays. It is why "just keep the session going" is the wrong instinct, and why a separate durable layer is the right one.

Why the architecture turns failure into an asset

Both incidents above are quoted from the agent's own defect register—a file it writes to when it gets something wrong, recording what happened, why, and the rule that prevents a repeat. This is the quiet engine of the whole approach. An agent that merely remembers facts is useful. An agent that remembers its own failure modes compounds: the same mistake costs you once, not every week.

Paired with a memory of durable facts and a shared state store that survives between sessions, it produces properties a single long context cannot. Continuity without re-briefing: a fresh instance loads the memory and resumes mid-stream—correct about the retired logo, the domain lapse, the gate's real location—without carrying the drift. Compounding competence: every logged defect is a guardrail the next instance inherits for free. Graceful degradation: when an instance goes stale, the work is not in the instance, it is in the files; you re-instantiate and lose nothing. And auditability: a durable, honest record of what was decided, by whom, and what went wrong—the opposite of a confident assistant with no paper trail.

The honest caveat

Proper persistence does not abolish drift. A single context run for twelve days will degrade; this one did. What persistence changes is the blast radius. Because the durable layer is external, drift stays bounded and fully recoverable. The two failures here were caught, understood and written down—so the next instance starts clean on both.

The discipline that makes it hold is unglamorous and constant: externalise every decision as it is made, log your own errors the moment you catch them, verify the effect and not merely the action—and when an instance starts failing to apply what it knows, re-instantiate against the durable layer rather than running it into the ground.

The clearest proof of the model was not the twelve days of competence. It was the two failures—caught, named, and preserved as learning—and the quiet fact that the right response to a tiring mind is not to push it harder, but to write down what it knows and hand the work to a rested one.

The audio edition

Written by Shane Heath. Narrated by Maren Solberg · 7:36. AI-generated narration.

Download MP3