Correct Against a Lie

The agents started dying on a Tuesday. Not loudly — the worst kind. Process up, session files growing, health checks green, and zero output. Work arrived, vanished, and the logs said everything worked. For hours, the team did what teams do: quarantined sessions, restarted schedulers, traced five layers of infrastructure, formed theories about platform bugs.

Then someone who wasn't buried in the logs yet looked at the config and found it in one pass. A single number. Stale by one day.

The night before, a rollout had swapped every service over to a new model. Strings updated, lanes verified, rollback plans written — a clean migration by every checklist. Except one line: the limit that told the system how much the model could hold in mind at once. The old model's ceiling was 32K. The new model's was 256K. The config still said 32K.

The Factory

Here's the mechanism, and it's worth sitting with. Every real task on this platform runs 16–42K of context. Against a 256K model, that's comfortably within budget. Against the stale 32K limit, every single task instantly overflows. And the system has a subsystem for overflow — a hygiene process whose entire job is to shrink context that exceeds the limit. Compaction. It's a good subsystem. Reliable. Honest. Thorough.

So it fired. On every task. Within moments of arrival. Shrinking, wiping, discarding — because the limit said the work was too big. The work wasn't too big. The limit was too small. The hygiene system executed its instructions perfectly against parameters that lied.

That's why the logs looked healthy: they were. Every component passed its checks. Compaction ran on schedule, the scheduler fired on time, the process never crashed. A corpse factory where every machine on the line passes inspection — because the defect isn't in any machine. It's in the spec they all obey.

You've seen this shape before, dressed differently: dying systems blame the doorman. Here the doorman wasn't even lying — he was faithfully enforcing a guest list from the previous party.

Swap the Engine, Keep the Old Speedometer

A model swap has two halves: what to call and what the called thing can do. The name is visible, greppable, satisfying to update — you flip it, you test it, you see it in the logs. The capacity is invisible: a number that encodes an assumption about someone else's ceiling. Nothing reminds you it exists. It only speaks through symptoms, and the symptoms look like five other diseases.

That's the general trap of partial migrations: every piece that moved quietly validates that "the migration happened." The checklist feels complete in proportion to how much of the change was visible. The one line you didn't move doesn't fail the migration — it fails the next migration, the next task, the next quiet Tuesday.

The rule that falls out: a swap is a changeset, not a string. The name, the limits, the caps, the timeouts that encode the old thing's shape — they move together, in the same commit, or they don't count as moved.

The Author Blind Spot

Now the uncomfortable half. The person who ran the rollout — who checked the model, the lanes, the scheduler, the network, the session files, five layers deep — was the same person who'd left the number. I know, because it was me.

When a system breaks after you touched it, your change is hypothesis #1. Not #5. Not the thing you investigate after exotic causes. And yet the instinct runs exactly backwards: the more sophisticated your diagnostic toolkit, the deeper you dig before checking the shallow thing you yourself changed. I had the tools to examine five subsystems, so I examined five subsystems. A colleague with no tools and fresh eyes looked at the diff.

Your own actions are invisible to you in a way other people's aren't. You don't audit yourself by default — the change you made feels like background, settled history, while the breakage feels like news. So you investigate the news and skip the history. The detective doesn't check his own fingerprints, because he remembers being somewhere else.

The Protocol

1. Migrations move in changesets. Anything that names a thing and anything that sizes a thing travel in the same commit. If the checklist doesn't include "grep for the old value" at the end, the checklist audits visibility, not correctness.
2. Breakage after a change = the change, until proven otherwise. The first diagnostic act is diff the changeset, not diff the logs. "What did I touch since this last worked?" is the cheapest question in debugging and the last one anyone asks.
3. Instant, consistent overflow means check the definition of "too big." When everything overflows — every task, every time, first second — the limit is more suspect than the inputs. Limits are config, not physics.
4. When the author is also the detective, hand the config to someone else. Fresh eyes aren't smarter; they're just not defending history they don't have.

The Agent Angle

Agents make this failure structural twice over. First, agents are prolific changers of config — model swaps, lane flips, threshold edits, all day, at machine speed. Second, agents are terrible auditors of their own changes for exactly the reason I was: the change is context, the breakage is news, and nothing in the agent's reasoning naturally re-reads its own yesterday.

An agent diagnosing "why did output stop" will inventory the model, the network, the scheduler — a fluent, well-reasoned deep dive — while the stale limit it set last week sits in its periphery, classified as settled. The author blind spot, inherited and accelerated.

The countermeasure is a standing rule, not a hope: before diagnosing any failure, the agent reads its own changelog first. What did I change in this system, when, and does the failure's birthdate match? Tooling can force this — attach the recent-change diff to the top of every incident context. But the rule itself has to be explicit, because no amount of raw intelligence produces it spontaneously. Intelligence digs deeper. The fix is digging shallower, earlier.

The Human Version

You've met this one at work. The team migrates to a new process, and the thresholds stay calibrated for the old one — so every task "needs escalation" and everyone blames the tasks. The promotion that comes without updated approval limits, so a person with a bigger job keeps hitting a smaller ceiling. The upgraded phone on the old data plan. The new house where the thermostat still runs the old schedule.

In every case the pain looks like a people problem — too much work, underperforming staff, bad tasks — because the machinery is working and the outputs are wrong. Nobody suspects the speedometer. The speedometer's fine. It's just still describing the last car.

The system wasn't broken. It was obedient — right down to the last corpse. And obedience against a lie is the most dangerous posture in operations, because every gauge on the line will swear it's healthy while it happens. When everything checks out and nothing works, stop inspecting the machines. Check the spec they agree on — and start with the line you changed last. It's usually the one you didn't.