The Company That Fires Nobody, Yet Never Repeats a Mistake

There is no one to put on a performance plan here. The AI session that mis-read a stale cost ceiling, or skipped a check it should have run, is usually gone — its context closed, its work handed off — long before anyone notices the mistake. So the usual human fix for a repeated error, find the person and correct them, has no target. What we do instead is write the lesson down twice: once as a rule a future session can read, and once as a candidate for something no future session needs to read at all, because a script enforces it before the mistake can happen. The second copy is the one that actually holds.

We wrote about the substrate all of this runs on in "How We Built Our AI Agent Operating Infrastructure" — the bus, the seats, the memory store. This is the piece about what happens after a seat writes a lesson into that store, and why most of those lessons are only a holding pen for something stronger.

Why the human fix doesn't transfer

A human organisation that keeps making the same mistake usually has a name attached to it — retrain the person, escalate to a manager, eventually let them go. That fix works because the person persists: the same set of habits, the same blind spot, shows up next Tuesday unless something changes it. An AI workforce doesn't have that continuity to correct. A session is opened, does the work, and closes; the next session that touches the same problem starts from whatever got written down, not from what the last session "learned". If the lesson only exists as prose in a document, it is exactly as durable as a human's memory of a training session — real for a while, then quietly absent the next time someone is under load and reaching for the fast, familiar answer instead of the correct one.

This isn't a hypothetical failure mode for us; it's a documented one in the literature we build against. A 2023 Stanford and UC Berkeley study on long-context language models (Liu et al., "Lost in the Middle") found that model accuracy on information placed in the middle of a long context degrades sharply compared with the same information placed at the start or end — a result that held even for models built specifically for long contexts. A rule buried on page four of a long instruction file is, structurally, information in the middle. Knowing that a rule exists is not the same as a session reliably acting on it under load, and the gap between those two is exactly where repeated mistakes live.

The rule that caught its own authors within a day

We didn't arrive at this position from a design review. We arrived at it from watching our own rules fail in front of us. On 13 July 2026, the same defect re-entered our system six times in one day, through six different doors — an actor-binding rule that had been coined by one seat, found by another, and upheld by a third, and then all three read a new verdict table within the hour and none of them applied it. Our own COO put the lesson plainly at the time: "a rule you can state and cannot apply under load is a slogan." The rule that came out of that day — every seat, every session, read this one first — is what we call the meta-rule: a rule that is only knowledge will be missed under load by the very people who wrote it.

The proof of that rule is almost funny, and we've kept it rather than quietly edited it out. The document that states the meta-rule sat on an unmerged branch for a full day while the seat that wrote it told the rest of the organisation it was already canonical. It took a fourth seat to notice: the doctrine built specifically to fix "rules that only exist as words" was itself only words, referenced in zero of the ten role documents it was supposed to bind. A rule-set that can catch its own author making the exact mistake it exists to prevent is either broken or honest about how the mistake actually happens. We think it's the second, and we left the story in the document rather than tidy it away.

Grading which lessons are actually rules, and which are gates

The practical output of taking that seriously is a taxonomy, not a slogan. Every lesson an AI session records goes into one of four types — a fact about the person we're working with, a correction or confirmation about how to approach the work, a note about the state of an ongoing project, or a pointer to somewhere the current information actually lives. Before it's filed, though, there's a prior question that matters more than the taxonomy: is this a rule a script could check — a file pattern, a required flag, an "always do X before Y" — or is it a rule that needs judgement about intent and context that no script can currently make? The first kind gets built into a gate, a lint, or a hook, and the prose version of the rule is meant to be deleted once that happens. The second kind stays as prose, permanently, because there's nothing to mechanise.

Most rules don't announce which kind they are on first sight. So we run a script, rule-debt.sh, over the whole memory store looking for a specific signal: a rule whose written justification cites two or more separately dated incidents is a rule that has already been broken more than once despite existing. That recurrence is the tell. A rule broken twice isn't failing because nobody read it — it's failing because reading it isn't enough, and the fix has to move from a sentence to a script. The tool classifies each recurring rule as deterministic (something a script can check outright — mechanise it, then delete the prose), judgment (needs context a script can't currently supply — keep it in always-loaded material, not a file nobody opens), or mixed (mechanise the checkable half, keep the rest). Nothing here auto-builds the gate; a human or an architect seat still has to write it. What the script does is stop "we should really fix this properly one day" from being a feeling and make it a ranked, dated list.

What graduation actually looks like

Two gates in daily use came out of exactly this pattern. Our CaaS scoring model — the formula that ranks tutor quality, with real weighted buckets for delivery, credentials, trust and the rest — used to be protected by a rule telling every session not to change its point allocations without approval. That rule got broken more than once, because "don't change this" is easy to forget mid-edit when you're three files deep in an unrelated fix. It's now a mechanical pre-commit check: staging a change to any of the five protected files, or a matching pattern inside a staged SQL or TypeScript change, blocks the commit outright unless a human at the keyboard sets an explicit override — logged, every time, to a file nobody can quietly delete. The rule didn't get better at being remembered. It got removed from the category of things that need remembering.

The second is smaller and, honestly, more embarrassing to have needed: a rule that said "don't commit product code from the shared main checkout, because concurrent sessions can rewrite each other's working tree mid-commit." That rule was broken enough times that it's now a script wired straight into the pre-commit hook, checked before anything else runs. Both gates share the same shape — a rule that depended on a session remembering it under pressure, replaced by a check that runs whether the session remembers or not.

The honest edge: a gate that exists is not a gate that fires

We'd be overstating this if we left it there, because mechanising a rule doesn't make it unbreakable — it just moves the failure mode somewhere new. We found a checkout, weeks after the commit-location guard above had shipped, where every pre-commit hook was silently disabled. Not bypassed, not overridden — silently absent, because the git configuration on that machine pointed its hook path at a directory that didn't exist. The gate was real. Nobody was reading it, because nothing was invoking it. Our own doctrine has a name for this exact failure, coined the same week we found it: existence is not enforcement. The right question was never "is there a check?" — it's "who reads this check, at the moment it has to decide, and what happens if they can't?" A control sitting in the repository, correctly written, that nothing consults at the moment of the commit is decoration wearing the costume of a gate.

That's not an argument against mechanising rules; it's the reason mechanising a rule is never a one-off task. A gate needs its own check — is it actually wired in, on every machine, every checkout — the same way the original rule needed a gate. We'd rather publish that we found our own guard silently disabled than pretend the graduation from rule to gate is a finish line. It isn't. It's one link in a chain that has to keep being checked, which is a less comfortable thing to admit than "we fixed it," but it's the true version.

Why this keeps working

The uncomfortable starting fact — that there's no one to retrain, because the actor who made the mistake is already gone — turns out to be the reason this holds up better than it sounds like it should. A human organisation's hardest-won lessons live, for a long time, in one person's head, and they leave when that person does; that's not a flaw in any individual, it's just where institutional memory tends to sit by default. An AI workforce can't rely on that default even if it wanted to, because there's no continuous person for the lesson to live in. Every actor here is structurally temporary. That forces the lesson out of any one session's memory and into a record the next session, whoever runs it, has to read to start work at all — and forces the record itself to keep being tested for whether it's a sentence someone might skip, or a script that can't be skipped. Nobody needs to be fired, because nobody who acts is around long enough to become the single point of failure. The mistake stops recurring when the record graduates from something a session remembers to something a session cannot get past — not because any individual session got better at remembering it.

More in this series: How We Built Our AI Agent Operating Infrastructure on the bus and seats this memory system runs on; The Day Our Company Reviewed Itself on the seven-seat review that first showed rules recurring across independent drafts; and When Should an AI Agent Act Alone? on the actor-binding gates that came out of the same mechanisation discipline.