The Correction That Dies With the Session: Toward an Operating Model for Governing AI Agents in Production

An engineer catches an agent importing a library that's been deprecated for two versions. She corrects it, explains why, and the agent produces clean code for the rest of the session. Next morning, a fresh session starts, and the agent imports the same deprecated library again. Nothing was learned. The correction lived exactly as long as the context window that held it, then it was gone.

Anyone running agents against real production code has hit this enough times to stop being surprised by it. What's less obvious is why it keeps happening even as the infrastructure around agent autonomy gets more capable by the month. A recent argument names the pattern directly: when an expert corrects an agent's error, the correction usually dies with the session, and the error class returns. The paper frames the fix as an operations gap. Mechanisms for persisting corrections already exist and are shipping, in system prompts, retrieval layers, evaluation suites. What's missing is the discipline for governing them once they exist, deciding who owns a correction and how long it stays valid.

Governance as an operations layer

Storing a correction is easy now. Write it into a system prompt, drop it into a retrieval index the agent queries before acting, fold it into an evaluation suite that gates deployment, or fine-tune on it directly. Open-source agent infrastructure has caught up to this need: projects like OpenBot give agents a browser, files, and tools, with every action decided before it happens and recorded after. That's an audit trail, and it's real infrastructure. But an audit trail tells you what an agent did. It doesn't tell you whether the correction you filed last month is still doing its job, whether it's being ignored, or whether it's now causing a new failure somewhere else in the system.

That's the gap the paper names directly: versioning with provenance, recurrence monitoring, counter-metrics, and retirement of stale rules. None of these are exotic. Software engineering solved versioning and provenance for code decades ago; you know who wrote a line, when, and why, because git tells you. Corrections to agent behavior get none of that treatment in most shops. They live as a paragraph in a prompt file that someone edited on a Tuesday, with no record of what evidence prompted it, no owner, and no expiry.

Correcting a distribution, not a single output

Part of the reason a single correction feels insufficient is that agent output isn't a fixed point, it's a distribution. A companion argument makes this explicit: frontier models have largely saturated accuracy, meaning their mean output already lands on the target for most well-specified tasks. What separates one system from another now is precision, how tightly the outputs cluster around that target across repeated, near-identical runs. If accuracy is solved and precision is the variable, a correction that fixes one phrasing of a task may not narrow the distribution for a different phrasing of the same task. The deprecated-library mistake might vanish for "add a logging import" and reappear for "wire up telemetry," because to the model these are different regions of the same distribution.

Recurrence monitoring means tracking whether the error class shows up again under a different surface form, using a taxonomy of failure types rather than a list of exact strings to search for. Silence isn't proof the correction worked. It might mean nobody's looking.

What an operating model requires

A workable version of this needs four things running as ongoing operations, not a one-time setup:

Versioning with provenance. Every correction gets an owner, a timestamp, the evidence that prompted it (the failing transcript, the ticket, the incident), and a diff against the prior version. Treat the correction file the way you'd treat a config change: reviewable, revertible, attributable.

Recurrence monitoring. Someone owns a dashboard, or at minimum a recurring query, checking whether the failure mode a correction targeted is showing up again, in whatever surface form it takes now.

Counter-metrics. Corrections have a cost most teams don't measure: an agent told "never do X" sometimes refuses X in a context where X was correct. Without a counter-metric tracking false-positive refusals or over-cautious behavior, you can't tell if a correction that reduced one error introduced a bigger one elsewhere.

Retirement. Correction files accumulate. Some go obsolete when the underlying model updates and the failure mode disappears on its own. Left in place, stale corrections bloat the context and contradict newer guidance. Somebody needs the authority to sunset a rule on a schedule, not just after it visibly fails.

None of this is glamorous work, and none of it fits neatly into a sprint. It looks more like the job of running a database migration policy or a security patch cadence: an operations function with an owner and a review cycle, not an engineering task you close out and forget.

What would change this

If model providers start shipping systematic error-class fixes at the training level fast enough that persisted corrections go obsolete before anyone finishes writing the governance layer around them, the cost-benefit case here weakens. That's a real possibility: base model updates already fix some behaviors that used to require manual correction. The argument holds only as long as correction volume stays below what an updated model can absorb on its own. Once a shop runs agents against enough internal systems, new error classes will appear faster than any single model release can absorb, and that's the condition under which an operating model like this one earns its cost.

The alternative, doing nothing, has a cost too. It means the senior engineer who caught the deprecated import today will catch it again next month, and again the month after, because the correction she wrote never outlived the session it was written in.