Your Agent Harness Rots Faster Than Your Model: The Expiration Rule

Every production AI engineering team talks about model drift, yet the most expensive degradation I find in codebase audits is harness rot. Over twelve months of shipping an agent, engineers accumulate thousands of lines of compensating code: three-paragraph system-prompt warnings yelling at the model never to invent tool parameters, regex post-processors that repair malformed JSON, forced context resets every ten turns, and hard caps on how many files an agent may inspect before proposing a patch. Every one of those patches was added for a legitimate reason during an incident review to survive a specific model snapshot’s failure mode. The problem arrives six months later when you upgrade the foundation model, keep the old harness intact, and discover that your own scaffolding is now capping the new model at the old model’s ceiling.

Anthropic documented a textbook example of this failure mode in its spring 2026 engineering retrospective on harness design. Earlier coding harnesses built around Claude Sonnet 4.5 suffered from what the team called “context anxiety”: as the context window filled up, the model began taking shortcuts and declaring tasks finished prematurely. To survive that quirk, engineers wired forced context resets and structured sprint-decomposition rails into the harness. When they later upgraded to Claude Opus 4.5, which sustained long-horizon coherence without panicking as the window grew, the forced context resets became dead weight that added orchestration complexity and overhead; when Opus 4.6 arrived, the sprint-decomposition scaffolding became unnecessary too. The workarounds had outlived the model quirks they were written to fix.

Why does dead harness logic survive across model generations in otherwise disciplined engineering organizations? Because teams treat model weights as versioned dependencies while treating prompts, context-compilation heuristics , and orchestration rails as permanent application architecture. Once a prompt reminder or a forced decomposition step merges into main, nobody remembers whether it encodes an immutable domain invariant (such as double-entry accounting rules or regulatory disclosures) or a temporary crutch for a June 2025 model snapshot that struggled with nested tool schemas. Afraid of breaking production, engineers only ever append to the harness, turning the runtime into a geological sediment of obsolete anxieties.

The cure is to draw a hard architectural line between domain invariants and model compensations, and to govern every compensation with an explicit expiration rule. Enforce a Compensation Register directly in your codebase alongside the harness configuration. Any time an engineer adds a non-business-logic heuristic (a prompt rule compensating for tool-calling quirks, a retry wrapper for formatting errors, a forced summarization threshold, or a synthetic planner step), that heuristic must be wrapped in a named feature flag and registered with four required metadata fields: owner, target_model_snapshot, failure_mode_compensated, and measured_token_or_latency_tax. If a piece of harness code does not enforce a business requirement and lacks an entry in the register, it does not pass code review.

Registration alone is paperwork unless it is wired to an automated test oracle, which brings in the second component: Counterfactual Canary Evals. Every entry in the Compensation Register must link to the exact slice of your golden evaluation suite (the three to ten reproducible production traces) that failed before the workaround was introduced. Unlike standard CI runs that only test the default configuration, your evaluation runner must support counterfactual execution: running that linked canary slice with the compensation’s feature flag toggled off. That links every line of defensive scaffolding to a live empirical falsifier rather than team folklore.

The loop closes with the Model-Upgrade Deletion Gate. Whenever your team evaluates a candidate model snapshot for promotion, you do not merely run your evaluation suite with the existing harness turned on. First, execute a per-flag ablation pass that runs each Counterfactual Canary slice against the candidate model with its corresponding compensation flag disabled to identify candidate workarounds that appear obsolete. Second, because two overlapping compensations (such as a schema-retry loop and a regex JSON repairer) can mask each other when tested one at a time, disable the entire candidate deletion set together and run a joint verification pass across all canary slices and the full regression suite, retaining only the minimal subset needed when an interaction fails. Every workaround in the verified deletion set is removed in the same pull request that promotes the new model snapshot, gated on your per-task pass^k release bar . Building a system the model cannot break means keeping the safety rails that protect your business invariants while ruthlessly stripping the crutches that only protected yesterday’s weights. Open your agent’s system prompt and orchestrator loop today: how many rules and retry shims in that file can you trace to a specific model snapshot, and how many would you delete tomorrow if you ran an ablation test against your current model?