Back in my Big 4 days, one of the hotdesks on floor 3 of the London office had a sticky note on the monitor: "The S key is sticky, sorry - Mandeep." It had been there at least six months. Mandeep was famous for his luxuriously sweet Turkish tea, so nobody questioned it: of course there was thick sugary goodness in those keys.

The first time I drew that desk, the keyboard was spotless. Every key crisp, the S included. Three months later I came back through that office and landed at the same desk. Every key on the keyboard looked nearly pristine. Except the S, worn completely blank, a beaten shell of its factory-new self.

The counter-evidence sat under everyone's fingertips hundreds of times a day, thousands if anyone was writing a surprisingly long snake novel. Nobody noticed, and nobody ever removed the invalid note. The note outranked their own senses; any keystroke that felt faintly off just confirmed it. The claim was plausible, we could all picture the honey, so the fingers said slam. An unqualified, undated note overrode nearly a year of direct physical experience, and the brutality of the wear is the efficiency and effort audit trail. Hold that image, because most of us are currently spamming sticky notes just like it all over our new generation of software factories.


Sticky notes, at machine speed

Last time I argued that context is the job: correct, relevant, concise, in that order. That was the easy version, because it assumed context was something you hand the agent. Fresh every run. Assembled by the pipeline, consumed, binned.

Memory breaks that assumption. Agents remember now: persistent notes, learned preferences, "insights" scribbled down mid-task and recalled forever after. And the moment your system can remember, it can remember wrong. A little Mandeep here and there bleeds into memory. A frustrated note from a debugging session. A workaround that was only ever meant for that one Tuesday. A "we always do it this way" that we absolutely do not. It doesn't stay in that conversation. It compounds. Every future run inherits it as established fact, stated with the calm confidence of something that's always been true. Every memory your agent writes is Mandeep's sticky note, except this note has perfect recall, executes at machine speed, and is read by a workforce constitutionally incapable of doubting it.

Context poisoning was a bad meal. Memory toxicity is contaminated groundwater.

Watch the agent's beliefs about reality drift in.

The factory drinks from the well

If you've built a software factory, an SDLC run on frameworks, skills, and deterministic workflows that feed agents the right context at each step, then memory sits upstream of everything. It's not one input among many. It's the water supply.

And the toxic entries don't announce themselves. Nobody writes "HERE IS A LIE" into a memory file (apart from these wonderful comedic exceptions). What toxic entries actually say is:

// the auth service prefers retries over timeouts

It did, before the rewrite.

// skip the integration tests locally, they're flaky

They were, eight months ago.

// note-to-self: 429s from the pipeline are flakes

This was always utter bollocks.

Each one is plausible. Each one reads exactly like the genuine, hard-won operational knowledge sitting beside it. That's what makes it toxic rather than merely incorrect: you can't smell it.

A poisoned memory drifts your factory in three places at once:

Token efficiency. Every stale or wrong memory is loaded into runs it has no business attending. The attention budget I banged on about last time? Toxic memories don't just waste it. They spend it against you, elbowing real signal out of frame to make room for a confident fib. You're paying, per token, to be misled.

Outcome validation. Your verify stage judges work against what the system believes to be true. If memory says the deploy gate is optional, the reviewer agent waves through changes that skip it, and the pass rate still looks lovely. This is the nastiest failure mode there is: green pipelines, wrong software. The machine isn't broken. It's been convinced.

Authoring intent. You designed the skills. You wrote the framework. You encoded how your organisation ships. Then memory accretes on top like barnacles, and six months later the factory is running on your rules plus a sediment of unreviewed asides nobody ever ratified. The intent didn't get deleted. It got outvoted, quietly, by things nobody remembers writing.

Notice these aren't three separate risks. They're one drift measured three ways: the same rot showing up in your bill, your quality gates, and your design.


Exhibits from my own house

Think this is all hypothetical? I went through the memory my own coding agent has accumulated. Here are real entries, lightly paraphrased, and I want to be clear about something before you read them: every one of these was true when it was written. That's the whole trick. None of them is a lie. All of them are toxic.

Real entries from my own agent's memory. Every one was true when written. Every one is toxic.

Individually, each is defensible. Collectively, they are my individual factory's beliefs, or worse, are shared with my team, and not one of them carries a date, an owner, an expiry, or a link to the incident that spawned it. They will all be recalled with identical confidence in five years. That's not a knowledge base. That's sediment.

Yeah yeah yeah, before you feel smug: your git repo has been doing this to you for years. The flaky test commented out with a TODO that outlives three reorgs, the "temporary" feature flag old enough to start school, the skip annotation nobody dares remove because nobody remembers why it's there. The difference now is that a human reader treated those with healthy suspicion; an agent treats them as ground truth and acts on them, at machine speed, every time they're in frame. Repos were always memory. We just used to get away with not cleaning them.


Factory drift is toxic

Now multiply by a team.

If memories live wherever they land (this engineer's local agent directory, that repo's scratch file, whatever an agent decided to note down), then no two contributors are running the same factory. Same skills, same framework, same YAML, and different accumulated beliefs underneath. Alice's agent learned a workaround in March. Bob's never did. Carol's learned it and then learned a contradicting one.

Unmanaged memory is snowflake knowledge. The rules your factory enforces become a function of whose laptop the agent ran on. That's not a software factory. That's a collection of artisanal workshops wearing a matching uniform.

The fix is the same fix it's always been: a central registry. Memory as a first-class, versioned, reviewed artefact. Shared entries live in one place, they ship to every contributor identically, and a change to what the factory believes goes through the same door as a change to what the factory does. A memory edit is a config change to your organisation's brain. It should get the code-review treatment, because it is code now. It executes, every run, in the attention of the thing writing your software.

One honesty check, though, because my own exhibits cut against the punchiest version of that fix: review alone won't save you. A gate catches the born-false entries, the ones a model scribbled down on a bad day. But the sneakiest Mandeeps were true when they were written. Every reviewer would have waved them through, because there was nothing wrong to catch yet. The danger is time, not authorship. You can't review your way out of decay.


Hygiene is accuracy

When authorship was all humans, bad institutional knowledge had a natural predator: the person who knew better. A wrong note in the wiki got snorted at and ignored, because the reader carried the fundamental knowledge of the business in their head and could see the note was nonsense. Human scepticism was the immune system, and it worked precisely because the knowledge and the judgement lived in the same skull.

Your agents don't have that skull. The authors of your code are no longer all humans who know the business, the context, the unwritten rules. Increasingly they're models whose entire understanding of your organisation is whatever the harness and the memory hand them. They cannot smell that a memory is off, because the memory is not advice to them. It's ground truth. The immune system didn't weaken. It was never installed.

Which means the hygiene has to move into the system itself:

  • Provenance on every entry. Where did this belief come from: a human decision, or something a model concluded on its own at 2am? Those are not the same grade of knowledge and should not be stored as if they were.
  • Expiry as the default. Knowledge about systems rots at the speed the systems change, which is to say: constantly. A memory without a review date isn't institutional knowledge, it's a future incident with patience. Prune on a schedule, not on a vibe.
  • Verification against reality. Memories that reference files, flags, schemas, endpoints: check they still exist before they're recalled into a run. Production is the source of truth; memory is at best a cache of it, and caches get invalidated.
  • Quarantine on the way in. A single conversation should not get to write directly into what every future run believes. Staged, reviewed, promoted, or binned.

Keeping a clean house used to be a virtue. Nice to have, mildly smug, the engineering equivalent of alphabetised spice racks. Not any more. When the workforce reads the house rules literally and executes them, the state of the house is the state of the factory. Clean house isn't the chore you do after the real work. It is the real work.


The registry is the immune system

So this folds straight back into the thesis. The pipeline is the context engine: every step a decision about what reaches the agent. Memory is one of those inputs, and it's the most dangerous one, because it's the only input that writes itself.

Treat it accordingly. One registry, versioned and reviewed. Provenance, expiry, verification, quarantine. Deterministic control over what the factory is allowed to believe, so the agents can be gloriously non-deterministic about everything else. Chaos at the edges, determinism in the spine, and the spine includes memories.

That's the project. Swamp is deterministic automation for AI agents, and everything it puts in front of one carries provenance: a source, an owner, a version history. Check it out at swamp-club.com.

A little Mandeep is all it takes.

Somewhere on floor 3 of a London office sits a keyboard, every key pristine except one. That's what happens when nobody takes the note down.