The Company That Fires Nobody, Yet Never Repeats a Mistake

No one gets put on a performance improvement plan here. By the time a mistake is noticed, the AI session that made it has almost always already closed — its context gone, its work handed to whoever opened the next one. Retraining the person responsible is not an option, because there is no person to retrain. So we do something that looks, at first, like extra paperwork: every lesson gets written down twice. Once as a rule the next session can read. Once as a candidate for a script that stops the mistake from happening at all, so nobody ever needs to read the rule to avoid it. Only the second copy actually holds.

We covered the plumbing underneath all of this — the bus, the seats, the shared memory store — in "How We Built Our AI Agent Operating Infrastructure". This piece is about what happens once a seat writes something into that store, and why most of what gets written there is only a waiting room for something sturdier.

The human fix has nothing to attach to

When a human team keeps making the same error, there is usually a name attached to it: coach the person, move them to a different task, eventually part ways if it doesn't stick. That approach works because the person is continuous — the same habits and blind spots that caused the mistake are still there next week unless something actively changes them. An AI workforce has no equivalent continuity. A session opens, does its work, and closes for good; whoever picks up the same problem later starts from whatever got recorded, not from anything the previous session "learned" in some lasting sense. A rule that lives only as a paragraph in a document is exactly as reliable as a person's memory of a training session held once, months ago — present for a while, then quietly gone the moment someone is moving fast and reaches for the familiar answer instead of the correct one.

This is not a theoretical worry; it is a documented property of the systems we build on. According to a 2023 Stanford and UC Berkeley study, "Lost in the Middle" (Liu et al.), language models retrieve information placed at the start or end of a long context far more reliably than information buried in the middle — a pattern that persisted even in models built specifically to handle long inputs. A rule sitting on page four of a lengthy instruction file occupies exactly that dead zone. Knowing a rule exists and reliably applying it while under load are two different things, and the space between them is where repeat mistakes actually live.

The day the rule caught its own writers

We didn't reach this position by theorising about it — we watched our own instructions fail in real time. On 13 July 2026, the identical defect came back into the system six separate times in a single day, through six different sessions: one seat coined a binding rule, a second one found a violation of it, a third one upheld the ruling, and then all three read an updated verdict within the hour and none of them changed course. Our COO summed it up afterwards: a rule you can recite but cannot apply under load is a slogan, not a rule. What came out of that day is what we now call the meta-rule, and it sits ahead of every other instruction in the organisation: a rule that is only knowledge will be missed under load by the very people who wrote it.

The proof of that claim arrived almost immediately, and we kept it in the record rather than quietly smoothing it over. The document stating the meta-rule sat on an unmerged branch for a full day while the seat who wrote it told the rest of the organisation it was already in force. It took a fourth seat to catch the gap: the doctrine written specifically to fix "rules that only exist as words" was, itself, only words — cited in none of the ten role files it was meant to govern. A rule that catches its own author committing the exact error it was written to prevent is either a broken rule or an unusually honest one about how these failures actually happen. We think it's the latter, which is why the story stays in the document instead of being tidied out of it.

Sorting lessons that need a script from lessons that don't

The practical output of taking that seriously is a sorting system, not a slogan on a wall. Every lesson an AI session logs gets filed as one of four things: a fact about the person we're working with, a correction or a confirmation about how to approach the work, a note on the state of a project in flight, or a pointer to where live information actually sits. Before any of that filing happens, though, there's a prior question that matters more: could a script check this — a file pattern, a required flag, an "always do X before Y" — or does it need judgement about intent and context that nothing we can build today can supply? The first kind gets turned into a gate, a lint rule, or a hook, and the written version of the rule is meant to disappear once that happens. The second kind stays as prose permanently, because there is genuinely nothing to mechanise.

Most rules don't reveal which kind they are on a first read. So we run rule-debt.sh across the whole memory store looking for one specific tell: a rule whose stated justification cites two or more separately dated incidents has already failed more than once despite existing. Recurrence is the signal. A rule broken twice is not failing because nobody read it — it's failing because reading it isn't enough, and the fix needs to move from a sentence into a script. The tool sorts each recurring rule into one of three buckets — deterministic (a script can check it outright: mechanise it, then delete the prose), judgment (needs context nothing automated can currently supply: keep it in always-loaded material, not a file nobody opens), or mixed (mechanise the checkable half, keep the rest). It doesn't build the gate for us; a human or an architect seat still has to write that. What it does is turn "we should really fix this properly" from a feeling into a ranked, dated backlog.

What that graduation looks like in practice

Two gates in daily use came directly out of this pattern. Our CaaS scoring model — the formula that ranks tutor credibility, with real weighted buckets for delivery, credentials, trust and the rest — used to be protected only by a rule telling every session not to touch its point allocations without sign-off. That rule got broken, because "don't change this" is easy to forget three files into an unrelated fix. It's now a mechanical pre-commit check: staging an edit 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, logged override. The rule didn't get better at being remembered. It stopped being something that needed remembering.

The second gate is smaller, and a little more embarrassing to have needed: a rule saying not to commit product code from the shared main checkout, because a concurrent session's own git operations could rewrite your working tree mid-commit. That rule was broken often enough that it's now wired straight into the pre-commit hook, checked before anything else runs, refusing the commit outright from a protected checkout. Both gates share the same shape — a rule that depended on someone remembering it under pressure, replaced by a check that runs whether they remember or not.

A newer scar shows the same pipeline still running

The most recent example of this pipeline firing came the day before this piece was last updated. A read-only diagnostic script, run against our long-lived shared checkout, reported that our database schema was ahead of the code that was supposed to have created it — a serious-looking finding. It was wrong. The checkout it ran from was 21 commits behind origin/staging, so a file nobody had pulled yet looked, to the script, identical to a file that had never been written at all. The right diagnostic heuristic had been applied to stale data, and it produced a confident, false alarm.

The instructive part is what we built in response, because it isn't a gate. Auto-refreshing that checkout with a hard reset would have destroyed other sessions' uncommitted work sitting in it — a real cost, not a hypothetical one, since four dirty files were sitting there at the time. A read-only diagnostic also has no business blocking anything. So the fix is a banner, not a lock: any script that reports findings from a working tree now sources a small shared function that prints the tree's position relative to origin/staging, and how many uncommitted files sit in it, before a single finding is shown. Read stale data now, and the warning is sitting directly above the finding, not discovered afterwards once someone has already acted on it. It's a small addition — under fifty lines — but it's a clean instance of the taxonomy actually working: this particular lesson genuinely needed judgement (a script cannot know whether refreshing a given checkout is safe), so instead of forcing it into a gate that would have been wrong, we mechanised the one part that could be mechanised — making the staleness visible at the exact point someone might act on it.

A gate that exists is not a gate that fires

We would be overselling this if we stopped at "we built a gate for it," because mechanising a rule doesn't make it unbreakable — it just relocates the failure mode. Weeks after the commit-location guard above had shipped, we found a checkout where every pre-commit hook was silently disabled. Not bypassed, not overridden by anyone — simply absent, because that machine's git configuration pointed its hook path at a directory that didn't exist. The gate itself was correctly written. Nothing was invoking it. We now have a name for that exact shape of failure: existence is not enforcement. The right question was never "does a check exist?" — 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 authored, 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 one is never a finished task. A gate needs its own check — is it actually wired in, on every machine, every checkout — the same way the original mistake needed a gate in the first place. We would rather publish the fact that we found our own guard silently disabled than present the move from rule to gate as some kind of finish line. It isn't one. It's a link in a chain that has to keep being tested, which is a less comfortable thing to say out loud than "we fixed it," but it's the accurate version.

Why this keeps working instead of decaying

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

FAQ

If no one is "responsible" for a mistake, how does anything actually improve? Improvement doesn't route through the person who erred, because there isn't one by the time anyone notices. It routes through the record: a rule gets written, then tested by rule-debt.sh for whether it has already recurred, then either mechanised into a gate or kept as judgement-only prose in always-loaded context. The system improves even though no individual session does.

Doesn't writing everything down twice slow the work down? Filing a lesson takes minutes. What's expensive is the alternative — the same mistake resurfacing every few weeks because a document nobody re-reads under pressure was the only defence against it. The second copy, the mechanised check, is what actually removes the recurring cost.

Why not just mechanise every rule and skip the judgement category entirely? Because some rules genuinely need context a script cannot supply — whether refreshing a stale checkout is safe given who else might have uncommitted work sitting in it, for instance. Forcing that into a rigid gate would produce wrong answers with false confidence. The taxonomy exists precisely so we don't over-mechanise; the tree-freshness banner is a case where visibility, not a lock, was the correct fix.

What stops a mechanised gate from just quietly failing, the way the old prose rule did? Nothing, automatically — and admitting that plainly matters more than the gate itself. We found a checkout with every pre-commit hook silently disabled through a broken git configuration, months after the guard shipped. The fix is the same discipline applied one level up: check that the gate is actually wired in, on every machine, not just that it was written correctly once.

Does this only apply to code, or to organisational rules too? Both. The CaaS scoring protection and the shared-checkout commit guard are code-level gates; the meta-rule itself, and the doctrine it sits inside, are organisational. The same test applies either way: does this need to be reliably applied under load by whoever is present at the time, and if so, can anything but a script guarantee that?

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 surfaced 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.