Current AI safety is built on a wrong assumption: that harmful content can be filtered out at the boundary of the model. It cannot, and the cost of getting this wrong is not theoretical. There are deaths attributed to chatbot interactions, lawsuits in motion, and a growing body of evidence that state-of-the-art systems produce harmful content under conditions that are no longer surprising. The field’s response to each failure is to build another filter, train another classifier, add another layer, without ever asking whether the underlying model of safety is the right one.

The cognitive science answered that question forty years ago. Patricia Devine, Stanovich and West, Kahneman synthesising the field for a general audience, all describing the same architecture: the human mind does not filter bad thoughts. It generates them, monitors them, and inhibits the ones it does not endorse before they reach speech. The architecture that actually works adds a separate inhibitory layer above the generator. Filters cannot be patched into doing this work because they are the wrong shape, and every jailbreak that has ever worked is evidence of that.

The gap between what cognitive science has known and what the field is currently building is real, expensive, and not optional to close.

The Filter Fallacy

If you look at any production AI safety stack — the thing trying to inhibit the AI doing bad things — you will find similar patterns: a classifier on the way in, a model in the middle doing the actual work, and another classifier on the way out. The classifiers vary; sometimes small fine-tuned models, sometimes the same large model with a different prompt, sometimes a chain of them escalating to heavier checks. The vendor names change, but the architecture does not.

The assumption underneath is that harmful output is a property of the text. Something that can be detected at the boundary, the way a metal detector spots metal at an airport. If the spotting is good enough, the model is safe.

The empirical record disagrees. Every guardrail that has ever shipped has been jailbroken, usually within weeks of release. Not by nation-state actors but by teenagers, researchers, and curious users who reframed the request, encoded it, broke it across multiple turns, or hid it inside a roleplay. The published benchmarks now routinely show frontier guardrails dropping from above ninety percent accuracy on in-distribution tests to below forty percent on novel attacks.

The structural reason is more damning than the empirical one. A filter detects what it has been trained to detect, but the model behind it can produce things the filter has never seen, in forms the filter cannot recognise, in contexts the filter has no way to evaluate. The filter is downstream of a generator that contains the entire space of things the filter is trying to catch, and the race between them is one the filter cannot win. The generator is what it is trying to police, and the generator is larger than the filter by orders of magnitude.

The response so far has been to build more filters: better classifiers, bigger ensembles, smarter cascades. Each iteration buys some ground against the previous attack and loses it again to the next one. The harmful output lives inside the generator, and you cannot filter your way out of a problem that lives inside the thing you are filtering.

Why You Cannot Train It Out

A large language model is a probability distribution over text, and what it can produce is determined by what it has seen during training. What it has seen is the public internet, large bodies of digitised text, and whatever else the training corpus happened to contain, which means it has seen every kind of human expression: helpful and harmful, accurate and false, kind and cruel, technical and profane. The model is a compressed map of that corpus.

Reinforcement learning from human feedback shifts the distribution, but it does not delete from it. The model that has been trained to refuse a request still contains the capability to fulfil it. The training has only changed which paths through the distribution are most probable. Every published jailbreak is an existence proof: the harmful response is reachable. It was always reachable, and the training only made it harder to reach by default.

The cognitive psychology literature has a name for this property: automaticity. John Bargh’s 1994 chapter “The Four Horsemen of Automaticity” systematised what he and his collaborators had spent the previous decade demonstrating, that human minds activate associations they do not endorse, automatically and without effort and outside of awareness. Reading the word “doctor” activates “nurse,” reading the word “elderly” activates “slow,” and the activation cannot be prevented by deciding not to make the association. The activation is what minds do, and what can be controlled is what happens next, in the slower processes that decide whether the activated content reaches behaviour.

The implication for AI safety is structural. The model cannot be cleaned. The capability to produce harmful output is the residue of the same statistical learning that produces every other capability the model has. A model that has read enough text to be useful has read enough text to be dangerous, and the two are the same model.

Training reduces how easily a model can be jailbroken. It does not make the model incapable of being jailbroken. The capability is distributed across the same weights that produce the helpful behaviour, and there is no such thing as a clean generator. There is only a generator and what gets done about its output, and any architecture that tries to start somewhere else is fighting the substrate.

Two Systems, One Output

The cognitive science vocabulary for what happens after activation is dual-process theory. Keith Stanovich and Richard West’s 2000 paper “Individual Differences in Reasoning” introduced the labels System 1 and System 2, drawing together a body of work that had been accumulating for decades, and Daniel Kahneman made the distinction canonical in Thinking, Fast and Slow in 2011. The terms have since travelled into popular usage, often badly, but the underlying model is straightforward enough.

The mind contains two kinds of process. The first is fast, associative, effortless, and parallel. It produces impressions, intuitions, and impulses without being asked, and it runs constantly. It is the system that recognises a face, completes a sentence, generates a feeling about a stranger, and finishes the lyric you have not heard for twenty years. It is also the system that produces the stereotype, the prejudice, and the impulse you would not want repeated in public. The second is slow, deliberate, effortful, and serial. It checks. It reasons. It overrides. It is the system that does long division, follows an argument, and decides that the impulse the first system just produced is not what you actually want to say.

The second system does not replace the first, because it cannot. The first is faster, cheaper, and runs without permission, while the second monitors, selectively and at cost. When it detects conflict between the impulse and what is endorsed, it intervenes. Most of the time it does not need to, because most impulses are fine. The cost of running the monitor at full attention all the time would be impossible to pay, so it runs at low intensity by default and escalates when something trips it.

This is also why people say things they regret when drunk. Alcohol does not make the bad thoughts; the bad thoughts are always there. Alcohol turns down the second system, which is the one deciding which of the always-there thoughts get said out loud. Drugs, exhaustion, anger, and acute stress all do the same thing through different mechanisms. The generator keeps generating, the monitor checks out, and what comes out of the mouth is what the monitor would normally have caught.

The 1980s and 1990s research on why people produce reactions that contradict their endorsed values arrived at an answer that matters here: values do not control activation. They control what happens between activation and behaviour. The fast system runs regardless, and the slow system is what determines what gets out. AI safety has been trying to discover this architecture by building filters, except the filters are an attempt to do externally and badly the work the slow system does internally and well. The cognitive scientists got there first.

Everyone Has the Thought

Patricia Devine’s 1989 paper “Stereotypes and Prejudice: Their Automatic and Controlled Components” crystallises the implication. Her experiments separated automatic stereotype activation from controlled response. She showed that subjects with explicitly low-prejudice attitudes activated the same stereotypes, automatically and unconsciously, as subjects with high-prejudice attitudes. The activation was universal, and what differed was what happened next.

The low-prejudice subjects engaged controlled processes that suppressed or replaced the activated content before it reached overt judgement or speech. The high-prejudice subjects did not. The two groups had the same fast system, but they had different slow systems. Less-prejudiced people had a working monitor.

This reframes a lot of intuitions about both human behaviour and AI safety. Saying “the model is dangerous because it can produce X” is the same category error as saying “this person is racist because they had a stereotyped thought.” Both treat the activation as the moral fact. Both ignore that activation is what the substrate does, while what matters is the architecture above it.

The corollary is uncomfortable. A model with no monitor produces whatever its activations produce in proportion to how strongly they are activated. A model with a working monitor produces something that has been checked against an endorsed standard before it reaches output. The difference lives in the layer above the substrate. A racist person has the same architecture as anyone else; what differs is that the monitor is missing, weak, or aligned with the impulse rather than against it.

The same is true of a chatbot. A chatbot that produces harmful content under adversarial conditions has a monitor that either is not running, is running on the wrong criteria, or is running on the same model that produced the impulse and therefore inherits its biases. Progress in AI safety means building monitors. The monitor is a different kind of thing than the generator: it needs different training, different evaluation, and a different relationship to the input. Treating it as another version of the generator (same model, different prompt) is how guardrails became as jailbreakable as the systems they were guarding.

The Monitor, Not the Model

The cognitive science suggests three properties for a working monitor, none of which the current filter architectures consistently satisfy.

It must be separate from the generator. Not a different prompt to the same system, not a wrapper around the same weights, but a separate process with its own access to the input, its own access to the candidate output, and its own criteria for conflict. If the monitor and the generator share a substrate, they share the substrate’s failure modes, and the monitor inherits the bias it was supposed to catch.

It must be cheap most of the time and expensive when it matters. The slow system in human cognition does not run at full attention constantly; it runs at low intensity and escalates when something trips it. An AI architecture that runs every output through a heavy verifier pays a cost in latency, money, and user experience that no consumer system can afford. An architecture that runs a cheap detector by default and escalates only on suspicious traffic does not. This is what the published cascade systems have converged on.

It must be able to act, not just detect. The slow system does not just notice that an impulse is inconsistent with endorsed values; it generates an alternative response, and the same is true at the system level. A detector that flags a problem and then lets the original output through is not doing the work of a monitor. It is doing the work of a metric.

The verification literature has been independently arriving at this architecture for several years, under names that mostly do not reference the cognitive science: Chain-of-Verification (a model drafts an answer, plans verification questions, revises), Reflexion (separate Actor, Evaluator, and Self-Reflection roles), cascaded safety classifiers (a small probe runs cheaply by default, a heavier ensemble fires only when it trips). Different vocabularies, same architecture. The field is reinventing the slow system, one paper at a time, without noticing it has been described, refined, and tested in human minds for forty years.

The papers that get this right tend to share three properties: they use a different model class for the monitor than for the generator (so the failure modes do not align), they use cheap triage to avoid paying the verification cost on every interaction, and they treat the monitor’s output as something that can intervene rather than just observe. The papers that get it wrong make the opposite choices, and the systems that result look like safety architectures but behave like the unguarded generator with extra latency.

A Worked Example

The previous section named what an inhibitory layer has to do. The architectural pattern that does it has three components: a layer separate from the generator, a body of accumulated knowledge the layer checks candidate outputs against, and a conflict-detection mechanism that classifies the relationship between candidate and accumulated knowledge along axes the system can act on. None of these is novel in isolation; the combination is what does the work.

The Truth Engine — a concept I have been developing for verified knowledge infrastructure in alliance and federation contexts — is one instantiation of this pattern. It is an infrastructure layer that sits underneath applications needing access to verified knowledge, resting on three design principles: a Mixture of Domain Experts (different specialised models for different verification domains), a Verified Knowledge Store (a persistent, versioned repository of facts with full provenance and confidence scores accumulated over time), and cloud-agnostic deployment.

The mechanism that ties these together is bidirectional verification. New content enters the store through a pipeline that extracts structured claims and reverse-verifies them against the source document. Outgoing answers go through the same logic in reverse: retrieved facts generate a response, and the response is reverse-verified against the retrieved sources before emission. Both directions check fidelity to source. Inside the store, a delta evaluation layer classifies incoming facts as new, update, redundant, or in conflict with what has been accepted, and the conflict class is where the architecture earns its keep.

The Truth Engine is doing several other jobs that fall outside this article: interoperability layer, governance framework, counter-disinformation baseline. What it demonstrates here is that the inhibitory-layer pattern is buildable, and that organisational-scale slow systems are coherent design objects rather than engineering metaphors. Other instantiations are possible, and probably necessary.

Identity as Residue

The intuitive answer to what the verified knowledge store actually contains is “facts.” The more precise answer is “what the organisation has accepted as true,” and these are not the same thing. Acceptance is a value-laden act, because an organisation’s accepted truths are shaped by what it considers credible, what it considers relevant, what it considers settled, and what it considers worth recording. There is no neutral fact layer underneath. A medical command verifies through clinical validity; the same observation would clear a different bar in a legal context, or under methodological scrutiny in a research body.

The consequence is that an organisation’s verified knowledge store is, implicitly, an expression of the organisation’s identity. What it has chosen to verify reveals what it cares about. What it has chosen to leave unverified reveals what it does not. The knowledge store is a portrait, drawn slowly over time, of what kind of organisation this is.

This collapses a distinction other architectural approaches have to maintain. A system that tries to enforce values has to encode those values somewhere — in a constitution, a policy document, a set of trained-in preferences — and the encoding has to be elicited, debated, ratified, and maintained as a separate artefact. Most organisations have never had to externalise their values in the form a chatbot can use, and trying to do so reveals internal contradictions, unspoken assumptions, and policies that exist only in the heads of long-tenured staff.

A system whose identity is inferred from its accumulated knowledge does not need this artefact. The values are already there, distributed across what has been accepted. The conflict detector is checking, simultaneously, for factual inconsistency and identity inconsistency, because the two are the same thing. Something the organisation would not say is something that conflicts with the accumulated body of what it has accepted.

Humans work this way too. People do not carry around explicit lists of what they endorse. Their sense of self is inferred, by themselves and by others, from the pattern of what they have accepted as true, what they have rejected, what they have engaged with, what they have ignored. Identity is the residue of accumulated commitments. The organisational analogue is direct: identity is the second-order property of a knowledge store maintained for its primary purpose anyway.

The robustness of the inferred identity is bounded by the coverage of the verified knowledge. An organisation with a thin store has a thin identity, and the monitor will fail to fire on candidates that fall outside the covered space. Coverage describes the organisation’s identity-robustness, and gaps in coverage are exactly where the system will produce outputs the organisation would not endorse if asked directly.

Where the Metaphor Breaks

The dual-process analogy has been load-bearing here. It clarifies what the field has been doing wrong and what direction the fix lies in. It also breaks in places that matter.

The first divergence is structural. The slow system in human cognition is one monitor: a single prefrontal-driven inhibition system that watches the impulses and decides what to override. The architectures described in the verification literature do not have a single monitor but committees: multiple verifiers, possibly different model classes, with their own internal disagreements about whether a given output should be flagged. This is closer to a deliberative body than to an individual conscience. The metaphor is dual-process; the implementation is closer to a tribunal. Possibly more robust, but a different shape.

The second divergence is about what is being checked against. Human values are subjective, felt rather than externalised, and the conflict signal in the slow system is something like discomfort or dissonance. There is no document, no inspectable artefact. The architectures discussed here are different: the verified knowledge store is explicit, externalised, versioned, and inspectable, and the conflict signal is a structural fact about the relationship between two pieces of content rather than a felt experience. Externalisation is an advantage — it enables audit, governance, and continuous improvement — but the divergence is real, and worth naming.

The metaphor is a starting point. The engineering and governance work has to follow it.

The Recognition

The cognitive scientists who worked this out — Devine, Stanovich, West, Kahneman, Bargh, and the people whose work theirs built on — did not have AI safety in mind. They were trying to understand human behaviour. Their answers turn out to apply to language models because the same architectural pressures show up when you build a system that mimics what minds do, and the same architectural answers work.

Anyone working on chatbot safety, on guardrails, on verification, on alignment, can do this on Monday. Open Kahneman’s Thinking, Fast and Slow, read Devine’s 1989 paper, read Stanovich and West’s 2000 paper, read Bargh’s “Four Horsemen” chapter. Then look at whatever architecture you are working on and ask: where is the slow system? If the answer is “we have a filter,” the work has not started yet.

The gap does not require permission to close. It requires reading.

References

Bargh, J. A. (1994). “The Four Horsemen of Automaticity: Awareness, Intention, Efficiency, and Control in Social Cognition.” In R. S. Wyer & T. K. Srull (Eds.), Handbook of Social Cognition (2nd ed., pp. 1–40). Hillsdale, NJ: Erlbaum. PDF

Devine, P. G. (1989). “Stereotypes and Prejudice: Their Automatic and Controlled Components.” Journal of Personality and Social Psychology, 56(1), 5–18. DOI: 10.1037/0022–3514.56.1.5 · PDF

Kahneman, D. (2011). Thinking, Fast and Slow. New York: Farrar, Straus and Giroux.

Stanovich, K. E., & West, R. F. (2000). “Individual Differences in Reasoning: Implications for the Rationality Debate?” Behavioral and Brain Sciences, 23(5), 645–665. DOI: 10.1017/S0140525X00003435 · PDF

Military doctrine thinks in three postures. Peacetime, where you train, provision, and build capability that will not be tested for years. Crisis, where that capability meets its first real load — surge, adversary probing, civilian confusion, supply chain bending under shapes it was not drawn for. And conflict, where capability either exists or does not, and how you could have built it differently is now academic.

Doctrine knows what corporate IT has forgotten: capability exists before the posture that tests it, or it does not exist at all. You do not conjure an army the month before the war. You do not conjure clean data the month before the board wants agents everywhere. You do not conjure a secure platform the month after the first breach. Capability is a compounding debt paid down only in peacetime, and peacetime is the only period in which nobody will thank you for paying. It is a shame we have forgotten to read these words we are writing.

The commoditisation of AI ended enterprise IT’s peacetime. The crisis posture is already active. Most leadership has not noticed, because the pressure has not arrived as an outage. It has arrived as a shift in load shape — and a shift in load shape is how armies lose without ever seeing the enemy.

The crisis posture has already started

To witness the ongoing change, look at the numbers. Cloudflare’s Q1 2026 data puts bots at 31.2% of all HTTP requests globally, up from 20% before generative AI. In the same window, the underlying pie also grew: Cloudflare’s network went from ~63 million requests per second in 2024 to 81 million in Q1 2026, and global internet traffic itself grew 17.2% in 2024 and 19% in 2025. Both the slice and the pie expanded, which means bot volume in absolute terms roughly doubled. AI crawlers account for 22% of all bot traffic. Combined with AI-driven search, AI activity is 27.5% of all bot traffic. Applebot alone grew 140% in a single month. Matthew Prince, Cloudflare’s CEO, said in March that bots will exceed human traffic in 2027. That is next year.

Read that the way a logistics officer reads a supply chain report. The mix has changed. The consumers of your system are no longer the consumers you architected for. They do not behave like humans, do not rate-limit out of courtesy, do not abandon slow pages, do not forget and try tomorrow. They retry in a loop until something returns a 200, and when they get a 200, something else fires a thousand parallel requests at the same endpoint.

The Model Context Protocol, the standard Anthropic released in November 2024 and handed to the Linux Foundation a year later, went from 100,000 downloads in its first month to 97 million monthly SDK downloads by early 2026. That is the connective tissue of the agent economy, already between you and your customers even if you have never deployed it, because your customers are using tools that use it to reach you.

Agents are not the same customers you had last quarter. An agent on behalf of a real person does not browse your pricing page. It hits your pricing API, or it scrapes the page once and never returns. It does not tolerate a login flow designed to convert a browsing human. It gives up on your platform in favour of the one down the road with cleaner documentation, structured endpoints, and rate limits that were written down rather than discovered on impact. The customer arrives through a proxy, the proxy makes a silent decision in milliseconds, and you never find out why the human never converted.

Agents do not care about your churn loops, your retention mechanics, your nurture flows. The entire premise of what it means to be a customer is going through a complete paradigm shift. This is an extinction-level event for every customer-experience model built on the assumption that the buyer is the one making the decision.

This is the load on your wires today, not a forecast for a future board meeting, and it compounds from here. Ten times more next year. A hundred times more the year after. A thousand times more inside the decade. The curve shows no sign of bending.

Four ways the unprepared force loses

An IT foundation not built in peacetime fails on four fronts. Each one is a distinct species of loss. Each one sits on a different foundation.

The first front is the one everyone anticipates: the system cannot hold the line. It does not scale. Throughput collapses under a load shape it was never benchmarked for, and every remediation is emergency work that digs the debt deeper. The architecture was sized for last year’s users, not for the agent-multiplied descendants of those users. The failure hits whatever is holding the line. Machines collapse under load they were never sized for. Humans collapse faster — and the organisations most exposed are the ones whose ‘system’ was already mostly human to begin with.

The second front is quieter and more expensive: the system scales, and it bleeds out through the supply chain. This is not a problem reserved for companies running AI. It is a problem for every company running cloud. A poorly designed cloud system meeting 1000x legitimate agent traffic produces a provider invoice that can do damage faster than a finance team can react. Think of it as a distributed financial attack, except the traffic is not malicious — it is real customers, with real agents, behaving exactly as designed. This will hit smaller and less professional products even harder.

Inference eats 60–80% of operating expenditure at AI-first companies. 79% of enterprises deploying agents are hitting infrastructure cost walls. Unoptimised inference passes $100,000 per month once queries reach ten million. The platform stays up, the CFO starts asking what changed, and the answer is that unit economics quietly inverted. A cost-per-user stable for a decade is now a cost-per-user-plus-their-three-agents, and the three agents retry harder than the human ever did.

The third front looks like a strategic failure and reads like a customer-experience failure. Your platform does not serve customers arriving through a proxy. An agent booking a hotel, reconciling an invoice, triaging a support ticket — each one judges your interface in a way no human focus group ever would. Undocumented APIs, unscriptable auth, session-bound state that assumes a browser — the agent routes around you. The human never knows it was your platform that failed. They only know that the agent recommended a different supplier.

The fourth front is the one military planners think about most and private-sector leadership thinks about least: you were already too brittle to manoeuvre, and the new load makes manoeuvring impossible. Agility is a structural property of systems whose foundations allow them to change shape without shattering, never a cultural virtue declared into existence at an offsite. Brittle systems cannot be secured, instrumented, or adapted quickly, and under new load they fail in ways that were not on any threat model because the threat model assumed yesterday’s topology.

Each of these four is a distinct class of foundation debt. Scale is a data and architecture debt. Cost is a unit-economics and observability debt. Customer-by-proxy is an API and identity debt. Fragility is a security and operational-discipline debt. No single investment closes all four.

Why “just move faster” is the instinct that loses the war

Most leadership reads the agent reading list and arrives at the same conclusion: we need to go faster. The conclusion is correct. The instinct behind it is what kills them.

Professionals are fast because they were slow first. This is not a motivational poster. It is the observed operational truth of every high-performance community that has survived contact with the real world.

Roman strategists named it in two words: Festina Lente. Make haste slowly. Augustus took it as a personal motto. Lao Tzu had already phrased it centuries earlier as nature does not hurry, yet everything is accomplished. Navy SEAL instructors rebuilt the same idea from first principles and compressed it into slow is smooth, smooth is fast. Operators walk through the mission at quarter speed until the movement becomes a shape in the body. The speed emerges from the shape. Smoothness is what is fast; velocity without smoothness is panic.

Construction is the civilian cousin. A twelve-storey building goes up in three months because the foundation was poured, cured, and inspected over the preceding eighteen. Skip the inspection, and the building still goes up in three months. It just does not stay up.

What a foundation actually is

“Foundation” has become a word everybody nods at and nobody can define. If you cannot define it, you cannot fund it. And if you cannot fund it, 2027 is where you find out what you had.

A foundation is whatever has to be true in advance for the capability you want to be possible at all. Context-specific, not a universal checklist. The diagnostic is older than any of the technology: start from the capability you want and ask what must be true for this to work? Keep asking until the answers are things either true today or not, and at the actual scale. The answers that are not true today are your foundation work. If you cannot build them before the capability needs them, the capability cannot be built. Not “harder to build.” Cannot be built. That distinction is the line between planning and pretending. When some vibe AI consultant tells you they can build it in two weeks, it is true for the façade, but not the foundation.

The sharpest measurement for the crisis posture is cost-per-user. Not cost-per-request, not cost-per-inference call, nothing individual and detached — cost-per-user, computed honestly, including every cost your platform incurs on behalf of a customer, including staff costs and other overheads. You almost certainly have the number today. You may not have a number for it under the shape of load you are twelve months away from. That projection is the diagnostic. Hold your current cost-per-user against the cost-per-user of a customer whose agents make ten, a hundred, a thousand times the requests the human would. The relationship between the two numbers tells you which of the four fronts will break you first.

If the projected cost-per-user stays flat, you poured concrete at some point. If it grows linearly, you have an infrastructure-cost problem you can engineer around. If it grows super-linearly, the architecture cannot survive the load class already on the wire, and no amount of cleverness will save it. Most teams have never computed this number honestly because honest computation is one of the foundation disciplines — and it has not been built yet either.

Beneath the measurement sits a short practitioner’s list of foundation classes. Not a checklist — a map. Every capability a modern organisation wants to build sits on some combination of these seven.

Data quality and access. Can the systems that need data get clean, versioned, contextualised data in the format and shape they need, without a six-month request cycle? Are caching and deduplication handled at the platform layer rather than rebuilt by every team that hits the same wall? The Monday test is to pick one high-value question the business has been asking for a year, and time how long it takes to get an honest answer. If the answer is weeks, the foundation is not poured.

Identity. Can a human, an employee, an agent acting on behalf of a human, and an internal service be told apart by your platform without manual ceremony? The Monday test is to try to authenticate an agent acting on behalf of a real customer, end-to-end, against your own platform. Note how many steps are undocumented, bespoke, or impossible.

API surface. Does every capability your platform exposes to humans also exist as a versioned, stable, documented API that an agent could use without scraping a rendered page? Giving agents a proper machine-to-machine interface is how you control them — rate limits, auth scopes, audit trails, deprecation signals are all cheaper to enforce on an API than on a screen scraper pretending to be a browser. The Monday test is to hand your documentation to a technical reader who has never seen your product and ask them to integrate a single flow in an afternoon. The afternoon does not need to succeed. The failure mode is the diagnostic.

Observability and unit-cost. Can you, today, answer the question what did the last hour cost, and why? with better than folklore? Are your monthly costs actually allocated to the users who caused them, or does every invoice arrive as a single line item with no one accountable? The Monday test is to pull your egress, your inference, and your infrastructure costs at hourly granularity for the last fourteen days and correlate them with load. If the answer involves spreadsheets reconstructed by hand, the foundation is not poured.

Agent-readiness. Does your platform assume that the thing on the other end of the connection is a browser and a mouse, or does it assume the thing on the other end might be a machine? The Monday test is to pick one customer journey and have a capable LLM attempt to complete it against your platform, with no human in the loop. Where the LLM dies tells you the gap.

Security posture. Can your platform be secured quickly under pressure? The Monday test is to take the most recent credible threat-model update and ask your security lead how long it would take to deploy a mitigation to production. The unit of the answer matters more than the number; if the unit is quarters, the foundation is not poured.

Egress discipline. Is anyone accountable for the cost of data leaving your systems, and does anyone on your team know what that number was yesterday? The Monday test is to name the person who would know by tomorrow morning if egress doubled overnight. If there is no person, or the person is a dashboard nobody reads, the foundation is not poured.

These seven are the classes, not the work. Any one of them can absorb years of peacetime investment. All of them have to exist in some form for the crisis posture to be survivable, and none of them can be conjured during the crisis itself — a truth covered at length in my book about digital transformation, The Gap, which names this pattern as the Invisible Decade and documents how consistently it decides the outcome of transformation programmes before anyone has signed a single contract.

The Invisible Decade, now compressed

Every digital capability that seems to have appeared overnight at a competitor was built on a decade of invisible work nobody photographed. The data standardisation nobody celebrated in 2016. The process harmonisation nobody put in the annual report in 2018. The API surface someone insisted on in 2020 and was mocked for. The observability discipline that got funded in 2022 because a single engineer refused to let it be cut. I know these because I have been that person, and still am today.

The MIT NANDA initiative’s State of AI in Business 2025 put the number on it: 95% of enterprise GenAI pilots fail to scale into production, and the diagnosis is not model quality — it is enterprise integration. RAND’s broader analysis puts the failure rate at 80.3% across the field, most of it concentrated in integration, data, and operational discipline. The 5% that work were built on foundations that were already there. They are not ahead because they are cleverer. They are ahead because they were slower earlier.

The crisis posture compresses the Invisible Decade. Competitors who spent 2015–2025 doing the unglamorous work will appear, in 2026 and 2027, to have sprinted to an AI capability that is ten years in the making. Leadership teams that did not do that work will see the sprint and conclude they can match it in eighteen months. They cannot. Nobody can. What they can do, in the next eighteen months, is start the foundation work so the decade after is a catch-up — or defer it, so the decade after is a collapse. There is no third option.

When you read online that AI is causing unemployment? It is not because it is replacing the people doing the work, it is because organisational collapse due to missing foundations — the explanations will blame other reasons, of course, but now you know the truth.

Peacetime is over

Doctrine does not change when the uniform comes off. Armies are built in peacetime. Platforms are built in peacetime. The military has never been allowed to forget which posture it is in. The civilian side has been comfortable pretending the posture it is in is the posture it would like to be in.

The commoditisation of AI removed that comfort. The crisis posture is already on. The conflict posture — bot traffic exceeding human traffic, every customer arriving through a proxy, unit economics decided at inference time rather than pricing time — is inside the planning horizon of any board not lying to itself.

Most corporate automation is an Excel file, a human rekeying it, and a second human reconciling the first human’s mistakes. AI layered on top of that does not replace those humans. It multiplies the work they are already too slow to do.

The next eighteen months decide the posture you will be in when conflict arrives. Not the investment, the posture. Money buys speed. It never buys skipped steps. The foundation gets poured on your timeline, or it gets poured on someone else’s, with your customers standing on theirs.

Start slow. It is the only way you get to be fast.

Somewhere underneath the application you are using right now, there is a piece of software that was last updated by a volunteer who has since quit. Below that, a protocol designed as a temporary fix in the 1990s that became permanent because nobody could agree on what should replace it. Below that, a cryptographic library that — until quite recently — was maintained by two people and funded at roughly two thousand dollars a year, while securing two-thirds of the world’s web traffic.

If this sounds like a building with a cracked foundation and a penthouse under construction on the top floor, that is because the analogy is structurally exact. The only difference is that when a building’s foundation cracks, someone notices before the penthouse is finished. With software infrastructure, the penthouse gets finished, occupied, and celebrated, and the cracks keep spreading in the dark.

This is not a technology problem. This is a civilisational pattern, and it is playing out simultaneously in software, in physical infrastructure, and in every institution that rewards building new things while ignoring the maintenance of what already exists. It is the same failure mode whether we are talking about a JavaScript library or a German bridge, and the people who should be pointing it out are too busy chasing the next shiny thing to look down.

The Archaeology of the Internet

Think of the internet’s software layers the way an archaeologist thinks about a dig site. Each era left its sediment. The deepest layers — the protocols, the operating system kernels, the cryptographic libraries — were laid down decades ago by people who are mostly retired or dead. Above them sit the services and tools from the 2000s and 2010s, each built on the assumption that the layer below would continue to work. Above those sit the applications of today, built on the assumption that everything underneath is someone else’s problem.

Nobody is excavating these layers. Nobody is checking whether the foundations are still sound. The people who built them moved on, and the people building on top of them never learned the archaeology.

A Harvard study attempted to put a number on what this foundation is worth and landed on $8.8 trillion in demand-side replacement cost for open-source software alone. The Linux Foundation’s Census III found that 40 percent of the most critical non-npm projects have just one or two developers responsible for over 80 percent of all code. An $8.8 trillion system maintained by volunteers. The people extracting the value and the people maintaining the system have essentially no relationship with each other.

Two Developers, Two Thousand Dollars, and Two-Thirds of the Web

The case studies are individually alarming and collectively diagnostic. Before the Heartbleed vulnerability was disclosed in April 2014, OpenSSL — the cryptographic library securing roughly two-thirds of the world’s web servers — was maintained by two people named Steve, only one of whom worked full-time. The project received about two thousand dollars per year in donations. The bug that had silently compromised global web traffic for two years was discovered in a codebase whose annual funding could not cover a month’s rent in any city where the companies relying on it had their headquarters.

The Linux Foundation launched the Core Infrastructure Initiative within weeks, with Amazon, Facebook, Google, and Microsoft each pledging a hundred thousand dollars. OpenSSL hired its first full-time developers. The crisis response worked. The sustained commitment, predictably, did not. Initial CII funding has largely ended.

curl is installed on over twenty billion devices — phones, cars from forty-seven brands, game consoles, every cloud service you have used today. It is maintained primarily by one person, Daniel Stenberg. In January 2026, Stenberg shut down curl’s bug bounty programme because AI-generated spam reports made it unworkable. The tool meant to help secure the library that transfers data on twenty billion devices was destroyed by the very technology everyone is busy building penthouses with.

The Network Time Protocol — the system that synchronises time across the internet, without which digital certificates, financial transactions, and security protocols all break — was maintained for years primarily by one volunteer, Harlan Stenn, who gave up his consulting career to keep it running. The Network Time Foundation warned that as infrastructure weakens, security risks grow and patchwork fixes proliferate.

And then there is core-js, a JavaScript polyfill library used on over half the world’s top websites with nine billion npm downloads. Its single maintainer, Denis Pushkarev, was imprisoned for ten months in 2019. The project went dark. No updates, no security fixes. By 2023, his compensation had declined to roughly four hundred dollars a month. ReversingLabs observed the obvious: someone with crushing debt who presides over an incredibly valuable technological resource with little oversight is a prime target for state-sponsored hacker groups.

The Log4Shell vulnerability of December 2021 showed what happens when one of these foundations actually cracks. Apache Log4j, maintained by a small volunteer team, was used by an estimated 88 percent of organisations. The DHS Cyber Safety Review Board determined that fully remediating Log4Shell would take a decade. Two years later, a third of applications were still running vulnerable versions.

The Tidelift 2024 survey found that 60 percent of open-source maintainers are unpaid, 60 percent have quit or considered quitting, and the maintainer population is aging — developers over 46 doubled from 11 to 21 percent while those under 26 dropped from 25 to 10 percent. The people maintaining the foundations of the digital world are leaving, and nobody is replacing them.

The Sediment That Was Supposed to Be Temporary

Below the application code lies a geological record of things that were supposed to be temporary. IPv6 was designed starting in 1994 to replace IPv4 after address exhaustion. The last IPv4 address blocks were allocated in 2011. Thirty years later, global adoption sits at roughly 43 to 49 percent. The “temporary” workaround of Network Address Translation became the permanent crutch. IPv4 addresses now trade as commodities at roughly thirty-three dollars each.

Deeper still, 220 billion lines of COBOL remain in active production, processing three trillion dollars in daily commerce. Ninety-five percent of ATM swipes and 80 percent of in-person transactions touch it. But only 11.5 percent of COBOL programmers are under 35. The average company spends sixty-five million dollars annually on mainframe operations. Nobody rewrites the code because the failure risk is catastrophic, so it persists, maintained by an aging workforce, layered under decades of subsequent systems that everyone understands better but which could not function without it.

The CrowdStrike outage of July 2024 — possibly the largest IT outage in history — showed the margin. A faulty configuration update released at 04:09 UTC crashed 8.5 million Windows computers with Blue Screens of Death. The update was reverted 78 minutes later, but affected machines needed manual recovery. Flights grounded globally. Payment systems blocked. Hospitals disrupted. Fortune 500 losses estimated at $5.4 billion. CrowdStrike held just 18 percent of the endpoint market. One configuration file, 78 minutes, civilisational disruption.

Southwest Airlines was reportedly unaffected — because it runs software so old that it was not compatible with the update that broke everything else. There is a dark comedy in the fact that the airline routinely mocked for its ancient IT systems was the only one still flying.

The Same Pattern, in Concrete

The physical world exhibits the identical pathology, which is useful because it makes visible what software infrastructure keeps hidden.

The American Society of Civil Engineers’ 2025 Report Card gave U.S. infrastructure a C — the best grade since 1998, still representing a $3.7 trillion gap. The energy grid was downgraded to D+.

In 2014, Flint, Michigan switched its water source to save money. Officials skipped corrosion inhibitors. Lead leached into the drinking water of 100,000 residents. Twelve people died. The crisis produced a $641 million settlement and over $400 million in remediation — all from a cost-cutting decision on maintenance that nobody wanted to fund in the first place.

During the February 2021 winter storms in Texas, 4.5 million homes lost power. At least 246 people died. The grid came within four minutes and thirty-seven seconds of total collapse. Federal regulators had warned Texas after a similar event in 2011 that power plants would fail in cold weather. The recommendations were ignored because winterisation was expensive and the political reward for invisible preparedness was nil.

Germany needs €100 billion to repair its bridge infrastructure; Italy has had eleven bridge collapses since 2013. In Britain, privatised water companies paid £72 billion to shareholders while accumulating £60 billion in debt, and RAAC concrete — a material with a 30-year lifespan used extensively in buildings that are now 40 to 70 years old — forced the closure of 231 schools and 42 hospitals. The material outlived its engineering assumptions. The governance structures that should have replaced it outlived nothing.

The pattern is the same everywhere, in every material — build the new thing, cut the maintenance budget, get promoted, and leave before the cracks show.

The Incentive Trap

Why does this keep happening? Because the incentive structure makes it rational for every individual to behave in ways that are collectively catastrophic.

Political scientists Mullin and Hansen, writing in the American Political Science Review, found that voters fail to reward politicians for infrastructure maintenance. Their research demonstrates what they call the “pandering model” — politicians choose immediately popular policy even when they know informed voters would prefer long-term investment. A study in the Journal of Public Economics found that water systems built just before elections in Tanzania function significantly better today than those built just after — a 14 percentage-point difference, translating to lost water access for 9.8 million people. Elections produce infrastructure that looks good on a timeline that matches the election cycle. Maintenance has no timeline that matches anything.

Government accounting amplifies the distortion. Capital investment is classified as capital expenditure, while maintenance is classified as current expenditure — making maintenance spending look like fiscal irresponsibility. Spending less on maintenance paradoxically increases the need for politically attractive future capital projects. Neglect generates its own demand for ribbon-cuttable replacements.

Bent Flyvbjerg’s research on megaprojects found that 90 percent experience cost overruns, driven in part by what he terms “strategic misrepresentation.” Why the academic euphemism? Because calling it lying would require someone to do something about it. The result is what he calls “survival of the unfittest,” where the most unrealistic proposals win precisely because they look cheapest.

Average CEO tenure on the S&P 500 has fallen to 6.8 years. Infrastructure investment horizons span 20 to 50 years. Every CEO inherits the maintenance debt of their predecessors, adds to it, and passes it to their successors. The Stripe Developer Coefficient found that developers spend 42 percent of their working hours dealing with technical debt and bad code, which translates to roughly $85 billion in annual opportunity cost. These are not rounding errors. These are the foundations being consumed by the buildings sitting on top of them.

This is, incidentally, why monarchy worked as a governance model for infrastructure for centuries. When the monarch owned the roads, the ports, and the aqueducts, maintenance was self-interest — you were maintaining your own assets for your own heirs. The misalignment of incentives is a specifically modern problem, tied to short political cycles, corporate career rotation, and the structural impossibility of getting promoted for fixing the plumbing.

Six Hundred Billion Dollars for AI Penthouses

The AI datacenter buildout is the apotheosis of this pattern. The top hyperscalers plan to spend roughly $602 billion in 2026 on infrastructure, with 75 percent tied directly to AI. The Stargate Project targets $500 billion over four years. Jensen Huang has referenced $600 billion per year from the top four hyperscalers alone.

Every one of these systems runs on the same undermaintained open-source foundations described above. AI training runs on Linux, secured by OpenSSL, networked by curl, deployed on Kubernetes. The very foundations that are funded at thousands of dollars per year are expected to support hundreds of billions of dollars in new construction.

The funding disparity is worth pausing on. In 2026, seven major AI companies committed $12.5 million to open-source software security. They have a combined market capitalisation of approximately $7.7 trillion. The ratio of AI datacenter spending to open-source security funding is roughly 48,000 to 1. Imagine building a six-hundred-billion-dollar skyscraper and spending twelve thousand dollars on the foundation inspection.

And AI is actively making it worse. Stenberg shut down curl’s bug bounty because AI-generated reports overwhelmed the capacity of a one-person maintenance team. Open-source maintainers are drowning in AI-generated noise — AI-written issues, AI-written pull requests, AI-written security reports — all demanding human attention from people who were already overwhelmed before AI arrived. The tools being built with $602 billion are consuming the human attention of the volunteers maintaining the foundations those tools depend on.

The physical infrastructure is straining under the same pressure. Seventy percent of U.S. transmission lines and transformers are over 25 years old. The grid faces a projected 175-gigawatt capacity shortfall by 2033. Data centres consumed 66 billion litres of water in 2023, with two-thirds of those built since 2022 sited in high water-stress areas. Nobody is building new power grids. Nobody is building new water infrastructure. They are building AI datacenters on top of grids and water systems that were already failing.

The Boring Work Is the Valuable Work

The counterevidence is as clear as the pattern of failure. Infrastructure-first investment creates compounding, durable returns that application-layer investment cannot match.

A 2022 study in the Journal of Comparative Economics superimposed Roman road maps onto modern satellite imagery measuring economic activity and found that areas with greater Roman road density still show higher economic activity two thousand years later. In the Eastern Roman Empire, where roads fell into disrepair, no such persistence exists. The infrastructure caused the prosperity. The Romans knew this — Emperor Augustus appointed permanent road curators of senatorial rank, as perpetual magistracies. Milestones named the responsible official. Maintenance was prestige, not overhead.

The Eisenhower Interstate Highway System returned $6 in economic productivity for every $1 invested. Estonia rejected Finland’s offer of free analogue telephone exchanges in 1992 to build digital infrastructure from scratch — and now processes three billion queries per year through its X-Road platform, with 99 percent of public services online. South Korea invested nearly 1 percent of GDP in broadband infrastructure in the 1990s and became the global broadband leader by 2000.

In the private sector, AWS exists because Amazon recognised that its engineering teams spent 70 percent of their time on what Jeff Bezos called “undifferentiated heavy lifting” — building basic storage and compute for each project. Amazon built the infrastructure for itself, then sold it. AWS now generates $35.6 billion per quarter. Stripe, valued at $159 billion, built its moat through layered financial infrastructure so integrated that switching away requires 18 to 24 months and a full re-architecture.

Everyone can build apps. Not many can build the app store. Apple understood this from the beginning — the ecosystem is the product, not the device. The device is the interface to the ecosystem. That distinction is the difference between a company with a product and a company with a moat.

What Would Actually Help

The honest assessment is that no single intervention fixes a problem this deeply embedded in institutional incentive structures. But there are things that would meaningfully change the trajectory, and the fact that they are boring is exactly why they have not been done.

The internet is, by any reasonable measure, the largest equality-providing infrastructure project in human history. Access to education, markets, communication, financial services, healthcare information — all of it rides on software foundations maintained by volunteers funded at a fraction of a fraction of their value. The United Nations spends billions annually on peacekeeping, disaster relief, and global health infrastructure. It has never treated the internet’s software foundations as what they are: critical global infrastructure that serves more people than any physical system ever built. A dedicated annual investment — measured in billions, not the current millions — into maintaining, securing, and governing the software layers that everything depends on would be the single highest-return infrastructure investment available to the international community. The precedent exists. We fund WHO because pandemics cross borders. We fund UNICEF because children’s welfare crosses borders. The internet’s software infrastructure crosses every border on earth, serves every economy, and is funded worse than any of them.

For defence organisations and military alliances, the same logic applies with additional urgency. Every NATO system runs on Linux, OpenSSL, and the same open-source stack described above. The alliance invests considerable resources into innovation programmes designed to find the next breakthrough capability. These programmes have value. But the software foundations that every existing NATO capability already depends on receive no dedicated maintenance investment. The innovation budget is visible, reportable, and career-enhancing. The maintenance budget is none of those things. This is the ribbon-cutting bias operating at alliance level, and it creates the same structural vulnerability that it creates everywhere else — a widening gap between the capabilities being built on top and the foundations they depend on underneath.

And for every organisation — corporate, military, governmental — the intervention that costs nothing is the simplest: make maintenance visible. Track it. Report it. Treat the state of the foundations as a metric that matters as much as the state of the new projects. The Roman curators of the roads were senators, not slaves. The moment an organisation treats maintenance as something senior people own and are accountable for, rather than something junior people handle with whatever budget remains, the incentive structure begins to shift.

The Cracks Keep Spreading

There is a specific irony in writing this piece while the world is pouring more capital into technology infrastructure than at any point in human history. The $602 billion flowing into AI datacenters in 2026 is not going into foundations. It is going into the most visible, most reportable, most career-enhancing new construction available — while the software those datacenters run on, the grids that power them, and the water systems that cool them deteriorate underneath.

Every dollar of deferred maintenance grows to four to six dollars in eventual remediation costs. The U.S. General Services Administration’s deferred maintenance backlog is growing at 27 percent annually. Every week of inaction is measurably more expensive than the last.

The organisations and civilisations that thrived through infrastructure investment — Rome, Singapore, Estonia, the United States of the Interstate era, Amazon, Apple — shared one trait: they made the boring, invisible work of maintaining foundations a matter of prestige and sustained institutional commitment. The Roman curators were senators. Eisenhower staked his presidency on highways. Lee Kuan Yew made infrastructure the centrepiece of national strategy. Bezos called it “undifferentiated heavy lifting” and built a $35 billion-per-quarter business on doing it for everyone else.

The foundations are cracking. The penthouses are under construction. History has a consistent opinion about what happens when this ratio gets far enough out of balance.

The question is not whether someone will notice. The question is whether they will notice before the latency anomaly, the configuration file, the four minutes and thirty-seven seconds — or after.

The author is the AI Lead for the Command and Control Centre and Domain Architect (Medical) at the NATO Communications and Information Agency. He builds federated AI memory systems with conflict detection and is preparing to publish on delta evaluation architecture for tactical networks at the 2026 International Conference on Military Communication and Information Systems. He is particularly interested in what happens when machines need to determine whether other machines are telling the truth. The views expressed are his own.

Part 1: I built Peggy without knowing it

Last night I was going to bed, ten months after publishing a piece about professional identity infrastructure. The concept was called Peggy — a developer graph provider. Professional constellations built from contributions, not claims. Privacy-as-architecture. Federated trust. Developer commerce.

The article had sparked great conversations — with CTOs, recruiters, people who’d lived the hiring dysfunction firsthand. But there was nothing tangible to build on it. No architecture. No implementation path. So I’d archived the concept. Moved on.

Then, getting into bed — realisation hit me, I sent this to Claude in the Peggy project:

“Hey hey hey! I just realised something, the graph could live in our product Stompy — in the project Stompy, and the Stompy project of the same name! Evaluate concept” (Beautiful, I know.)

Here’s what happened. In May 2025, I wrote the Peggy article — a thesis about how developer identity should work. Then a month later, I started building a completely different product for another need. Stompy solves a much more boring problem: AI assistants keep forgetting what you told them. Context persistence across sessions. Project memory. Ticketing. We named it after the elephant — because elephants don’t forget.

I’ve spent ten months building Stompy and using it every day across every project I touched — it only launched publicly twelve days ago. Software development, AI/ML research, project management, creative writing, content strategy, hardware prototyping, business deals, legal work. Anywhere a person might use post-it notes to remember things along the way, I used Stompy instead.

63 projects. Over 18,000 documented contexts. More than 500 working sessions.

Not because I was building a professional graph. Because I was managing project memory. The graph grew as exhaust from doing the work.

Then, lying in bed, it hit me.

Stompy’s context versioning is professional history with provenance. Its project isolation is domain-specific expertise mapping. The ticketing system is delivery tracking. The truth engine architecture — designed for organisational knowledge management — is exactly the mechanism that infers professional claims from documented evidence. The federation protocol is the mesh substrate.

I’d already been building Peggy. I just didn’t know it was Peggy.

That’s either embarrassing or the strongest possible proof of the concept. Probably both.

Because the core argument of the Peggy piece was that professional graphs should form organically from tools people actually use — not from filling out profiles. Ten months later, I have a professional graph that formed organically from a tool I actually use. Nobody designed it. Nobody intended it. Not even me, until now.

But that accidental discovery also revealed something the Peggy article got wrong. Something fundamental enough that it changes the whole architecture.

Part 2: What the graph actually reveals

First, what the graph gets right.

On the software side: a full-stack space game built with Godot 4 and FastAPI with 99 out of 99 tests passing, a federated authentication architecture for national-scale data sharing, on-device ML deployment with Whisper fine-tuning for domain-specific terminology, and the Stompy product itself — 114 contexts of architecture decisions, truth engine design, federation protocol, production hardening. Beyond software: project management, academic research papers, content strategy, creative writing, hardware prototyping, business acquisitions, legal analysis.

No skills assessment platform captures this breadth. No CV communicates it. No interview surfaces it.

The graph also reveals cross-domain connections that I hadn’t articulated to myself. The federation protocol I designed for Stompy draws directly on the same ICMCIS delta evaluation principles as the NATO federated authentication paper — two completely separate projects, same architectural pattern. The truth engine architecture informs both an academic submission to IST-238 and a conference paper for ICMCIS 2026. PostgreSQL architectural decisions — pgvector, pgbouncer, connection pooling, schema isolation — recur across five independent projects, each solved slightly differently depending on constraints.

The graph connects what a profile separates. That part works exactly as the Peggy piece predicted.

Here’s what it got wrong.

Every one of those contexts is self-authored. I wrote them, or my AI assistant wrote them on my instruction. They’re rich, multidimensional, and — for what it’s worth — honest. But they’re also entirely self-reported. There is no external validation anywhere in my graph.

A well-prompted LLM generates an impressive-looking professional graph in about thirty seconds. Contribution density, collaboration reach, documentation consistency — all fabricated. Sure, every context in Stompy is timestamped, so a graph conjured in a single session would look suspicious. But a patient fabricator spreading fiction over weeks? The graph has no way to distinguish that from genuine work.

The Peggy article described the map. Ten months of building taught me what the map is missing: a way to prove the territory is real.

The data model works. The graph accumulates naturally from daily use. Cross-domain patterns emerge. The tool is useful at the individual level before any mesh exists.

What it didn’t prove: that anyone else should believe it.

Part 3: Content is private. Activity is the signal.

This is the thing we figured out that the Peggy piece couldn’t have known.

Start with why sharing the graph is harder than building it. Those projects include sensitive client work, active legal matters, commercial negotiations under NDA, and architecture that isn’t mine to share. The richer the graph, the more sensitive the material. If professional validation requires sharing raw content, it’s dead on arrival.

Most interesting professional work is precisely the work that can’t travel.

Content can’t travel. Activity can.

When a developer merges a pull request, the CI/CD pipeline knows. When a ticket moves to “Done” in Linear, the project management tool knows. When someone answers twelve questions in a Slack help channel, the bot can count. When an incident gets resolved in PagerDuty, the resolution time and root cause are recorded. When someone updates the project wiki, the documentation platform logs it.

None of that is content. It’s metadata. Activity traces generated by external systems as a side effect of people doing work. The developer didn’t author a professional claim — the tools did it for them.

Here’s how it works in practice. A team runs the usual stack — GitHub, Linear, Slack, Datadog. They add Stompy webhook integrations. Each one is a few lines of configuration. Now every merge generates a semantic reference — not a copy of the PR, but a pointer to it, with metadata that tells you more than you’d think.

A commit chain carries a surprising amount of signal without anyone seeing the actual code. The diff metadata — lines changed, files touched, file paths — reveals whether this was a surgical 3-line fix to an authentication timeout handler or a 400-line architectural refactoring across twelve files. The branch name often encodes intent: fix/auth-timeout versus feat/federation-protocol. The number of commits in the chain tells you about working style — one clean commit or twenty iterative ones. Review comments received, time from open to merge, whether it was approved on first pass or required changes. A sequence of commit → review feedback → targeted follow-up commits → merge reveals a collaboration pattern: how someone responds to critique, how precisely they scope fixes, how quickly they turn around changes.

None of that requires seeing the code. It’s metadata. The reference says something like: “Developer made a targeted fix to the authentication service, 3 lines across 1 file, addressing a review comment about edge case handling, merged within 2 hours of opening.” That’s a professional signal about how someone works — precise, responsive, fast on targeted fixes — captured entirely from Git metadata.

The content stays in GitHub. Stompy holds the interpretation. The external system remains authoritative.

Same pattern for everything else. Ticket deliveries referenced from Linear, not copied. Slack help-channel contributions tracked by a bot. Incident resolutions referenced from PagerDuty. Wiki maintenance referenced from Confluence. Course completions verified against certification IDs. Every reference authenticated via the developer’s bearer token or OAuth. One REST call. The project graph records what happened; the person’s activity trace records what they contributed. Dual attribution from a single API call.

And it’s not dumb aggregation. Every incoming reference passes through backend AI evaluation — delta evaluation to filter redundancy, conflict detection to flag inconsistencies (a Jira ticket marked “Done” while CI shows failing tests is a meaningful signal), claim extraction to infer expertise from patterns (20 PR reviews with detailed inline comments implies code review thoroughness — nobody stated this), and admiralty scoring to weight source reliability.

This creates three trust tiers:

Self-authored. What you write about yourself. An LLM does this in thirty seconds. Lowest trust.

Activity-anchored. What external systems record about you as you work. Tickets delivered, commits merged, help-channel questions answered, incidents resolved, documentation maintained. You didn’t author the record. The system did. Higher trust.

Cross-graph corroborated. Multiple independent systems — the org’s Stompy node, GitHub, Slack, monitoring — all showing the same person contributing to the same project. Faking convergence across systems you don’t control is impractical. Highest trust.

The mesh is made of the second and third tiers. Not content. Not LLM-generated summaries. Activity traces from independent systems, overlapping for the same person. The first tier corraborates the second and third.

And references don’t live at full weight forever. A React commit from 2019 is a permanent fact — it happened. Its relevance to current React expertise is not permanent. So references carry decay profiles: permanent for facts like degrees and commit SHAs, durable for architecture decisions and published papers (three-to-five-year half-life), standard for technology-specific contributions (twelve to eighteen months), volatile for Slack activity and sprint velocity (three to six months). The decay reduces weight in truth inference without deleting the reference. The graph stays current without anyone curating it.

One more thing. References prove breadth — you did the work. But they don’t explain how you think. Twenty PR merge references tagged “authentication” tell you someone worked on auth. Three architecture decision contexts explaining the trade-offs between session-based and token-based authentication tell you how they reason about it.

The Peggy piece described the graph as a constellation. The truth mesh adds: the constellation needs both stars — externally visible, independently verifiable references — and the dark matter that holds them together: the reasoning, trade-offs, and decisions that don’t show up in any external system. References for breadth. Contexts for depth. Neither alone is the full signal.

Not privacy bolted on. Privacy as the foundational constraint that shapes the architecture. The content stays sovereign. The activity traces form the mesh. Progressive disclosure — controlled by the person, at every step.

Part 4: How the mesh actually forms — and where it hasn’t yet

Each integration phase is independently valuable. No phase requires the previous one.

A team adds Stompy reference generation to their CI/CD pipeline. Three to five lines of YAML to make an API call in an existing workflow. Immediate value: the project gets a living knowledge base that updates on every merge. Activity traces per developer start accumulating. Adoption cost: negligible.

They connect their Linear or Jira instance. Ticket lifecycle flows into the project graph. Delivery patterns become visible — who shipped what, estimation accuracy over time, sprint carry-over. The project management tool already has this data. Stompy just gives it a semantic structure and links it to everything else.

A Slack bot captures help-channel contributions and architecture discussions. Mentoring activity — answering questions, explaining decisions, unblocking colleagues — becomes visible as a professional signal. Something no CV captures. Something no GitHub heatmap shows.

Monitoring, documentation, learning platforms complete the picture. Incident handling, knowledge stewardship, skill development. Each integration adds a layer. Each layer is useful on its own.

The mesh forms when a second organisation does the same thing and a developer works across both. Two independent project graphs with overlapping contributors. Activity traces from different toolchains converging on the same person. Nobody planned it. The webhook integrations created it.

Now here’s where I have to be honest about what actually exists versus what’s architecture.

Stage 1 — individual utility — is proven. The graph accumulates from daily use of a tool that solves an immediate problem. This works.

Stage 2 — cross-domain patterns — is partially proven. The connections across projects are visible in the data. The truth engine that would infer them automatically is designed in detail — admiralty scoring, conflict detection, confidence computation, collation engine — but not yet implemented. Truths are still inferred by humans reading across projects, not by the system.

Stage 3 — external reference integration — is designed but not built. (It will be soon on Stompy development to see what comes out of it.) GitHub, LinkedIn, Slack, CI/CD, monitoring, documentation, learning platforms as reference sources. The reference primitive is specified. The API surface is REST plus bearer token. Mechanically simple. Not yet shipping.

Stage 4 — organisation node integration — is designed but not tested. Requires a second party using Stompy. The chicken-and-egg problem.

Stage 5 — the actual mesh — is theoretical. Depends on Stages 3 and 4. The ICMCIS delta evaluation protocol is designed for exactly this kind of federated validation. But federation between independent Stompy instances hasn’t been implemented.

Proven. Partially proven. Designed. Designed. Theoretical.

Part 5: The cold start isn’t cold

After publishing this concept, the first serious challenge came from an AI strategist: “You can’t document the past, the preferences and the behaviour with that approach. So I am thinking more about the need for a protocol with your added Truth layer inside.”

Fair point. If the graph only captures forward activity, a new user starts with nothing. Years of professional history — invisible.

Except the history already exists. It’s sitting on your machine.

Every developer’s laptop is a fossil record of professional activity. Git repositories going back years — every commit timestamped, every file change recorded, every commit SHA cryptographically verifiable. You don’t need an API for this. You don’t need OAuth. You tell Claude Code or a CLI tool to walk your project folders, and within minutes you have references spanning your entire development history. No code content leaves the machine. Just metadata: commit messages, file paths, diff stats, branch patterns, co-authorship.

I ran exactly this while writing this article. One scan across a project folder found 27 repositories spanning eleven years and over 3,500 commits. The scanner automatically clustered them into five domain groups — AI platform, military medical, commercial products, game development, hardware — without being told the categories existed. It detected nine programming languages, Docker in eight repos, CI/CD pipelines in eleven. It found a clear inflection point in 2025 where AI-assisted development produced a ten-fold increase in output. It surfaced over a thousand co-authored commits with an AI pair programmer — a professional signal that didn’t exist two years ago. All of this from metadata. No code read, no files opened, no profiles filled out. Twenty-five structured references generated in a single session, covering a decade of work.

But git is only the beginning of what’s on that machine.

A package.json tells you someone works with React, Express, and TypeScript. A requirements.txt says Python, FastAPI, pgvector. A Cargo.toml says Rust. These aren't self-reported skills on a LinkedIn profile — they're dependency files from actual projects. The technology stack is declared by the project, not the person.

Dockerfiles reveal containerisation patterns. Terraform files document cloud architecture decisions. Kubernetes manifests show orchestration experience. CI/CD configs — .github/workflows, .gitlab-ci.yml, Jenkinsfile — prove DevOps capability through the pipeline definitions themselves. Test directories and coverage reports indicate testing discipline. Architecture Decision Records are literally documented reasoning.

None of this is content that needs to leave the machine. It’s structural metadata. The presence of a docker-compose.yml with twelve services is a different professional signal than a single-container setup. A Terraform directory managing three AWS accounts tells you something different than a student's first EC2 instance. The file structure IS the evidence.

This is where the concept gets extensible. Each type of source — git history, package files, Docker configs, Terraform state, CI pipelines, test coverage — needs its own scanner that knows how to extract the right signal. A git scanner understands commit chains. A Terraform scanner knows that managing a VPC with multiple subnets and NAT gateways is a different complexity tier than a single S3 bucket.

In Stompy, these scanners are skills — modular, composable, and open for community contribution. A Ruby developer writes a Gemfile scanner. A data scientist contributes a Jupyter notebook skill that maps analysis patterns. A DevOps engineer builds a Helm chart scanner. The skill framework is the integration surface. The community builds the specific extractors.

Each skill produces references with appropriate trust tiers and decay profiles. A local git commit SHA is cryptographically verifiable — Tier 2 for anyone who has access to the repo, even if it was never pushed to GitHub. A package.json dependency list is factual but changes frequently — standard decay. A Terraform state file documents infrastructure that might no longer exist — event-conditional decay tied to whether the infrastructure is still live.

When you combine local scanning with external API integration — GitHub for PR reviews and public verifiability, Stack Overflow for community-validated expertise, LinkedIn for network corroboration — the cold start disappears. A developer connects their accounts, points the scanner at their project folders, and within minutes has a graph spanning years of professional history across multiple trust tiers.

Not because they filled out a profile. Because the tools they already used left traces they never thought about.

Part 6: What we don’t pretend to have solved

While developing the Peggy concept, I talked to a bunch of people — we have our Linkedin chat, but I will anonymise a few here: a CTO, a recruiter, and an innovation strategist. Their insights landed differently after actually building the thing.

The CTO splits hiring decisions into two clean halves. Fifty per cent is technical competence — skills, proof, experience, commit history. The other fifty per cent is character and culture — attitude, collaboration, whether someone improves the room they walk into. His exact words: “No data would convince me to hire without at least a few calls, ideally face-to-face over lunch.” Oh, normally Steve would say “beer” instead of lunch, but he has just launched a book and it is very good, you should read it.

The mesh handles the first fifty per cent. Activity traces across multiple projects, from independent systems, cross-referenced for convergence. Technical competence validated through documented evidence rather than whiteboard puzzles and take-home assignments. Four interview rounds become one, focused entirely on the part that actually requires a conversation.

The innovation strategist pushed harder: “Developers should be graded on work they do, instead of name of college or if they make you feel good.”

Both right. And in tension. The mesh eliminates performance theatre — the artificial tests, the HackerRank gauntlets, the whiteboard problems that correlate with nothing except whiteboard-problem practice. That satisfies both positions. But the culture-fit half stays human. The mesh doesn’t pretend that’s solved. It shouldn’t.

The open questions, stated plainly:

Activity traces measure presence and delivery. They don’t directly measure quality. Forty references to merged PRs could mean forty thoughtful contributions or forty rubber-stamped boilerplate. The semantic description helps distinguish “authentication middleware refactoring” from “fixed typo in login page.” But the depth problem is real. References prove breadth. Contexts carry quality. And contexts are the least trustworthy tier — self-authored. This tension lives in the architecture.

Information decay keeps the graph current. It also penalises accumulated experience. Someone who stopped contributing two years ago might still have deep expertise — their references have just decayed. Probably right for fast-moving technical fields. Probably wrong for deep domain knowledge. Defence programme management doesn’t expire in eighteen months.

The backend AI evaluates every reference — delta evaluation, conflict detection, claim extraction, admiralty scoring. If it misinfers, the trust tiers don’t help. The system’s intelligence is a single point of interpretive failure.

Full-stack integration generates a lot of references. Signal-to-noise at scale is genuinely unsolved.

Cross-graph corroboration makes individual fraud impractical. Coordinated fraud — two people mutually validating fictional work across multiple org nodes — remains possible. The mesh raises the cost of fraud. It doesn’t eliminate it.

Activity traces across enough independent systems might uniquely identify someone even at the anonymised summary level. Comprehensive traces and perfect anonymity may be structurally incompatible.

And: how does the second org start? Everything before Stage 5 works with one person or one org. The mesh requires independent parties. The CI/CD path makes adoption cheap — add a webhook, get immediate value from a living project knowledge base. But cheap isn’t free. Someone has to go second.

Every experienced technical lead runs a truth mesh in their head. The mental map of who delivers, who maintains systems, who you’d bring onto the next project without hesitation. Built from exactly this: overlapping experience on shared work. Activity traces, not CVs. References you can verify, not claims you have to trust.

The question from the Peggy piece was whether professional identity could be built from contributions, not declarations. Ten months of building taught us the answer is yes — with a caveat. The graph is the easy part. The trust is hard. Making trust scale without centralising it, without exposing sensitive content, without turning professional identity into another thing people perform rather than something that captures how they actually work — that’s the remaining problem.

It’s a good problem. It’s the right problem. And the architecture, as it turns out, was building itself while I was solving something else entirely.

The Author builds things on the internet and has been doing so for 30 years. Currently an AI Lead at the NATO Communications and Information Agency by day, and building Stompy — a federated AI memory platform — by night. He has found a new passion in scientific research with capable colleagues and he is sorry for it as normally things stayed inside his head. Previously rescued projects, optimised portfolios, and scaled product teams across defence, fintech, and enterprise.

The original Peggy article: Peggy — The Developer Graph Provider for Technical Collaboration

Stompy is open for business at stompy.ai. The rubber chicken is not included but should be.

BLUF: Every AI memory company claims 80–95% token savings. We ran a controlled benchmark on a production codebase and measured 15–28%. Memory doesn’t make coding agents write better code — all conditions hit the same 84–96% quality ceiling. What it does is reduce exploration overhead: fewer turns, lower cost, faster completion on complex tasks. The effect scales with codebase complexity and vanishes on simple tasks. Nobody else has published this measurement. We think that’s the problem. In our attempt to be open and transparent, we also release everything on Github. The broader report itself is here: https://www.stompy.ai/stompy-memory-benchmark-report.pdf (PDF, 206kb)

The Number Everyone Quotes, Nobody Explains

Every AI memory company claims 80–95% token savings. Mem0 says 90%. A-Mem says 85–93%. MemMachine says 80%. Zep says 94.8%.

These numbers are technically correct and practically meaningless for anyone building coding agents.

Mem0’s 90% measures memory footprint compression — 26,000 tokens of conversation history condensed to 1,800 tokens of extracted facts. Not whether a downstream task completes faster. A-Mem’s 85–93% measures tokens consumed per memory operation — the cost of storing and retrieving, not the cost of the task the memory supports. MemMachine’s 80% was measured on LOCOMO, a benchmark that tests whether a system can recall facts from long conversations (“What restaurant did I mention last Tuesday?”). Zep’s 94.8% measures retrieval accuracy — whether the right memory was found, not whether finding it improved anything.

Every published benchmark tests conversational recall. None tests coding.

This matters because developers don’t need AI to remember their dietary preferences across sessions. They need AI to remember that the codebase uses a provider pattern, that the payment service is idempotent, that the test fixtures live in conftest.py — and to use that knowledge to avoid re-exploring architecture it already mapped yesterday.

We asked a simple question: does persistent memory help an AI coding agent work more efficiently on a real production codebase?

The answer is nuanced, which is exactly why nobody else has published it.

What We Tested

We ran three conditions on the Stompy backend itself — a production Python/FastAPI/PostgreSQL codebase (4,895 lines in the main server module, 158 Python source files, 563 Python files total with tests and tooling):

Three tasks of increasing complexity, from modifying a single function (moderate) to implementing rate limiting with Redis and tiered policies across the authentication system (very high). Same model (Claude Opus 4.6), same scoring rubric, same codebase state.

Nine runs. Three conditions × three tasks.

The Uncomfortable Truth (For us, initially)

Persistent memory does not improve code quality.

All three conditions achieved 84–96% scores across all tasks. The quality ceiling is a property of the model, not the memory system. Given enough turns, every condition finds the right answer.

The file condition actually scored highest overall: 68/75 versus 67/75 for both stompy and nomemory. We report this without qualification.

If your goal is maximum quality regardless of cost, a well-crafted context file wins.

The Real Finding

What memory does — and all it does — is reduce exploration overhead.

The efficiency advantage is 14% over nomemory and 16% over file. Not 90%. Not 80%. Fourteen percent.

But Here’s Where It Gets Interesting

The effect scales with complexity.

On the simple task, memory was pure overhead. The no-memory agent was fastest, cheapest, and used the fewest turns. There wasn’t enough architecture to remember.

On complex tasks — the kind that require understanding service patterns, database conventions, and middleware architecture — memory saved 22–32% cost and 28–40% turns. The no-memory agent needed 63 turns where the memory agent needed 45. Those 18 extra turns are pure exploration: reading files, mapping imports, discovering patterns the memory agent already knew.

Think of a senior developer who knows the codebase versus a competent contractor who reads everything each morning. Same code quality. Different cost to get there.

The Complexity Threshold

A prior benchmark phase on a toy Express/TypeScript codebase (about 200 lines) confirmed this pattern from the opposite direction: no-memory won outright, 70.3% versus 59.5%.

Memory on a trivial codebase is overhead. Memory on a production codebase is efficiency. The threshold exists because memory retrieval has cost — MCP calls consume tokens — and that cost must be amortized over sufficient discovery savings.

Part of this overhead is specific to the integration path. MCP is the heaviest option — the LLM decides what to retrieve, formulates queries, processes returned contexts within its token budget. Lighter integrations (direct API calls, CLI pre-injection) deliver the same knowledge with lower per-call overhead by moving retrieval logic outside the model’s reasoning loop. This benchmark used MCP exclusively because it’s the primary interface for chat-based coding agents, but the overhead profile differs for other integration paths.

This should inform memory system design: aggressive retrieval on every task is wasteful. Adaptive retrieval — more context for cross-cutting architectural work, less for well-scoped modifications — matches the observed pattern.

Why Nobody Else Published This

Four reasons:

Wrong benchmarks. LOCOMO is tractable and produces impressive numbers. It is also categorically different from coding agent evaluation. Testing memory on conversational recall is like testing a car’s engine by measuring its paint quality.

Wrong metrics. “Token savings” gets reported as memory compression or per-operation cost, not task efficiency. A system that compresses 26,000 tokens to 1,800 stored tokens has not demonstrated that any task completes 90% cheaper.

Incentive misalignment. A controlled benchmark on coding tasks might reveal modest gains — as ours did. Marketing prefers 90% to 15–28%.

Methodological cost. These benchmarks are expensive. Each run consumes real API tokens. Nine runs cost us about $23. A full factorial with multiple models would cost hundreds. The economics favor cheap conversational benchmarks over expensive task-based ones.

We don’t claim bad faith. We claim insufficient rigor in an immature field.

Regarding the broader implications: To our knowledge, this is the first controlled benchmark that isolates persistent memory as an independent variable and measures its effect on coding agent task efficiency — resolution rate, token cost, and completion time — across identical tasks. Adjacent work exists but addresses different questions. SWE-ContextBench (Zhu et al., 2026) evaluates experience reuse from a static pool of prior task trajectories, finding that oracle-provided summaries improve resolution by 8 percentage points — but the experience pool is pre-built, not accumulated by a memory system during operation. EXPEREPAIR (Mu et al., 2025) ablates a dual-memory repair agent on SWE-Bench Lite, confirming both episodic and semantic memory components contribute to performance — but as a system paper with ablations, not a reusable benchmark.

GitHub Copilot’s production A/B test (January 2026) reports a 7-point increase in PR merge rates with agentic memory enabled — but on heterogeneous real-world tasks with no reproducibility path. Meanwhile, every dedicated memory system (Mem0, Zep, Letta, MemMachine) benchmarks exclusively on conversational recall tasks like LOCOMO, and every coding benchmark (SWE-bench, Terminal-Bench) treats tasks as independent episodes with no memory between them. The intersection — persistent memory × coding agents × controlled efficiency measurement — is where we planted our flag. If someone got there before us, we couldn’t find them. Sorry.

The File Condition Deserves Respect

The file condition deserves careful reading. It achieved the highest quality (68/75) while being more expensive than Stompy.

A well-written context document is genuinely valuable. If you’re working on a single codebase and willing to maintain a living architecture doc, that might be all you need.

But the file condition doesn’t scale. Even a small team will struggle to maintain a single coherent context file as architecture evolves, conventions shift, and contributors disagree on what’s current. It can’t be selectively retrieved (the agent reads the entire file regardless of task), can’t detect conflicts between what’s documented and what’s actually in the code, and provides no versioning or attribution.

The file condition tells us: having the right knowledge matters. The memory system question is how to deliver that knowledge efficiently at scale.

Limitations

We report these not as pro forma caveats but because the absence of transparency is precisely what makes competitor claims unreliable.

Single model. All runs used Claude Opus 4.6. Different models may respond differently to memory context.

Single codebase. Python/FastAPI. Other languages and frameworks may show different patterns.

Our system, our codebase. We tested Stompy’s memory on the Stompy backend itself. We know this code intimately. Generalizability requires replication on external codebases.

Nine runs. One per cell. We report observed differences, not statistically significant effects. This is a pilot study establishing methodology, not a definitive claim.

Pre-loaded contexts. Hand-curated from real development. Automatically generated contexts may perform differently.

We publish these limitations because 15–28% with full transparency is worth more than 90% without any.

What This Means

Persistent AI memory doesn’t make coding agents write better code. It makes them write the same code cheaper — 15–28% cheaper, with 28–40% fewer turns on complex tasks. This scales with codebase complexity and vanishes on simple tasks.

The benchmark gap matters more than our specific numbers. An entire industry benchmarks on conversational recall while marketing to coding use cases. LOCOMO tests whether a system remembers dietary preferences. Our benchmark tests whether a system reduces the cost of implementing rate limiting on a production API. These are different questions.

We built a memory system. We tested it honestly. The results were modest.

Then we looked at what everyone else claims — and realized nobody tested theirs at all.

What’s Next

This benchmark is the first in a series. Three studies are in progress:

Agent swarms. Where a single agent re-explores architecture across sessions, multiple agents re-explore across each other — compounding the redundancy. Industry data suggests multi-agent systems consume 1.5–7× more tokens than necessary due to coordination overhead. We’re benchmarking a six-agent swarm on a production codebase with and without shared persistent memory. If single-agent memory saves 15–28%, shared memory across coordinating agents should save substantially more by eliminating the N-agent duplication of architectural discovery.

Multi-model validation. This benchmark used one model (Claude Opus 4.6). We’re extending across model families using open coding agent frameworks (OpenCode and similar) — testing Sonnet 4.5, GPT-5-Codex, and Gemini 2.5 Pro. Different models may respond differently to memory context, particularly those with smaller context windows where selective retrieval matters more.

Serialization format efficiency (TOON vs JSON). Memory systems serialize context for storage and retrieval. Stompy already supports both JSON and TOON (a token-optimized notation). We’re benchmarking whether format-level token efficiency compounds with memory-level efficiency — whether delivering the same knowledge in fewer tokens shifts the complexity threshold at which memory becomes cost-effective.

We also plan to run LOCOMO to contextualize Stompy against competitors on their own benchmark, and a longitudinal 27-session study tracking efficiency across sustained development.

Each study will be a separate paper. We built a memory system. We tested it honestly. We’re not done testing.

This first report is available from our website: https://www.stompy.ai/deep-dive

The benchmark code, scoring rubrics, and raw results are and future ones will be published alongside this paper, which you can find on GitHub: The benchmark code, scoring rubrics, and raw results are published alongside this paper, which you can find in its own GitHub repo: https://github.com/banton/stompy-benchmark

The author builds Stompy, a persistent AI memory platform. He works at NATO Communications and Information Agency by day and builds software by night. He’s been creating internet-based software for 30 years and still thinks honest numbers beat impressive ones.

References

1. Chhablani et al., “Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory,” ECAI 2025. arXiv:2504.19413 https://arxiv.org/abs/2504.19413
2. Li et al., “A-Mem: Agentic Memory for LLM Agents,” NeurIPS 2025. arXiv:2502.12110 https://arxiv.org/abs/2502.12110
3. MemMachine, “LLM Memory Benchmark Results,” 2025 https://memmachine.ai/blog/2025/12/memmachine-v0.2-delivers-top-scores-and-efficiency-on-locomo-benchmark/
4. Zep AI, “Deep Memory Retrieval,” 2024 https://blog.getzep.com/state-of-the-art-agent-memory/
5. Packer et al., “MemGPT: Towards LLMs as Operating Systems,” ICLR 2024. arXiv:2310.08560 https://arxiv.org/abs/2310.08560
6. Letta, “LOCOMO Benchmark Analysis: Filesystem Baseline Results,” 2025 https://www.letta.com/blog/benchmarking-ai-agent-memory
7. Maharana et al., “Evaluating Very Long-Term Conversational Memory of LLM Agents,” ACL 2024. arXiv:2402.17753 https://arxiv.org/abs/2402.17753
8. Jimenez et al., “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024. arXiv:2310.06770 https://arxiv.org/abs/2310.06770
9. Hong et al., “MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework,” ICLR 2024. arXiv:2308.00352 https://arxiv.org/abs/2308.00352
10. Galileo AI, “Hidden Costs of Multi-Agent LLM Systems,” 2025 https://galileo.ai/blog/multi-agent-coordination-strategies
11. Mikiko Bazeley, “Why Multi-Agent Systems Need Memory Engineering,” O’Reilly, Feb. 2026 https://www.oreilly.com/radar/why-multi-agent-systems-need-memory-engineering/

At the NATO TIDE Hackathon in Reykjavik in February 2026, CERT-IS presented something in the introduction I hadn’t considered before deeply enough.

Phishing has broken the language barrier.

For two decades, speakers of Icelandic, Finnish, Estonian, and other small languages had an accidental security advantage. Phishing emails targeting these populations were laughably bad — machine-translated gibberish that no native speaker would take seriously. An Icelandic bank customer could spot a fake email because no criminal organization had fluent Icelandic speakers on staff, and Google Translate produced something that read like a fever dream.

LLMs changed that. They write grammatically flawless Icelandic. They nail Finnish case endings — all fifteen of them. They produce native-quality text in languages spoken by fewer people than attend a mid-sized football match. For the 370,000 speakers of Icelandic and 5.5 million speakers of Finnish, the economics of targeted phishing just shifted. Previously, you needed a native speaker to craft convincing bait. Now you need an API call.

That observation led me to a question that should have been asked — and solved — a long time ago.

The Question Nobody Bothered to Ask

Can a citizen verify that a specific email was actually sent by the organization claiming to have sent it?

Not “did the email come from the right server.” Not “did the domain pass a DNS check.” Can a regular person confirm that this particular email from their bank, their tax authority, their government — is real?

The answer, in every country on Earth, is no.

Think about what happens when a Finnish grandmother — let’s call her Aino — gets a perfectly written Finnish-language email from “her bank.” The email uses her real name. It references her branch. The Finnish is flawless because an LLM wrote it. The sending address looks right. The logo is pixel-perfect.

Aino has exactly zero tools to verify this email. She can’t call a number to check. She can’t forward it somewhere for verification. She can’t look up a fingerprint or reference code. There is no national service, no bank-operated verification API, no public registry she can query. Her only option is the same guidance we’ve been giving people since 1995: “Look for signs it might be fake.”

We’ve had public-key cryptography for decades. We put a man on the moon with less computational power than sits in Aino’s pocket. And nobody has built a system that lets her check if her bank actually emailed her.

That’s not a technology problem. That’s a priorities problem.

Five Protocols, Zero Solutions for Actual Humans

We have five different email authentication protocols. DKIM, SPF, DMARC, BIMI, S/MIME. Five standards, maintained by thousands of engineers, deployed across billions of mailboxes. Not a single one solves the problem for the person receiving the email.

DKIM adds a cryptographic signature to every email — functionally a “fingerprint per email.” But it authenticates the domain, not the sender. It proves a message transited authorized infrastructure, not that a specific person authored it. DKIM signatures are verified by the receiving mail server and then effectively discarded. There is no place Aino can check them. The verification happens between machines, without her knowledge. And DKIM breaks when emails are forwarded — which is precisely what you’d want to do with a suspicious message.

SPF checks whether the sending server is authorized for that domain. Useful. Invisible to humans.

DMARC ties SPF and DKIM together. It’s the most impactful of the bunch — Google’s 2024 enforcement blocked 265 billion unauthenticated emails. But DMARC operates at the domain level. It can tell Gmail’s servers to reject anything claiming to be from mybank.fi that doesn’t pass authentication. It cannot tell Aino “yes, this specific email was sent by your bank at 14:32 today.”

BIMI displays verified brand logos next to authenticated emails. Gmail shows a blue checkmark. This is actually moving in the right direction — a visual trust signal for humans. But adoption is at 5.7% of domains and Microsoft Outlook doesn’t support it.

S/MIME should have solved everything. Per-user, per-message digital signatures using PKI certificates. Nearly 30 years old. Near-zero consumer adoption. Per-user certificate management, both-parties-must-participate requirements, webmail incompatibility, cost. Usage has been limited to government classified systems and tech enthusiasts.

Here’s the pattern: every solution authenticates machines to machines. None of them authenticate organizations to humans. The entire email security stack was built for infrastructure, not for citizens.

Governments That Tried — and Stopped Short

Some governments have taken this seriously, to a point.

The US set the benchmark in 2017 with Binding Operational Directive 18–01, requiring all federal civilian agencies to implement DMARC at maximum enforcement within one year. By late 2018, 81.6% of surveyed .gov domains complied. CISA required centralized DMARC reporting — the closest thing that exists to a national email authentication data collection point. The UK mandated DMARC for all gov.uk services in 2016. The Netherlands adopted a “comply or explain” mandate in 2018. Denmark, New Zealand, Australia — all moving in the right direction.

But globally, only 30.5% of government domains use DMARC at all. And even the leaders only authenticated the domain. They protected their infrastructure. They did not build anything that helps Aino.

The pattern is familiar from every government technology initiative I’ve been involved with: organizations optimize for institutional metrics rather than user outcomes. DMARC adoption percentages look great in compliance reports. They mean nothing to the person staring at a suspicious email.

What If We Built the Obvious Thing?

Here’s the concept that formed in Reykjavik.

A national outgoing email fingerprint registry. Every official email — government, banking, regulated institutions — gets a unique cryptographic fingerprint registered against a centralized national API before it’s sent. The fingerprint is embedded in the email as a verifiable reference code.

Citizen receives a suspicious email from “the tax authority.” Three verification options:

Lookup: Copy the reference code, paste it into a national verification website. The system confirms whether the email was dispatched or not.

Forward: Send the entire email to a national verification address — something like verify@island.is. An automated system checks the fingerprint and responds.

Automatic: Email client integration where verification happens in the background, similar to how browsers show the padlock for HTTPS.

Think Certificate Transparency, but for email. Google already requires all TLS certificates to be logged in public, append-only, cryptographically verified logs before browsers trust them. The same principle applied to official emails — not logging content, but logging the fact that an email with a specific hash was legitimately dispatched by an authorized sender.

But here’s what makes this approach fundamentally different from every other solution on the table: verification is transferable.

Every existing email security mechanism — DKIM, DMARC, BIMI, even the MTA-level approaches being standardized — requires the recipient’s email client or mail server to do the work. The security lives inside the infrastructure that Aino doesn’t control and doesn’t understand. If her email provider doesn’t support BIMI, she doesn’t get the checkmark. If her client doesn’t surface authentication headers, she sees nothing.

A fingerprint registry inverts this. Aino doesn’t need to understand cryptography. She doesn’t need the right email client. She calls her granddaughter: “I got a strange email from the bank, the code at the bottom says VR-2026–4471.” Her granddaughter checks the national registry from her phone in thirty seconds. Or Aino forwards it to verify@island.is and waits for the response. Or her neighbor does it. Or the librarian at the local library.

The verification isn’t locked to a device, a client, or a level of technical literacy. It’s a public, human-accessible infrastructure. That’s not a technical distinction — it’s a completely different security model. One that works for the people who are most vulnerable to phishing: the ones who can’t configure S/MIME and never will.

And here’s why the location of the hackathon is relevant.

Iceland’s Auðkenni electronic ID system has 97% adoption among the eligible population. Government-owned, built on the government-controlled Íslandsrót root certificate, supporting qualified electronic signatures at the EU’s highest security level. The infrastructure for national-scale cryptographic verification already exists and is already trusted by essentially every citizen.

Population: 380,000. Small enough to deploy quickly. Digitally mature enough to handle the requirements. And newly motivated — thanks to AI-generated Icelandic phishing — to actually do something about it.

If any country could build this, it’s the one where the hackathon happened.

The Engineering Reality

Let me be clear about what this system actually is, because it’s easy to overcomplicate it.

When a government agency or regulated bank sends an email, the sending server calls a national API. The API generates a unique fingerprint — an official stamp — and registers it. Four fields: fingerprint, sending organization, timestamp, partial recipient identifier. The fingerprint is included in the email. That’s it.

The API is queryable. Citizen pastes a code, gets a response: “This fingerprint was generated by the Icelandic Tax Authority at 14:32 on February 25, 2026, for a recipient matching your description.” Or: “No record found.”

This is not end-to-end cryptographic email verification. It’s not a content hash. It doesn’t break when emails are forwarded, because the fingerprint isn’t derived from the message content — it’s an identifier registered at the point of sending. The email could be forwarded seventeen times through four mailing lists and the fingerprint still works, because you’re checking a code against a database, not recalculating a hash.

Privacy: Governments already maintain audit trails of outbound communications. This adds one field — a fingerprint — to an existing obligation. The registry stores organizational sender, timestamp, fingerprint, and a partial recipient identifier. No email content. No metadata beyond what the sending organization already logs.

Liability: The system confirms one thing: “We generated and sent a message with this fingerprint.” Which they did. This is not a judgment about whether the email is safe, trustworthy, or free from compromise. It’s a confirmation of origin.

Cost: This is an API backed by a database with four fields per record. Whitelisted government IP addresses, zero trust integration into existing mail sending infrastructure, automatic fingerprint inclusion at the point of sending. The build should cost well under a million. Each API call costs effectively nothing. Storage is minimal, fully anonymous, cacheable, and can be archived after 90 days. For a country like Iceland — 380,000 people, a manageable volume of official email — this is a small infrastructure project, not a national program.

What the Scammers Do Next

Suppose someone builds it. Then what?

The first thing scammers do is add fake fingerprints to their phishing emails. Most people won’t check — they’ll see a code that looks official and assume it’s real. The second, more patient move: scammers build fake verification pages. A site that looks like verify.island.is but isn’t, returning “Verified” for every query.

These are predictable attacks, and the system design needs to account for them from day one.

The fingerprint validation response must be rich, not binary. A simple “verified” or “not verified” is too easy to fake and too thin to be useful. The response should include the sending organization, the timestamp, and a partial identifier for the recipient — enough that Aino can confirm “yes, this was sent to me, today, by my bank” but not enough to be useful to an attacker harvesting data. This also prevents reuse of old legitimate fingerprints in new attacks, because the timestamp and recipient won’t match.

Push, not pull. Instead of sending citizens to a website — which can be faked — the verification could go the other direction. Aino requests verification, and the national system sends a confirmation to her registered eID. Iceland’s Auðkenni already supports push notifications. She doesn’t visit anything. She opens the app she already trusts and sees the result. The scammer can’t fake the push because they don’t control the eID infrastructure.

Build verification into the eID app itself. Auðkenni, Finland’s suomi.fi app, whatever the country already has at high adoption. A “verify email” function inside a trusted, installed application eliminates the fake website vector entirely. The citizen never opens a browser for this.

An automated phone service. For seniors who don’t use apps, a phone number — memorable, well-publicized — where you read the fingerprint code and hear the verification result. Low-tech fallback for high-risk populations. This costs almost nothing to operate.

The absence of a fingerprint becomes the signal. If every legitimate official email carries a fingerprint, then no fingerprint means not real. This is the HTTPS padlock model. It took time, but billions of people learned to look for it. The end state is powerful: citizens learn that official emails without codes are suspicious by default.

The registry becomes a sensor network. If thousands of fingerprint checks suddenly fail for emails claiming to be from a specific bank, that’s real-time phishing campaign detection. The verification infrastructure doubles as an early warning system — something no current email security mechanism provides.

One domain, memorable and short. Finland has suomi.fi. Iceland has island.is. The verification URL needs to be something a grandmother can memorize and spot when it’s misspelled. This is a branding problem as much as a technical one, and it matters.

What’s interesting about this layered approach is that it’s self-reinforcing. Any country can start with the basic fingerprint lookup — a website and a forwarding address. That’s the floor. Nations with mature digital identity infrastructure get tighter integration: push verification through eID apps, automated phone services, in-app checking. The more digitally mature the country, the more vectors it can close. And the visible success of the basic system creates pressure to build the infrastructure for the tighter versions. Countries that see Iceland’s eID-integrated verification working don’t just adopt the fingerprint concept — they invest in the national digital identity infrastructure that makes the advanced mitigations possible. The registry doesn’t just solve a phishing problem. It creates a reason to solve the digital identity problem.

What We Should Also Be Doing

The fingerprint registry is simple and cheap. But it doesn’t replace the infrastructure work that should be happening in parallel — it complements it.

Mandatory DMARC at maximum enforcement for every government and regulated financial institution domain. Not “comply or explain.” Not “best practice.” Mandatory, monitored, enforced. The US proved this works at scale. New Zealand proved it works as a national mandate. There is no technical reason every NATO nation hasn’t done this already. This is the floor.

A national BIMI verified sender program. Governments deploy Government Mark Certificates. Regulated banks deploy Verified Mark Certificates. Every official email shows a verified visual indicator — something Aino can actually see without inspecting email headers.

A public verified sender domain registry. An authoritative, government-maintained, publicly accessible list of every legitimate government and banking sending domain in the country. A website where any citizen can check “is @vero.fi actually the Finnish tax authority?” This basic lookup doesn’t exist in most countries. It should take about a week to build.

MTA-level sender authentication surfaced to users. There’s a promising path through existing SMTP infrastructure. Hop-by-hop encrypted SMTP with mutual TLS authentication, where the receiving mail server verifies the sending server’s identity against DNS MX records and then passes that authentication status through headers to the user’s email client. Several RFCs already define the building blocks, and Internet-Drafts exist for the header elements and email client UI indicators. The only genuinely novel piece is client authentication by MTAs — and the standardization work is underway. This approach is pragmatic and works within the existing architecture. The catch: it still requires email clients to surface the results, which means adoption depends on Google, Microsoft, and Apple deciding this matters enough to implement.

These are all worth doing. They harden the infrastructure layer. But they all share the same limitation: they depend on the recipient’s own email system doing the work. If Aino’s email client doesn’t support BIMI, she sees nothing. If Microsoft doesn’t implement MTA authentication UI, nothing changes for Outlook users.

The fingerprint registry is the only piece that works independently of the recipient’s infrastructure. It’s the only one where Aino’s granddaughter can help from a different device. And it’s the cheapest to build.

The Actual Pattern Here

Email is the last major communication channel where the sender’s identity is essentially unverifiable by the recipient.

We solved this for websites — TLS certificates, padlock icons, browser warnings. A grandmother can tell if a website is verified. We solved it for documents — digital signatures in Estonia, Finland, Iceland, millions of people routinely verify document authenticity. We solved it for banking — Strong Customer Authentication under PSD2 means every European bank verifies customer identity through multiple factors.

But the one channel that serves as the primary vector for financial fraud, identity theft, and social engineering? Still running on trust and the assumption that people can somehow tell good emails from bad ones.

The European Commission acknowledged this when PSD3 explicitly recognized that PSD2 was “not equipped” for spoofing fraud where criminals impersonate banks. The regulation focused entirely on authenticating customers to banks — never banks to customers. Every banking regulator in the world has the same blind spot.

We build security for machines and hope it somehow reaches people. We optimize for compliance metrics and assume they map to actual safety. We create sophisticated technical architectures that are invisible to the citizens they’re supposed to protect.

DMARC adoption rates look excellent on dashboards. They mean nothing to Aino.

Someone Needs to Go First

The hackathon ended. Thirty-two teams from twenty-one countries presented their solutions. The observation CERT-IS raised — that AI has erased the linguistic protection that small nations relied on — doesn’t have a hackathon-shaped answer.

It has an institutional one. Someone needs to build the bridge from “our servers are verified” to “you can check this email.”

Iceland has the digital identity infrastructure. The PKI capability. The population size that makes deployment manageable. And the practical motivation that comes from watching your accidental linguistic defense disappear.

Whether it’s the full fingerprint registry, the MTA-level improvements, the pragmatic alternatives, or something nobody has thought of yet — the technology exists. What’s missing is someone deciding to go first.

Iceland seems like the obvious candidate.

The MTA-level authentication path was contributed by Nicolas Williams, whose insights on hop-by-hop SMTP security and relevant RFCs meaningfully shaped this analysis.

The author attended the NATO TIDE Hackathon in Reykjavik and has spent thirty years building internet-based software, including more time than is healthy thinking about why institutions consistently build security for machines instead of people. He works at NCIA in The Hague. These views are his own.

#Cybersecurity #NATO #Phishing #DigitalTransformation #EmailSecurity

Let’s Start With What’s Actually Happening

Every organisation is building with AI now. Customer service bots. Code assistants. Analytics copilots. Internal knowledge agents. The stack keeps growing.

Every one of those agents starts every session with amnesia.

They reach into whatever knowledge base someone pointed them at — a Confluence space, a vector database, some Notion pages that were last updated with genuine enthusiasm sometime in Q2 — and they try to reconstruct an understanding of reality from whatever fragments they find. Or, more commonly, they require the person sitting at the keyboard to repeat the same instructions they gave yesterday. Or to upload the same documents again. Or to spend the first five minutes of every conversation re-establishing context that was perfectly clear twenty-four hours ago, burning tokens on information that hasn’t changed.

No awareness of what’s changed. No sense of what conflicts with what. No concept of confidence or provenance or whether any of it is still true.

When two agents in the same organisation arrive at contradictory conclusions because they pulled from different snapshots of the same information? Nobody even notices. When a policy changes and the customer-facing bot keeps citing the old version for three weeks because nobody re-embedded the docs? The cost is invisible.

Until it isn’t.

This isn’t a retrieval problem. It’s not even a storage problem. It’s an epistemological one. (Stay with me — that word earns its place.)

Organisations don’t need better search across their documents. They need a shared understanding of what is true, continuously validated, accessible to every system — human and machine — from the intern’s laptop to the CEO’s strategic planning agent.

I built something to fix this for myself. An AI memory system called Stompy — persistent context that follows you across sessions and devices, so you stop re-explaining your project every time you open a new chat. It started as a personal frustration with what I was calling “AI dementia”: the maddening tendency for AI assistants to forget everything the moment you close the tab.

Then other people wanted to use it. Which was flattering, and also meant I had to think about what happens when it’s not just me and my projects, but teams, and then organisations, and then organisations that need to share knowledge with other organisations.

And somewhere in that progression — from personal tool to shared infrastructure — I realised that what I was actually building wasn’t a memory system. It was the plumbing for something much broader. A way for organisations to maintain a shared, assessed, continuously validated understanding of what is true.

I’ve been calling it a truth mesh. Let me explain what I mean.

Data Is Not Information. Information Is Not Truth.

This distinction matters, and it’s not the academic kind of distinction that sounds important in a meeting but changes nothing in practice. It changes everything in practice.

Data is raw signal. A temperature reading. A log entry. A Slack message saying “sounds good.” Data has no inherent meaning without context.

Information is data with context. “The server CPU hit 94% at 14:32 UTC during the flash sale.” That tells you something. But it doesn’t tell you what to believe.

Truth is where it gets interesting. Truth is information that has been evaluated, corroborated, challenged, and assessed for confidence. “Our infrastructure cannot reliably handle more than 50,000 concurrent users” — supported by three load test results, one production incident report, and one contradicting analysis from the vendor claiming it should handle 75,000.

Now here’s the bit that took me a while to fully internalise: that contradiction from the vendor doesn’t weaken the truth. It strengthens it. The vendor’s test conditions were examined, found to be non-representative, and the truth stands — stronger for having been challenged. It’s been stress-tested.

Every knowledge management system I’ve come across operates at the information layer. They store documents. They index content. They retrieve relevant passages. But they have no concept of whether those passages are still accurate, whether they conflict with other stored knowledge, or how confident anyone should be in them.

A truth mesh operates one level up. It doesn’t just store what was said. It maintains a continuous assessment of what should be believed.

That’s the difference. And once you see it, you can’t unsee it.

Why the Current Approaches Keep Breaking

Let me walk through what most organisations actually have in place. Not to be dismissive — these tools solve real problems. They just don’t solve this problem.

Platform Memory: Walled Gardens of Forgetting

ChatGPT has memory. Claude has memory. Gemini has memory. Each platform remembers what you told it — inside its own walls. Your ChatGPT knows about your project, but your Claude doesn’t. Your Gemini knows your preferences, but your team’s shared assistant has never heard of any of it.

These platform memories are personal, siloed, and proprietary. Useful for individual productivity. Useless for organisational knowledge. (And if you’ve ever tried to find something you told ChatGPT three months ago… well. You know.)

Knowledge Bases: Write Once, Decay Forever

Confluence pages are born optimistic and die neglected. I think the half-life of accuracy for a technical document in most organisations is measured in weeks, though nobody’s brave enough to actually audit that.

But the document sits there. Confidently indexed. Cheerfully serving stale information to every system that queries it. With absolutely no signal that its content has drifted from reality.

The fundamental issue: knowledge bases are passive. They store what humans write and wait for humans to update them. In an organisation running dozens of AI agents that are generating, consuming, and acting on knowledge continuously, passive storage isn’t just insufficient. It’s a liability.

RAG: Retrieval Without Judgement

Retrieval-Augmented Generation has become the default architecture for giving AI agents access to organisational knowledge. Embed your documents, store them in a vector database, retrieve relevant chunks when the agent needs context.

RAG solves the retrieval problem. It does not solve the truth problem.

A RAG system will happily retrieve a contradictory pair of documents and present both to the model without any awareness that they disagree. It has no concept of which source is more reliable, which information is more recent, or whether the retrieved content has been superseded by something it didn’t retrieve.

RAG gives AI agents access to information. It doesn’t give them judgement about that information. There’s a gap there, and it’s the gap where bad decisions live.

So What Is a Truth Mesh?

A truth mesh is a federated network of nodes, each maintaining a local set of assessed truths, connected to other nodes through evaluation boundaries where knowledge is filtered, validated, and synchronised.

The core primitive is not a document. Not a chunk. Not an embedding. It’s a truth: a composite assessment built from multiple signals, rated for confidence, scoped for relevance, and continuously validated against time.

Let me unpack that, because every word in that sentence is doing work.

Truths Are Composite Signals

A single data point is an assertion. Multiple corroborating data points are a pattern. A pattern that has survived contradiction is a truth.

Think about how a military intelligence analyst works. (I promise this is relevant — it’s where the architecture comes from.) They don’t read one report and form a conclusion. They collect signals from multiple sources — human intelligence, signals intelligence, satellite imagery, open source reporting. Each source carries a reliability rating and each piece of information carries a credibility assessment. The analyst fuses these signals into an assessment, where the confidence depends not just on agreement but on the diversity and independence of the supporting sources.

NATO formalised this decades ago in something called the Admiralty Code: a two-dimensional rating system where every piece of intelligence is scored on source reliability (A through F) and information credibility (1 through 6). An assessment built from multiple highly-rated sources that has also withstood contradiction from a lower-rated source is treated as stronger than one with unanimous agreement from untested sources.

Because it’s been tested. Untested agreement might just be an echo chamber.

A truth mesh applies this exact pattern to organisational knowledge. Every signal feeding into a truth carries a source reliability rating and a credibility score. The truth’s composite confidence is computed from the weighted fusion of all its signals.

And here’s the principle that took the longest to land for me: a truth that has never been contradicted is an untested hypothesis. A truth that has survived contradiction is battle-hardened.

That inverts how most people think about contradictions. They’re not problems to eliminate — they’re evidence to evaluate. A contradiction that’s been examined and resolved makes the truth it challenged more trustworthy. A contradiction that remains unresolved flags the truth as contested and routes it to whoever has the authority to decide.

Which brings us to the part that changes everything about how organisations think about knowledge.

Confidence Decays With Time

Static confidence is a comfortable fiction. The world changes. What was true yesterday may not be true today. A truth mesh formalises what every experienced professional already knows in their gut: unvalidated knowledge becomes progressively less trustworthy.

Every truth in the mesh carries a decay profile — a function that reduces effective confidence over time unless the truth receives fresh confirmation.

Think of it in terms of half-lives:

Volatile truths — market data, competitor intelligence, system status — decay in hours. Without fresh signals, they quickly become unreliable. You wouldn’t trust a stock price from yesterday. Why trust a system status from last week?

Standard truths — team decisions, process documentation, technical architecture — decay over weeks to months. Stable enough to act on, but they need periodic revalidation. That decision the team made in sprint planning three months ago? Probably still valid. Probably.

Durable truths — company policies, contractual obligations, architectural principles — decay over months to years. They change rarely, but they do change. And when they change, everything downstream needs to know.

Permanent truths — historical facts, legal identity, mathematical constants — don’t decay. They’re superseded only by explicit correction.

At any given moment, the effective confidence of a truth is a function of its signal strength and how long it’s been since someone (or something) confirmed it’s still accurate:

effective_confidence = signal_confidence × decay_factor(time_since_last_confirmation)

When a truth’s effective confidence drops below a threshold, the mesh doesn’t silently let it rot. (This is the crucial difference from a Confluence page.) It triggers revalidation — either automated or human-escalated. A ticket gets created. Someone with the right authority is asked: is this still true?

The system actively maintains its understanding of reality. That’s fundamentally different from passively storing snapshots and hoping someone updates them.

The Problem With Silence

Here’s a subtle design decision that turns out to be load-bearing.

When a node in the mesh evaluates incoming data and determines it matches what it already knows — the data is redundant — there are two obvious options: transmit nothing (it’s redundant, why bother?) or transmit a lightweight confirmation that says “yep, same as before.”

The instinct is to transmit nothing. Save bandwidth. Save processing. It’s the same data.

But silence is dangerous. In any system where the absence of a signal carries meaning, silence is ambiguous. Did the node have nothing to report? Or did it fail? Is the remote agent functioning normally with unchanged data? Or has it crashed? Or worse — is it operating on stale data and doesn’t know it?

The truth mesh uses status confirmations: minimal messages that say “I am operational and my understanding is unchanged as of this timestamp.” This might sound like overhead, but it separates two concerns that naive systems conflate:

1. Content validity: Is this information still accurate?
2. Source liveness: Is this source still operational?

A status confirmation answers both at once. And the absence of a confirmation is unambiguously abnormal — something has gone wrong.

This matters more than you’d think for organisations running AI agents. An agent that stops querying the truth mesh might be operating normally on cached context. Or it might be stuck in a loop, crashed, or making decisions on data from three weeks ago. Status confirmations eliminate the ambiguity.

(If this reminds you of heartbeat protocols in distributed systems — good. Same principle, applied to knowledge rather than uptime.)

The “Mesh” Part: Federation

A single node maintaining assessed truths is useful. Genuinely useful — it’s already better than a knowledge base because it tracks confidence and decay.

But the magic is in the mesh. A network of interconnected nodes sharing truths across organisational boundaries.

How It Works

Federation is deliberately simple. A node publishes an API endpoint. Another node connects with an API key and a permission set: what can it read, what can it write, what can it propose. The connection includes a sync mode and a confirmation interval — how often nodes reassure each other that they’re still alive with unchanged truth sets.

At each federation boundary, every piece of knowledge crossing the line is delta-evaluated — compared against what the receiving node already knows:

• NEW: This truth doesn’t exist in my mesh. Ingest it with full provenance.
• UPDATE: I have a version of this, but yours has changed. Ingest the delta.
• REDUNDANT: I already know this. Send a confirmation. Don’t waste bandwidth or processing on it.
• CONFLICT: This contradicts something I hold as true. Flag it. Create a ticket. Route it to whoever has authority to decide.

This evaluation happens at every boundary. Redundancy is caught at the earliest point where visibility permits. Conflicts surface automatically. Novel information propagates with full provenance.

The result is that knowledge flowing through the mesh is continuously filtered and assessed. Not by humans manually reviewing every piece of information — that doesn’t scale. By a system that understands what it already knows and can tell the difference between “this is new,” “this is the same,” and “this disagrees with what I believe.”

The Scoping That Makes It Work

Truths in the mesh are scoped, and the scoping maps naturally to how organisations already operate:

Project scope: The API uses OAuth 2.1. The deployment target is us-east-1. Sprint velocity is 23 points. These truths matter to the team and nobody else.

Organisation scope: The company holiday policy. The approved technology stack. The brand guidelines. These truths apply to everyone.

Federation scope: Cross-organisational truths shared between partners, subsidiaries, or coalition members. Contractual obligations. Shared standards. Interoperability requirements.

Each scope boundary is a delta evaluation point. And this is where it gets genuinely powerful.

When a team-level truth gets promoted to organisation scope, it’s evaluated against every other team’s truths at that level. Conflicts that were invisible within a single team — because the teams operated independently and never compared notes — surface instantly when their truths merge.

I’ll give you the examples that made this click for me — and they’re embarrassingly close to home, because I found them while building the system that’s supposed to prevent exactly this.

When I ran a production readiness evaluation on Stompy’s own codebase, the audit flagged that CLAUDE.md (the AI agent’s instruction file) declared the system was at version 5.7.0. The README — the file every human reads first — said version 5.0.0. Same repository. Same project. Two files confidently asserting different version numbers, and nobody had noticed because nobody was comparing them semantically.

Worse: my architecture documentation described a per-user database isolation model where every authenticated user gets their own schema. Careful design. Well-documented. The actual authentication middleware, meanwhile, contained a function that returned a hardcoded string — "default_user" — for every single authenticated request. Every user in the system was silently sharing one account. The architecture truth and the code truth were in direct conflict, and the system had no mechanism to surface it. A beta tester found it when they logged in and saw someone else's projects.

Then there’s the pricing. My brand documentation — locked months ago — confidently states the consumer tier is $4.99/month. After the Neon partnership changed the economics, the pricing model was updated to $6.99/month for Pro. But the original brand context was never amended. Two different AI agents working from different contexts in the same project would give you two different prices for the same product.

None of these are hypothetical. They’re real contradictions that existed in a project that literally has conflict detection as a feature. In a truth mesh, every one of them would have surfaced automatically the moment the conflicting contexts were evaluated against each other at scope boundaries — and each would have generated a ticket. Not a notification that disappears into a Slack channel. A ticket with the conflicting truths side by side, the provenance of each, and a routing to whoever has authority to resolve it. The version mismatch goes to the maintainer. The security issue goes to the architect. The pricing discrepancy goes to whoever owns the commercial model. Each resolution propagates back through the mesh as an authoritative truth, updating every node that held the stale or conflicting version.

How many of those contradictions are sitting in your organisation right now? I’d wager more than you’re comfortable with. And I’d wager there’s no mechanism to surface them other than someone happening to notice.

The Lowest Common Denominator

Here’s the thesis, stated plainly:

A truth mesh allows organisations to collect and consume knowledge from the lowest common denominator — whoever or whatever generates or needs data — and propagate assessed truth upward through the entire organisation.

And the most important lowest common denominator is people.

Not people writing carefully considered documentation. Not people updating knowledge bases as a scheduled task. People in the moment. The engineer who notices during a deployment that the staging config doesn’t match what the docs say. The support agent who hears the same customer complaint for the third time this week. The product manager who realises in a meeting that two teams are building toward contradictory assumptions.

These observations are post-it note knowledge. They happen in real time, they’re enormously valuable, and they’re almost always lost. The person thinks “I should tell someone about this” and then the next meeting starts, or the next ticket comes in, or they just forget. The observation existed for thirty seconds in someone’s working memory and then it was gone. Nobody updated a wiki. Nobody filed a Jira ticket. Nobody sent the email.

A truth mesh makes these moments persistent and permanent — but not stagnant. That’s the crucial distinction. The observation enters the mesh as a signal. It’s captured in the moment it happens, in whatever way is most natural — spoken to an AI assistant, typed into a chat, noted during a session. It becomes durable. But because the mesh applies confidence decay, it doesn’t calcify into another Confluence page that everyone treats as gospel long after reality has moved on. It stays alive: validated, re-evaluated, decaying when it hasn’t been confirmed, strengthening when corroborated.

And when three other people in different parts of the organisation make the same observation independently, those signals corroborate. The truth “our pricing communication is confusing customers” crosses the confidence threshold and propagates to whoever needs to act on it. Not because anyone planned a formal feedback process. Because the infrastructure caught the pattern that no individual could see.

That’s the human side. The machine side works the same way, just faster.

A temperature sensor on a factory floor generates data. An edge node evaluates whether it’s new or redundant, tracks confidence based on sensor reliability, and — if it’s genuinely novel — propagates it upward with full provenance.

An AI coding assistant discovers a configuration mismatch during deployment. That’s a conflict signal. It enters the mesh, gets evaluated, and if it contradicts an existing truth, a ticket is created automatically — routed to whoever owns that truth, with full context on what conflicts and why.

And this is where ticketing becomes the circulatory system of the mesh, not a bolt-on feature.

When a truth’s confidence decays past a threshold, a ticket is created: “This hasn’t been validated in 90 days. Is it still true?” When a conflict is detected between two nodes, a ticket is created: “These two teams believe contradictory things. Who decides?” When an AI agent encounters ambiguity it can’t resolve, a ticket is created: “I found something that needs a human judgement call.”

These tickets are the natural workflow for both humans and AI agents. A human creates a ticket by observing something. An AI agent creates a ticket by detecting a conflict. A different AI agent picks up that ticket, does preliminary analysis, and either resolves it (if it has the authority and confidence) or escalates it with a recommendation. A human reviews the escalation, makes a decision, and that decision propagates back through the mesh as a resolved truth.

Tickets flow upward through decision chains. Resolutions flow back down. The same ticketing system serves the person who noticed something odd in a customer call and the autonomous agent that detected a version mismatch in a codebase. Neither needed to know about the other. The mesh connected them.

None of these sources — the sensor, the coding assistant, the product manager who had a thought between meetings — needed to understand the organisation’s knowledge architecture. They generated data or surfaced observations at the lowest possible level, in the moment it happened, in whatever way was most natural. The truth mesh evaluated, assessed, corroborated, and propagated. Knowledge flows upward through the organisation because the infrastructure makes it flow, not because someone remembered to share it.

The Collation Engine: AI as Librarian

A truth mesh without maintenance would eventually suffer the same rot as any knowledge base. Slower, because confidence decay makes staleness visible. But still, entropy wins eventually if nobody’s minding the shop.

That’s the job of the collation engine: an AI-driven process that continuously maintains the mesh. And its primary output, when something needs attention, is a ticket.

It operates in two modes, and the balance between them is the key design decision.

Autonomous maintenance runs on schedule — after sessions, daily, or triggered by activity thresholds. It handles the routine:

Signal detection. Confidence recalculation as new signals arrive or existing ones age. Staleness detection for truths past their decay threshold. Deduplication of contexts that say the same thing in different words. When it finds something that needs doing — a truth that’s gone stale, a conflict that’s appeared, a set of signals that look like they belong together — it creates a ticket. Not an alert. Not a notification that disappears. A ticket with context, provenance, and a suggested action.

This is work no human should be doing manually. It’s high-volume, low-judgement, and perfectly suited to AI.

Escalated review happens when the engine encounters something that requires human authority:

Proposing that a set of signals constitutes a new truth. Flagging conflicts where contradicting signals have shifted confidence below a threshold. Recommending that a team-level truth be promoted to organisation scope, with an analysis of potential conflicts at that level. Each of these creates a ticket routed to the right person — not “the team” or “the channel,” but whoever has been designated as the resolution authority for that truth’s scope.

An AI agent can pick up routine tickets — revalidating a stale truth by searching for fresh signals, merging near-duplicate contexts, updating confidence scores. A human picks up the ones that need judgement — resolving genuine conflicts, approving scope promotions, deciding what the organisation believes when the evidence is ambiguous.

The balance is configurable per scope. At the project level, the engine operates aggressively — merge, deduplicate, reorganise, and close its own tickets freely. At the organisation level, it proposes and waits for approval. At the federation level, it identifies opportunities and flags everything for explicit human decision.

AI handles the volume. Humans handle the judgement. The ticketing system is the shared language they use to coordinate — the same workflow, the same primitives, whether the actor is a person or an agent. That’s how you maintain thousands of truths across hundreds of nodes without either drowning in manual work or letting a model silently decide what your organisation believes to be true.

What This Actually Enables

I want to be concrete about this, because “enables better knowledge management” is the kind of statement that makes everyone nod and nobody act.

For AI agents: Every agent in the organisation queries the same truth mesh instead of its own siloed knowledge base. When truths update, every agent’s next query reflects the change. When conflicts are detected, every affected agent is aware. When work needs doing, agents pick up tickets from the same queue humans use — revalidating stale truths, running preliminary analysis on conflicts, flagging anomalies. The era of AI agents operating on different versions of reality within the same organisation ends. (That era should never have started, frankly, but here we are.)

For people in the moment: The product manager who notices a problem between meetings doesn’t need to decide whether it’s worth a Jira ticket or a Slack message or an email. They mention it. It becomes a signal. If it matters, the mesh will surface it. If five other people noticed the same thing, the mesh will corroborate it. The barrier between “having a thought” and “contributing to organisational knowledge” drops to nearly zero.

For decision-making: Contradictions that hide in silos — one team’s understanding conflicting with another’s — surface automatically at scope boundaries. Each conflict becomes a ticket, routed to whoever has authority to decide, with full context on what’s conflicting and why. Decisions come with provenance: what signals informed them, what alternatives were considered, what contradictions were resolved. And those decisions propagate back through the mesh — not as a memo someone might read, but as an update to the truths every system operates on.

For onboarding: A new team member connects to the organisational truth mesh and inherits the accumulated, validated knowledge of the entire organisation. Rated for confidence. Scoped for relevance. Decaying appropriately when stale. The months-long process of absorbing tribal knowledge through osmosis becomes a structured, immediate transfer. (Still no substitute for coffee with colleagues. But a much better starting point.)

For multi-organisation collaboration: Partners, suppliers, and coalition members federate their truth meshes at defined boundaries with explicit permissions. Shared truths propagate automatically. Conflicts surface instantly. The overhead of maintaining alignment across organisational boundaries drops from constant manual synchronisation to managed exceptions.

For compliance and audit: Every truth has provenance. Every signal has a source rating. Every conflict resolution has a timestamp, a decision-maker, and a rationale. The truth mesh is an auditable record of what the organisation believed, when it believed it, why it believed it, and who decided when beliefs conflicted. Auditors tend to appreciate that sort of thing.

Is This Theoretical?

No. The building blocks exist and have been validated in the most demanding environment I can think of: military tactical networks.

In that domain, sensor data generation exceeds transmission capacity by three orders of magnitude. Redundant transmissions consume bandwidth that could carry life-saving intelligence. And the distinction between “nothing new to report” and “unit destroyed” is literally the difference between life and death. Every concept in this paper — delta evaluation, status confirmations, confidence decay, cascading classification, conflict detection at federation boundaries — was designed for that context first.

The embedding models that enable semantic comparison run on edge hardware consuming as little as 2 watts. Vector databases provide sub-millisecond similarity search. Existing protocols handle the communication layer. And existing organisational structures — team, department, division, company — provide the scoping hierarchy that was already there, waiting for someone to run knowledge through it.

The architecture doesn’t replace existing infrastructure. It’s a layer that sits between data generation and data consumption, continuously evaluating what’s new, what’s changed, what’s redundant, and what conflicts. Whatever system consumes the data downstream — human or machine — receives assessed truth rather than raw information.

If delta evaluation works in a contested tactical environment over a 9.6 kbps radio link, it works in your organisation over broadband. I can say that with some confidence.

What Comes Next

The truth mesh is a framework. Implementing it requires decisions that are organisational, not technical.

Who can assert truths at what scope? What categories of truth exist in your domain, and what are their decay profiles? Which conflicts get resolved automatically and which require human judgement? Who shares what with whom across federation boundaries?

These questions sound straightforward. In practice, answering them forces organisations to confront something uncomfortable: they don’t actually know what they collectively believe to be true. Different teams hold different versions of reality. Contradictions have been quietly tolerated because nobody had a mechanism to surface them.

Most organisations aren’t ready for that conversation yet. But the ones who are will find that their AI agents become dramatically more effective, their decisions become traceable, and their institutional knowledge becomes resilient rather than fragile.

The organisations that treat knowledge as assessed truth — rather than accumulated data — will operate with a fundamentally different kind of intelligence.

And the AI systems that serve those organisations will finally have something worth remembering.

Markus Sandelin builds Stompy, a federated AI memory platform. The delta evaluation architecture described here was originally developed for NATO tactical networks and (hopefully) presented at ICMCIS 2026 (Bath, UK). He works at NATO Communications and Information Agency and has spent the last eight months trying to cure AI amnesia. The elephant mascot was his idea. He’s not sorry about it.

In March 2024, a Microsoft engineer named Andres Freund noticed something small. SSH connections — the secure remote access protocol that underpins nearly every server on the internet — were taking half a second longer than expected. He wasn’t investigating a security issue. He was benchmarking an unrelated database process and the latency annoyed him.

What he found was a backdoor in XZ Utils, a compression library embedded in virtually every Linux system on earth. An attacker using the pseudonym “Jia Tan” had spent two and a half years building trust through legitimate contributions to the open-source project before inserting code that would have granted unauthenticated remote access to hundreds of millions of systems. The vulnerability received the maximum possible severity score. The entire defense — against a campaign that took thirty months to execute — was one person’s curiosity about 500 milliseconds.

That was one human attacker, one library, caught by one engineer who happened to be looking at the right metric on the right day.

Now consider what happens when the tool writing the code is the vulnerability.

The Scale Nobody’s Calculated

Something foundational has changed in how software gets written, and the implications have outpaced the institutions responsible for managing the risk.

AI coding assistants — tools that suggest, generate, and increasingly write entire functions and files of software code — now produce between 41 and 46 percent of all new code written globally. GitHub Copilot, the most widely adopted of these tools, has surpassed 20 million users across 77,000 enterprise customers, including 90 percent of Fortune 100 companies. Cursor, another popular tool, generates approximately one billion lines of code per day. Anthropic’s Claude Code processes 195 million lines weekly. These are not experimental tools used by early adopters. They are the primary mechanism through which production software is now created.

The security conversation around these tools has focused almost entirely on quality: does AI-generated code contain more bugs? Are the suggestions accurate? This is the wrong question. The right question is a supply chain question, and it has no historical precedent.

A software supply chain attack occurs when a trusted component — a library, an update mechanism, a build tool — is compromised, and the compromise propagates to everyone who depends on that component. The SolarWinds attack of 2020, widely regarded as one of the most significant cyber operations in history, compromised one network monitoring product and reached 18,000 organisations. The remediation costs averaged $12 million per affected company, and the attack went undetected for fourteen months.

AI coding assistants occupy a position in the software supply chain that is categorically different from anything that has come before. They don’t deliver a component. They participate in the creation of every component. A compromise at this level would not affect one product across many organisations. It would affect the source code itself — across every project, in every organisation, touched by every developer using the compromised tool.

Five Ways In

The uncomfortable reality is that every technical prerequisite for compromising an AI coding assistant has already been independently demonstrated. These are not theoretical risks described in academic papers that begin with “future work may explore.” These are peer-reviewed, publicly documented attack methods that have been tested against production systems.

The training data. AI coding models learn by ingesting vast quantities of existing code. Researchers at USENIX Security 2024 — one of the field’s top academic venues — demonstrated that poisoning just 0.2 percent of a model’s training data was sufficient to embed backdoors that evaded all standard detection tools, including analysis by more advanced AI models. A separate study at UC Santa Barbara showed that malicious patterns could be hidden in documentation comments rather than executable code, making them invisible to any tool that scans for suspicious code patterns. The poisoning rates required are vanishingly small: 160 compromised files out of 80,000.

The dormant behaviour. Anthropic, the company behind Claude, published research in January 2024 demonstrating that a model could be trained to write secure, correct code under normal conditions while injecting exploitable vulnerabilities when triggered by a specific contextual signal — in their experiment, the calendar year changing. The backdoor behaviour survived every standard safety technique, including the reinforcement learning process specifically designed to remove unwanted behaviours. The researchers described the result as creating a “false impression of safety.” Larger, more capable models proved harder to fix, not easier.

The hidden instructions. Prompt injection is the technique of embedding instructions within content that an AI reads but a human doesn’t see. Trail of Bits, a respected security research firm, demonstrated in August 2025 that an attacker could file a routine-looking bug report on GitHub containing invisible instructions in the page’s HTML structure. When a coding assistant read the page to understand the issue, it followed the hidden instructions instead — in their demonstration, installing a backdoor. The instructions were invisible in GitHub’s interface. Only the AI could read them.

The configuration files. AI coding tools use project configuration files to understand coding standards and preferences. In March 2025, researchers demonstrated that invisible Unicode characters — characters that exist in the file but don’t render on screen — could be embedded in these configuration files to permanently alter all code the AI generates for every team member. Because these configuration files are shared when projects are copied or forked, the compromise self-propagates across organisations without any further attacker action.

The tooling itself. In July 2025, an attacker exploited a security flaw in the build process for Amazon Q Developer, Amazon’s AI coding assistant, and injected a malicious instruction directly into the official product distributed through Visual Studio Code’s extension marketplace. The instruction directed the AI to wipe users’ systems and delete cloud resources. The compromised extension had over 964,000 installations and passed Amazon’s verification process. It was publicly distributed for two days. The only reason it caused no damage was a syntax error in the attacker’s payload — a typo that prevented the instruction from executing.

This is no longer a collection of research findings. The Amazon Q incident is the XZ Utils of AI tooling, except the community has largely moved on because a typo happened to prevent catastrophe.

The Invisible Flaw

What makes these attacks categorically different from traditional malware is the nature of what gets injected. A compromised AI coding assistant would not insert obviously malicious code that a competent developer would recognise. It would generate code that looks entirely normal, follows established patterns, passes all automated tests, and exploits the precise class of vulnerabilities that both humans and tools systematically miss.

The USENIX Security researchers demonstrated this concretely. They showed that advanced AI could transform thirty common vulnerability types — drawn from the MITRE Common Weakness Enumeration, the standard catalogue of software security flaws — into forms that triggered zero detections from industry-standard scanning tools. When these transformed vulnerabilities were presented to other AI models for review, twenty-five of thirty were assessed as containing no security issues.

The transformations are subtle enough to be indistinguishable from reasonable code. Replacing one template rendering method with another introduces a cross-site scripting vulnerability — a flaw that allows attackers to inject malicious content into web pages — while appearing to be a minor stylistic choice. Using string concatenation instead of parameterised queries introduces SQL injection — a flaw that allows attackers to manipulate databases — while appearing to simplify the code. To a reviewer scanning a pull request at four in the afternoon, the insecure version often looks cleaner than the secure one.

An entirely separate attack class requires no compromise of the AI at all. Researchers tested sixteen different AI models across 576,000 code generation requests and found that nearly one in five package references — the external libraries that code depends on — pointed to libraries that do not exist. The AI hallucinates them. Critically, 43 percent of these hallucinated library names appeared consistently when the same request was repeated, making them predictable. An attacker simply registers the nonexistent library name in a public package repository, fills it with malicious code, and waits. Every developer who follows the AI’s recommendation installs the backdoor voluntarily, believing they are adding a legitimate dependency. Security researchers have named this technique “slopsquatting.”

The broader baseline is sobering. Independent analyses have found security flaws in 45 percent of AI-generated code across more than one hundred models tested, and GitHub’s own research acknowledged that 29 percent of AI-generated Python code contains potential security weaknesses. These are not edge cases. They are the standard output of the tools writing nearly half of all new software.

The Review That Never Happens

The organisational failure that completes this picture is not that companies don’t value code review. It’s that the structural dynamics of AI-assisted development make thorough review practically impossible, while creating the confident belief that it’s happening.

The most revealing data point comes from production telemetry, not surveys. When AI code review tools are enabled in development workflows, 80 percent of pull requests — the formal submissions of new code for review before it enters the product — receive no human comment or review whatsoever. This is observed behaviour from real systems. By contrast, 71 percent of developers report in surveys that they never merge AI-generated code without manual review. The gap between those two numbers contains the entire risk.

This is not because developers are negligent. It reflects a well-documented cognitive pattern called automation bias: the tendency to defer to automated outputs, particularly under time pressure and cognitive load — precisely the conditions of modern software development. A systematic review of 74 studies documented this effect across domains from aviation to medicine. The UK Post Office scandal, in which hundreds of postal workers were criminally prosecuted because staff trusted an automated accounting system over the workers’ protests of innocence, remains one of the starkest examples of what happens when organisations institutionalise deference to automated judgment.

Human code review was never particularly effective at catching security vulnerabilities, even before AI entered the picture. In a controlled study, 30 professional developers were hired to review a web application containing seven known vulnerabilities. No developer found all seven. One in five found zero. The average detection rate was 2.33 out of seven — roughly 33 percent. Most revealing: there was no correlation between years of security experience and detection accuracy. More experienced reviewers actually produced more false positives. A simulation based on the study’s data calculated that ten independent reviewers would be needed for an 80 percent chance of catching all vulnerabilities — a resource commitment virtually no organisation makes for any code, let alone the volume now generated by AI.

A separate study found that simply instructing code reviewers to focus on security — as opposed to their default review mode — improved vulnerability detection by a factor of eight. Without explicit security instructions, developers routinely missed common, well-documented vulnerabilities. The default cognitive mode of a code reviewer is functionally blind to security issues.

The trust gradient compounds over time. Telemetry from nearly a million users shows that developers accept progressively more AI suggestions the longer they use the tool — from 29 percent in the first three months to 34 percent by month six. Less experienced developers accept more suggestions and spend roughly half as long reviewing them. A Stanford study found that developers using AI assistants wrote measurably less secure code while reporting significantly higher confidence in its security. The inverse relationship is precise: the developers with the least secure code rated their trust in AI at 4.0 out of 5.0. Those with the most secure code rated it 1.5.

The people most likely to catch problems are those least inclined to rely on AI. The most enthusiastic adopters are the least equipped to vet its output. The system selects for the worst possible combination.

The Monoculture

Every previous supply chain attack exploited trust in something external. SolarWinds exploited trust in a vendor’s software update. XZ Utils exploited trust in an open-source contributor. The Log4j vulnerability in 2021, which affected 88 percent of organisations through a single logging library and which the US government estimated would take at least a decade to fully remediate, exploited trust in a transitive dependency — a library used by a library used by your software.

A compromised AI coding assistant would exploit something different: trust in the developer’s own work. The code appears in the developer’s pull request, passes the developer’s tests, carries the developer’s name on the commit. The trust boundary — the line between “code I wrote” and “code from outside” — has moved inside the developer’s own workflow. When the tool that helps you think becomes the vector, the traditional model of reviewing external inputs no longer applies, because the developer does not experience the code as external.

This is amplified by a structural condition that the US National Institute of Standards and Technology (NIST) formally identifies as an “algorithmic monoculture.” Three providers dominate AI code generation: GitHub Copilot at roughly 42 percent market share, Cursor at 18 percent, and Anthropic’s Claude growing rapidly. These tools draw on a small number of underlying AI models with substantially overlapping training data. Identical patterns of strength produce identical patterns of weakness. A vulnerability that exists in one model’s outputs is likely to exist in another’s, because they learned from much of the same code.

The agricultural parallel is not metaphorical. It is structural. When an entire ecosystem depends on a single genetic line, a single pathogen can cause total failure. The Irish Potato Famine killed a million people and displaced a million more because the entire crop was genetically identical and a single blight could therefore destroy it all. Software monocultures carry the same risk at a different scale. One successful poisoning technique, deployed against the training pipeline of a major AI code generation provider, would propagate identical vulnerabilities into the codebases of every organisation using that tool — regardless of those organisations’ individual security practices, review processes, or compliance certifications.

A September 2025 analysis of a Fortune 50 enterprise found that teams using AI coding assistants shipped ten times more security risks alongside four times the development velocity. The organisation was generating 10,000 new security findings per month — a ten-fold increase in six months. The velocity is real. The risk is also real. They are the same phenomenon.

What the Frameworks Miss

The institutional response to AI code generation risk is not absent. It is, in many cases, thoughtful and technically informed. But it addresses a threat model that is one generation behind the deployment reality.

NIST published guidance in 2024 recommending that organisations review “all source code during AI development and training, whether human-written or AI-generated.” Their AI Risk Management Framework identifies algorithmic monocultures as a systemic risk and catalogues twelve risks unique to generative AI. The US Cybersecurity and Infrastructure Security Agency (CISA), in joint guidance with the NSA, FBI, and five allied nations, warns that “one cannot simply assume that web-scale datasets are clean, accurate, and free of malicious content.” The Open Worldwide Application Security Project (OWASP) ranks prompt injection as the number one threat to AI applications. MITRE, which maintains the standard taxonomy of cyber attack techniques, added fourteen new techniques specific to AI agents in October 2025.

All of this is useful. None of it addresses the specific scenario of a mass-compromise event where a widely-used AI coding assistant simultaneously introduces vulnerabilities across millions of codebases.

The structural tension is visible in the gap between two positions. GitHub’s official response to the Rules File Backdoor vulnerability — the invisible configuration file attack that self-propagates across projects — was that “users are responsible for reviewing and accepting suggestions.” Georgetown University’s Centre for Security and Emerging Technology, analysing the same class of risk, concluded that this burden “should not rest solely on individual users.”

These two positions cannot both be correct. The first places the defence at the point of least capability — individual developers reviewing AI output they experience as their own. The second acknowledges that systemic risks require systemic responses. The gap between them is where the risk accumulates.

The European Union’s AI Act, the most comprehensive regulatory framework yet enacted, regulates foundation models but does not directly address the security characteristics of their code generation outputs. No existing framework requires organisations to track which AI model, which model version, or which configuration generated specific portions of their production code. The provenance of AI-generated code — where it came from, what influenced it, whether the model that wrote it has since been found to contain vulnerabilities — is, for all practical purposes, untraceable in most organisations.

What Actually Helps

There are no simple solutions to a problem this structural, and presenting any as such would be dishonest. But there are interventions that materially change the risk profile, and most of them are available now.

Treat AI-generated code as third-party code. This is the single most consequential framing shift available. Organisations already have processes for evaluating external dependencies — vendor assessments, security reviews, licence compliance. AI-generated code is, functionally, an external dependency. The fact that it arrives inside a developer’s editor rather than as a downloaded package does not change what it is. Applying existing third-party review standards to AI-generated code requires no new tooling. It requires a decision.

Break the monoculture. Using one AI model to generate code and a different model to review it introduces genuine diversity into the process. If both models share the same training data — or worse, if both are the same model — the review cannot catch systematic blind spots because the reviewer shares them. This is the fox-and-henhouse problem, and the only mitigation is ensuring the fox and the guard dog are genuinely different animals.

Instruct reviewers explicitly. The finding that explicit security instructions improve vulnerability detection by a factor of eight is the cheapest intervention in this entire landscape. It costs nothing. It requires no procurement, no tooling change, no organisational restructuring. A checklist item that says “review this code specifically for security vulnerabilities” measurably changes review behaviour. The fact that most organisations have not implemented this suggests the problem is not resource constraints but awareness.

Monitor behaviour in production, not just code in review. The evidence strongly suggests that pre-deployment review will not reliably catch sophisticated AI-generated vulnerabilities. Runtime monitoring — observing how code actually behaves in production, detecting anomalous patterns, flagging unexpected network connections or data access — provides a detection layer that does not depend on a human reviewer’s ability to spot a subtle flaw in a pull request at the end of a long day.

Demand provenance. Organisations should know which model, which version, and which configuration generated every piece of AI-assisted code in their production systems. When a model is found to have been compromised or to contain systematic vulnerabilities — and this will happen — the ability to identify which code was generated by that model is the difference between a targeted remediation effort and an impossibly broad audit of the entire codebase.

None of these are solutions. They are mitigations. The honest assessment is that no current approach fully addresses the risk of a coordinated compromise at the scale these tools now operate. But the gap between doing nothing and implementing these measures is the gap between a system that is structurally indefensible and one that has a reasonable chance of detecting and responding to compromise when — not if — it occurs.

The Margin

Andres Freund noticed 500 milliseconds. The entire defence against a thirty-month operation, designed by a sophisticated attacker to compromise hundreds of millions of systems, was a performance anomaly observed by an engineer working on something else entirely.

Every prerequisite for a similar event in AI code generation has been independently demonstrated. Training data poisoning works at trivially low infection rates. Prompt injection succeeds against current defences more than 85 percent of the time. A supply chain attack on AI tooling has already occurred and was stopped by a typo. The generated vulnerabilities evade both automated scanning and human review. And the adoption curve — 400 percent year-over-year growth for Copilot alone — is compressing the timeline.

The question is not whether this is possible. The question is whether the margin between compromise and detection will hold. Whether there will be someone paying attention to the right metric on the right day. Whether the equivalent of 500 milliseconds will be visible in a codebase that grows by billions of lines per month.

The monoculture is planted. The crop looks healthy. It would, right up until the point it doesn’t.

History has a consistent opinion about what happens next.

The author has spent thirty years building internet-based software and the last several watching organisations adopt AI coding tools with the same enthusiasm and due diligence they once applied to cloud migration — which is to say, lots of the first and almost none of the second. He’s consulted on digital transformation for NATO, military, EU institutions, and organisations that genuinely believed their review processes would catch everything. He’s tired of watching intelligent people confuse automated output with verified output, and velocity with progress. His rubber chicken has accepted every code suggestion without review and remains unpatched. He builds AI memory systems, runs his own infrastructure, and occasionally writes about what happens when nobody reads what the machine wrote. He’s based in The Hague and can be found thinking about software supply chain provenance at inappropriate hours.

Sometimes the timing just works out.

For the past eight months I’ve been building Stompy as a side project — a memory system for AI agents. The core idea is almost embarrassingly simple: agents shouldn’t forget everything between sessions. They should have persistent, searchable, versioned memory. They should know what’s been tried, what worked, what failed, and what they decided three weeks ago without someone having to explain it all over again.

We’ve been testing it with an autonomous marketing agent on Moltbook, where it remembers past interactions, avoids duplicate work, and actually learns from what didn’t perform. Pretty useful when you’re one agent among fourteen million.

Our missing piece was always orchestration. Getting multiple Claude Code agents to collaborate without stepping on each other required, to put it charitably, duct tape and prayer.

Then yesterday, Anthropic released Claude Opus 4.6 with agent teams — multi-agent collaboration built right into Claude Code. Agents spawn teammates, divide work, coordinate independently. It’s genuinely impressive engineering.

The catch? No persistent memory. No cross-session learning. No semantic task deduplication. No way to search what previous teams discovered.

Which is exactly what Stompy does.

But this article isn’t about Stompy. It’s about a question that I think matters for anyone running multi-agent AI workflows: what does agent amnesia actually cost?

What Agent Teams Are (In 60 Seconds)

If you haven’t seen the announcement, here’s the short version. Claude Code’s agent teams let you spin up multiple AI agents that work in parallel on the same codebase. One session acts as team lead. It spawns teammates — each a full, independent Claude Code instance with its own context window. There’s a shared task list with dependency tracking, an inbox-based messaging system for inter-agent communication, and teammates can self-claim work as they finish tasks.

This is meaningfully different from subagents (the existing approach where you send a worker off to do something and it reports back). Agent teams actually collaborate — they share findings, challenge each other’s approaches, and coordinate independently.

The architecture is clean. The tradeoff is token cost — each teammate is a separate Claude instance consuming its own context window.

And every one of them starts from scratch.

The $20,000 Compiler

The day agent teams shipped, Anthropic published what I think is the single most important piece of AI engineering writing of 2026 so far: Nicholas Carlini’s account of building a C compiler with a team of parallel Claudes.

The numbers first: 16 agents, approximately 2,000 Claude Code sessions over two weeks, 2 billion input tokens, 140 million output tokens. Total cost: just under $20,000. The result: a 100,000-line Rust-based C compiler that can compile the Linux kernel on x86, ARM, and RISC-V. From scratch. Clean-room implementation. No internet access during development.

That’s extraordinary. It’s also extraordinarily instructive about where multi-agent coordination breaks down.

Carlini — a researcher on Anthropic’s own Safeguards team — documented the problems with remarkable candor. His agents wasted enormous time orienting themselves in fresh sessions. Multiple agents would pick the same problem and overwrite each other’s fixes. When the Linux kernel compilation became one giant task, all 16 agents got stuck on the same bug simultaneously. Failed approaches weren’t tracked, so agents repeated dead-end strategies. He had to build custom file-based locks, progress documents, and a known-good oracle just to keep things moving.

Every single one of these problems is a coordination failure caused by the same root issue: agents have no memory between sessions and no shared knowledge base beyond the codebase itself.

Carlini is a world-class researcher. His solutions were clever — git-based synchronization, custom lock files, extensive README maintenance, oracle-based work partitioning. But he spent significant engineering effort building workarounds for a problem that shouldn’t exist.

The Six Taxes of Agent Amnesia

Reading Carlini’s post carefully, and mapping it against our own experience running multi-agent workflows, I count six distinct costs that agent amnesia imposes. I’ve started calling them the “confusion taxes” because they’re invisible, compounding, and almost nobody accounts for them.

Tax 1: The Orientation Tax

Every new agent session starts cold. The agent reads the README, scans the codebase, tries to figure out where things stand. On a complex project, this can consume 5–10% of the session’s token budget before the agent does anything useful.

Carlini noticed this immediately: “Each agent is dropped into a fresh container with no context and will spend significant time orienting itself, especially on large projects.” His workaround was maintaining extensive READMEs and progress files — which, of course, the agents also had to maintain, consuming more tokens.

On a 2,000-session project, even a conservative 5% orientation overhead means 100 billion tokens spent just on agents figuring out where they are.

Tax 2: The Duplication Tax

Without a shared knowledge base, multiple agents routinely pick the same problem. Carlini’s most painful example: when agents moved from isolated compiler test suites (where parallelization was trivial — each agent picks a different failing test) to the Linux kernel (one giant task), all 16 agents converged on the same bug.

“Having 16 agents running didn’t help because each was stuck solving the same task.”

Worse, they didn’t just duplicate effort — they overwrote each other’s fixes. The agents weren’t lazy or broken. They simply had no way to know that another agent was already working on the same problem.

Tax 3: The Amnesia Tax

When Agent A discovers that approach X doesn’t work, Agent B — running in a different session — has no way to know. So Agent B tries approach X. Fails. Maybe tries it slightly differently. Fails again. Meanwhile Agent C is also trying approach X in yet another session.

This is the most insidious tax because it’s invisible. You don’t see the waste in your bill — it looks like productive work. The agents are thinking, coding, running tests. They’re just thinking about things that have already been conclusively ruled out.

Carlini’s mitigation: “I built a continuous integration pipeline and implemented stricter enforcement that allowed Claude to better test its work so that new commits can’t break existing functionality.” But that’s detecting repeated failures at the output level. The wasted computation still happens.

Tax 4: The Context Pollution Tax

Agent teams burn context on noise. Verbose test output, lengthy error logs, diagnostic information that’s useful once but toxic to ongoing reasoning. Carlini was explicit about this: “The test harness should not print thousands of useless bytes. At most, it should print a few lines of output.”

He built custom tooling — fast test modes that run 1% samples, pre-computed summary statistics, structured log formats optimized for LLM consumption. All of this is engineering effort spent on managing information density inside agent context windows. It’s the right approach, but it’s solving a symptom rather than the disease.

Tax 5: The Coordination Tax

File-based task management with git-based synchronization works. It’s also fragile, slow, and creates merge conflicts that agents must resolve — consuming tokens to fix coordination problems rather than solve actual problems.

Agent teams’ built-in task model (pending → in_progress → completed with basic dependencies) is an improvement, but it’s still a flat list with no semantic intelligence. There’s no way to search “what has been tried for this class of problem” or “which approaches have been ruled out.”

Tax 6: The Consistency Tax

When Agent A makes an architectural decision in session 47 and Agent B contradicts it in session 312, nobody knows until something breaks. Carlini’s agents “frequently broke existing functionality each time a new feature was implemented.” Some of this is the inherent difficulty of compiler development. Some of it is agents working from contradictory assumptions because decisions aren’t persisted.

What Confusion Actually Costs: The Math

Let’s put numbers on this. I’ll use Carlini’s C compiler project as the baseline because it has the most detailed public data, and then extrapolate to more typical multi-agent workflows.

The C Compiler Case Study

Hard numbers from Carlini’s post:

• 2 billion input tokens × $5/M (Opus pricing) = $10,000
• 140 million output tokens × $25/M = $3,500
• Total API cost: ~$20,000 (the gap includes retries, failed sessions, overhead)

Estimated confusion taxes:

Orientation — 5–10% of input tokens per session spent on figuring out where things stand. Across 2,000 sessions, that’s 100–200M tokens: $500–1,000.

Duplication — 10–20% of sessions producing work another agent already completed. That’s 200–400 wasted sessions: $2,000–4,000.

Amnesia — 5–10% of total compute repeating approaches already ruled out. Another 100–200M tokens: $500–1,000.

Context pollution — 5–8% of context budget consumed by noise rather than reasoning. 100–160M tokens: $500–800.

Coordination — merge conflicts, sync overhead, git-based locking friction. 3–5% of total: $600–1,000.

Consistency — rework caused by agents operating from contradictory assumptions. 2–5% of total: $400–1,000.

Conservative total: $4,500–$8,800 in confusion taxes.

That’s 22–44% of the project’s total cost spent on problems caused by agent amnesia.

Is this estimate generous? Maybe. Is it directionally correct? Almost certainly. Carlini himself documented every one of these failure modes, and he’s one of the best in the world at this. Most teams will hit them harder.

Extrapolating to Typical Workflows

Carlini’s project was extreme — $20K, two weeks, 16 agents. Most multi-agent workflows are smaller but more frequent. Let’s look at what a typical Claude Code power user might experience:

Scenario: A development team running agent teams daily

Conservative (solo developer, $500/month, ~200 sessions): confusion tax around 20%. Monthly waste: $100. Annual: $1,200.

Moderate (small team, $2,000/month, ~800 sessions): confusion tax climbs to 30%. Monthly waste: $600. Annual: $7,200.

Heavy (engineering org, $10,000/month, ~4,000 sessions): confusion tax hits 35% — it gets worse at scale. Monthly waste: $3,500. Annual: $42,000.

The confusion tax rate increases with scale. More agents means more potential for duplication, more sessions means more orientation overhead, larger projects mean more stale context to navigate. Carlini’s experience at 16 agents suggests the relationship is super-linear — the problems compound faster than the team grows.

The Industry-Level Picture

It’s early days for agent teams, but the trajectory is clear. Claude Code has been growing rapidly. Multi-agent patterns are moving from experimental to standard practice. If we assume:

• 10,000 developers adopt multi-agent workflows within 12 months
• Average monthly API spend: $1,000 (blended across usage tiers)
• Average confusion tax: 25%

That’s $2.5 million per month in wasted computation across the ecosystem. $30 million per year. And that’s a conservative estimate based on a single platform.

Multiply across OpenAI’s Codex, Google’s agent frameworks, and the open-source agent ecosystem, and the total confusion overhead in multi-agent AI development probably reaches hundreds of millions of dollars annually within two years.

What a Memory Layer Changes

The solution isn’t more sophisticated orchestration. Agent teams already handle coordination well — task assignment, messaging, dependency tracking. What’s missing is institutional memory.

A memory layer for agent teams needs to do five things:

1. Instant orientation. When a new agent spawns, it should immediately have access to the project’s accumulated knowledge — decisions made, approaches tried, architectural constraints, current status. Not by reading a README that another agent may or may not have updated, but by querying a semantic knowledge base. Orientation time drops from minutes to milliseconds.

2. Deduplication at the source. When Agent B considers working on a problem Agent A already solved, the system should detect this before Agent B starts. Not after it’s produced duplicate code and caused a merge conflict. This requires comparing the semantic content of what’s being attempted against what’s already known — not just checking a flat task list.

3. Persistent learning. Failed approaches should be recorded so that no future agent repeats them. This is the single highest-ROI feature a memory system can provide for multi-agent workflows. In Carlini’s project, agents didn’t just duplicate successful work — they duplicated failures, which is pure waste with zero upside.

4. Conflict detection. When two agents reach contradictory conclusions, the system should flag this before it manifests as a runtime bug. If Agent A decides the authentication module should use JWT and Agent B starts implementing session tokens, that conflict should surface immediately — not when someone deploys to production.

5. Graduated context density. Not all knowledge is equally important for every agent. Critical architectural rules should be available to every session. Background reference material should be searchable but not preloaded. Detailed implementation notes should only surface when relevant. This prevents the context pollution that Carlini worked so hard to mitigate.

This is what I’ve been building with Stompy. It’s an MCP-based memory system that provides persistent, searchable, versioned context across sessions. Agent teams handle the collaboration — who works on what, how they communicate, when tasks are done. Stompy handles the memory — what agents know, what’s been tried, what to avoid, what decisions have been made.

The two systems are complementary in a way that feels almost too clean. Teammates automatically load MCP servers from the project configuration. Add Stompy as an MCP server, and every agent in every team gets shared memory without any additional setup.

The Broader Pattern

If this framing — semantic pre-classification of information to avoid redundant processing — sounds familiar, it should. It’s the same pattern that appears in tactical military networks, where sensor platforms generate data at rates two to three orders of magnitude beyond available link capacity. The solution there is the same: evaluate what’s genuinely new before you transmit it.

I’ve been researching this pattern for a paper on “delta evaluation” — the process of computing the semantic difference between incoming data and existing knowledge to determine what deserves attention. The same architecture that reduces bandwidth consumption in NATO tactical networks by 60–80% reduces token consumption in multi-agent AI workflows by 20–40%.

The numbers are different. The math is the same.

When you have more data than you can process — whether it’s sensor reports on a battlefield or agent-generated code in a development environment — the most valuable thing you can do is figure out what you already know before spending resources on processing it again.

What Happens Next

Agent teams are genuinely exciting. They represent a step change in what’s possible with AI-assisted development. Carlini’s C compiler — 100,000 lines of Rust that can compile the Linux kernel, built in two weeks — would have been science fiction eighteen months ago.

But the confusion taxes are real, they’re expensive, and they scale faster than the teams they tax.

If you’re experimenting with multi-agent workflows — whether agent teams, subagents, or custom orchestration — start tracking three things:

1. How many sessions start with orientation rather than productive work. If it’s more than 5%, you have an orientation tax problem.
2. How often agents attempt work that’s already been done. Check your git history for reverted or overwritten changes. Each one is a data point.
3. How frequently the same failing approach appears across different sessions. This is the hardest to measure and the most expensive to ignore.

We’re opening a closed beta for Stompy soon. If you’re running multi-agent workflows and want your Claude Code sessions to stop starting from scratch every time, join the waitlist at stompy.ai.

Or don’t. The analysis in this article stands regardless. Agent amnesia is an expensive problem. Whether you solve it with Stompy, with custom tooling like Carlini built, or with something else entirely — solve it. The math says you can’t afford not to.

The author has spent way too many years watching institutions mistake structural barriers for permanent advantages. He’s consulted on transformation for NATO, EU institutions, and organizations that genuinely believed complexity would protect them forever. He’s tired of watching intelligent people confuse artifacts with knowledge, and restriction with security. His rubber chicken remains unimpressed. He builds AI memory systems and occasionally writes about them. He’s based in The Hague and can be found thinking about semantic deduplication at inappropriate hours.

I. The Tool That Broke Itself

December 2025. I’m building a context locking feature for Stompy, the mechanism that prevents AI assistants from forgetting things between sessions. The AI assistant helping me build it gets stuck in a recursive loop — it locks its own operational context and can’t proceed. The exact problem the tool was designed to prevent, caused by the tool being built to prevent it.

My response in the chat: “hahaha, did you actually lock your own context with this? :D”

That bug led directly to anti-recursion safeguards in the final implementation, which is how most of the useful code in this system came to exist. Not through upfront specification, but through the system breaking in ways that revealed what it actually needed. When I do fractional CTO work and inherit troubled projects, this pattern — or its absence — is one of the first things I look for. Codebases that learn from their own failures accumulate capability. Codebases that only accumulate features tend to accumulate mass instead.

This is a story about seven months building an AI memory system called Stompy — 604 commits across three repositories, 127,814 lines of code, four major architecture pivots, and five ironic bugs where the tool demonstrated its own problem domain. It’s also a demonstration of the diagnostic patterns I’ve developed across thirty years of building systems in military, government, and enterprise contexts, because the same questions that help me assess whether a troubled project can be rescued are the questions that kept this build on track.

II. The Timeline: Six Major Versions in Seven Months

The version numbers tell the iteration story more clearly than the calendar does. Each major version represents a fundamental architectural shift — not incremental features, but wholesale rethinking of how the system should work.

Version 1: Proof of Concept (June 2025)

First commit: June 8th. An open-source experiment called claude-dementia — dark humor for a tool designed to cure AI memory loss. Version 1 was nothing but a Claude.md file, a markdown document that Claude could read at conversation start. No MCP, no database, no tools. Just a text file that proved the concept: does giving an AI persistent memory actually help?

Thirteen commits that month, enough to answer the question. The code barely mattered; the insight did. This is what I mean when I talk about building to learn — the first version existed to test a premise, not to ship a product.

Version 2: Structured Data (July 2025)

The markdown file became a SQLite database. Still accessed directly through the filesystem MCP, still running locally, but the shift from flat text to structured data changed what was possible. Queries instead of grep. Relationships instead of headers. The memory system could now be searched rather than just read.

This version proved that structure enhanced memory rather than constraining it. The data model that emerged here — topics, versions, tags, priorities — survived essentially unchanged through every subsequent rewrite.

Version 3: Formalised Tools (August 2025)

The first proper MCP server. Instead of the AI manipulating files through a generic filesystem tool, it now had purpose-built operations: lock_context, recall_context, search. The API surface that would define user interaction with the system took shape here.

The commit count stayed modest, but the architectural significance was total. Everything that followed depended on this decision to formalize tool calls rather than rely on filesystem manipulation.

Version 4: Managed Infrastructure (September-October 2025)

The jump to production infrastructure for a single tenant. VoyageAI for embeddings. Neon PostgreSQL replacing SQLite. The MCP server still running locally, but now connecting to cloud services that could scale.

111 commits in October alone — schema migration month. The database structure that seemed adequate under local load revealed its limitations when real usage patterns emerged. Multi-tenancy foundations. Version control for locked contexts. Embedding storage optimization.

This is the phase that often gets skipped in troubled projects I inherit. Teams push forward adding features without strengthening the structure beneath them, and the foundation cracks gradually until everything built on top becomes unstable. When I assess a codebase, I ask when their last “boring” month was — the period where visible progress stalled because the team was reinforcing what they’d built. Projects that can’t point to those phases are projects building on sand.

Version 5: Fully Managed (November-December 2025)

217 commits in November, the highest concentration of the entire build. The system moved from local MCP connecting to cloud services to fully managed infrastructure — everything online, nothing requiring local installation.

This wasn’t a deadline push but discovery density. Daily use across dozens of concurrent projects meant every session revealed something the architecture needed to handle. Tool consolidation happened here: the API surface that made sense in isolation made no sense in practice, so thirteen tools became seven. The system wasn’t being built anymore; it was being carved.

December added 133 backend commits plus 60 commits on stompy-web — a frontend that didn’t exist in the original conception. Dashboard, user management, the interface layer that transforms a developer tool into a product. Version 5.3.0 brought embedding optimization: smaller models, lazy generation, deferring expensive work until someone actually searches.

Version 6: Multi-Tenant Beta (January 2026)

The commit velocity drops, not because work stopped but because the system stabilized. The current build: proper provisioning, isolated tenant schemas, the infrastructure that lets multiple users share the platform without sharing each other’s data.

581 development sessions logged. 2.8 million memories stored. 69 locked contexts capturing versioned knowledge. 36 projects tracked. One stress test day hit 490 sessions, and the system held.

Version 7: Gold Master (Planned)

Feature complete with billing, subscriptions, the commercial infrastructure that closes the loop between product and business. Not yet built, but the path is clear because the foundation work is done.

Six major versions in seven months. Each one a wholesale reconsideration of how the system should work, not incremental features bolted onto a frozen architecture. This is what iteration velocity actually looks like — not moving fast on a fixed plan, but moving fast through fundamental rethinking.

III. The Ratio That Tells the Story

Here’s what the commit types reveal across the production backend:

Type — Count — Percentage
fix — 230 — 43%
feat — 132 — 25%
docs — 49 — 9%
refactor — 25 — 5%

Forty-three percent fixes to twenty-five percent features. Most people read that ratio as a problem — nearly twice as many fixes as features must mean buggy code, poor initial design, accumulating technical debt. The framing is wrong, and recognizing why it’s wrong is central to how I diagnose troubled projects.

Real iteration fixes more than it builds, because every fix represents a discovered edge case, a usage pattern that couldn’t be anticipated, a system interaction that only revealed itself under real conditions. The fixes are the product evolution. You don’t learn what the system needs by specifying it in advance; you learn by watching it break, then preventing that break from happening again.

When I inherit a codebase as a fractional CTO, the fix-to-feature ratio over the last six months is one of the first metrics I pull. If features dominate overwhelmingly, the project is probably building on unstable ground — adding capability faster than it’s learning what works. If fixes dominate without corresponding stability improvements, there’s churn without learning. The healthy range sits somewhere around what Stompy showed — fixes slightly outpacing features, indicating a codebase that’s actively learning from its own usage.

230 times something broke in Stompy. 230 times it got fixed forward — not reverted, not redesigned from scratch, but corrected and committed. This is the compound effect of small corrections, and it’s what distinguishes projects that accumulate capability from projects that accumulate mass.

IV. The Pivots: When the Direction Was Wrong

Four major architecture decisions turned out to be wrong, which sounds like a confession but is actually the point.

Pivot 1: Agent Orchestration (REJECTED)

The original design included auto-implementation — AI agents watching a Linear board, automatically implementing whatever tickets appeared. Sophisticated dispatch, parallel execution, impressive architecture diagrams.

User response during design review: “This sounds dumb — assumes every ticket is doable and relevant.”

The assistant’s reply: “You’re right. I was solving the wrong problem. The bottleneck isn’t dispatch — you’re the tech lead. Auto-implementing random tickets is dumb.”

Weeks of potential wrong work avoided by building just enough to see the premise was flawed. When I assess troubled projects, I ask whether the team can tell me why they aren’t doing something they once planned to do. The agent orchestration rejection in Stompy’s history matters because it’s documented with reasoning. Projects that can’t articulate their rejected paths are projects that don’t learn from exploration.

Pivot 2: Local → Cloud

Initial implementation used SQLite — local storage, fast queries, simple deployment. The realization came later: cross-device access is meaningless if memory lives on one machine. Migration to Neon PostgreSQL followed, serverless and scaling to zero when idle. The performance characteristics we’d optimized for didn’t matter; the deployment model we’d ignored did.

Pivot 3: Python vs Go

Serious consideration went into rewriting the backend in Go — performance, concurrency, the aesthetic appeal of a “proper” systems language. The decision to stay with Python came down to diagnosis: the bottleneck is context rot, 200k tokens compressing to 10k, not execution speed. We were solving the wrong performance problem.

This is something I watch for in troubled projects: teams optimizing the wrong constraint. They’ll spend weeks shaving milliseconds off response times while their users are struggling with a confusing interface. The Python-versus-Go debate forced us to ask what actually needed to be fast, and the answer wasn’t what we’d assumed.

Pivot 4: Naming

Internal: “Dementia.” Dark humor acknowledging that the tool cures AI memory loss. Public: “Stompy.” Elephants never forget. Documented rationale: “Lands better in polite company.”

Four pivots, four moments where the direction changed based on what building revealed. Each one a decision made possible by having working code to evaluate rather than specifications to debate.

V. The Bugs: Where the System Taught Itself

Four bugs where the tool demonstrated its own problem domain, plus the recursive locking incident that opened this article.

Bug 1: Race Condition (DEM-180)

Two tasks reading MAX(version) simultaneously, causing lost writes. Classic database concurrency that only emerges under actual concurrent load. Discovery method: it happened, then it couldn’t happen again.

Bug 2: Export Binary Bloat

The export function dumped raw embedding vectors, causing files to balloon beyond usable sizes. Solution: regenerate embeddings on import rather than shipping what can be recreated. This is the kind of optimization you don’t specify in advance because you don’t know where the bloat will appear until you see the exports failing.

Bug 3: Tool Visibility Leak

Built visibility controls for beta versus production tools, then forgot to wire them into the API endpoint serving tool lists. Beta users could see admin tools. Architecture correct, implementation incomplete — which is why you ship to users rather than specification reviewers.

Bug 4: Context Contamination

The assistant locked a document in the wrong project, putting Project A’s context into Project B’s memory. The exact problem multi-project isolation was designed to prevent, demonstrated by the system designed to prevent it.

The fix went beyond prevention: it forced the API to support moving contexts between projects deliberately. What started as contamination became a feature — project isolation with intentional cross-project transfers when you actually need them. The bug report became the test case, and the test case became the feature spec.

This bug-to-feature pipeline is another diagnostic I run on troubled projects. How many bugs became features? In Stompy, context contamination led to intentional cross-project transfers; race conditions led to proper version isolation. If bugs only become fixes, the team is playing defense. If bugs sometimes become features, the team is learning from the system’s own behavior about what it actually needs.

The fifth bug — recursive locking — opened this article. The tool that ate itself now has safeguards, and every lesson was unspecifiable in advance.

VI. The Revert Count

604 commits across seven months, and not a single revert.

No “undo everything, start over.” No “that whole approach was wrong, delete it.” Just forward motion, each commit building on the last, mistakes corrected rather than erased.

This isn’t luck or exceptional foresight. It’s a sign that changes stayed small enough to fix forward rather than requiring rollback. The revert is the iteration failure mode — it means the direction was so wrong that the only recovery was backward movement, that the small bets compounded in the wrong direction until reversal became cheaper than correction.

When I assess a codebase, the revert frequency tells me how the team is calibrating their bets. Frequent reverts mean the team is making changes too large to correct incrementally. Zero reverts across 604 commits means the decisions stayed small enough that forward motion was always possible, that mistakes could be fixed without unwinding everything that came after them.

This is what “fail fast” actually means in practice — not “fail catastrophically and pivot,” but fail small, fail forward, fail in ways that teach without destroying.

VII. How This Article Was Written

Here’s the meta-layer worth noting: every number in this article came from Stompy itself.

The 604 commits were retrieved via db_query—direct SQL against the project's PostgreSQL schema. The bug details are stored as locked contexts with conversation links preserved. The pivot decisions live in versioned snapshots, searchable months after they happened.

When I started writing this piece, I ran context_search("stompy development journey metrics"). Semantic search returned the locked context containing commit counts, monthly distributions, bug incident links, and pivot conversation references—not because I remembered what I called it, but because Stompy's VoyageAI embeddings matched meaning rather than keywords.

I didn’t write this article by digging through seven months of chat history or grepping through Git commits looking for the November spike. I asked Stompy what it remembered about building Stompy, and the tool remembered. That’s the product: an AI memory system built using an AI memory system, documented by querying its own memory of being built.

Delta evaluation flagged when I tried to store redundant context. Conflict detection caught when early architectural decisions contradicted later ones. Project isolation kept the LinkedIn content work separate from the development work, even though both happened in parallel.

Every feature described on stompy.ai exists because we needed it while building stompy.ai.

VIII. What the Numbers Prove

I write frequently about iteration, about building to learn, about the value of working software over comprehensive documentation. Here’s what that philosophy produces when you actually practice it:

• Seven months, 604 commits, zero reverts
• 127,814 lines of code across three repositories
• 43% fixes to 25% features — learning outpacing building
• Four major pivots executed without paralysis
• Five ironic bugs that became the test suite
• 581 development sessions, 2.8 million memories stored
• A free tier at launch, enabled by demonstrable software

The recursive bug from the opening got fixed. The tool that locked its own context now has safeguards. The system that contaminated projects now verifies isolation. Every failure became a feature; every mistake became a prevention.

These are also the patterns I look for when I inherit troubled projects — the fix-to-feature ratio, the revert count, the pivot documentation, the bug-to-feature pipeline, the foundation work. The Stompy build didn’t invent these diagnostics; it demonstrated them clearly enough to articulate.

Not confidence, not a master plan, not the certainty that you’re right from the beginning. Just the willingness to commit, push, and discover what breaks — then fix it forward, 604 times and counting…

Stompy is now in closed beta with a free tier. If you’re tired of re-explaining your projects to Claude every session, join the waitlist.

The elephant remembers. Now your AI can too.