This page sits in Operation Scarecrow alongside If Only We Had a Brain as a second entry point — that piece is why this section exists; this one is what it recommends. Everything below is argued in full elsewhere in this section; this page states the conclusions and points back rather than re-arguing them. Source links at the foot point to the page that carries each claim's actual evidence.


Fourteen pages is a lot to ask of someone deciding whether to fund this. What follows is the compressed version: the handful of conclusions that are actually load-bearing, a rough order to act on them in, and the parts of this that are still honestly unresolved rather than quietly assumed away.

If you do nothing else, do these four things

01
Stop building one memory system.

Split governance by tier, not by project or by vendor. Working memory (in-flight status, decision queues) gets almost no governance — TTL, no review, cheap to be wrong. Semantic memory (settled facts, the glossary, hard constraints) gets the heaviest governance in the system — a named steward, an approval gate, logged overrides — because it's cited everywhere and a wrong entry has organization-wide blast radius. Episodic memory (dated decisions, precedent) gets a lightweight filing requirement, not full review. Procedural memory (runbooks, skills, code) gets the same PR-and-CI bar your engineers already apply to production code. Applying one governance rule to all four — which is what nearly every "Company Brain" product does today — is the specific, mechanical reason these initiatives stall after an impressive pilot. Argued in full in The Company Brain Is Four Different Problems. Semantic-rated: this is the part of the argument least likely to move.

02
Fund the steward role, don't just name it.

Roughly 80% of data-governance initiatives fail the same way — a role gets created, nobody gets an independent reporting line, a tested veto, or an enforceable consequence for being overridden. That's not a motivation problem a leaderboard fixes; it's an authority problem. If you're naming a semantic-memory steward, give them standing that survives the first time their call costs someone something. Argued in full in Naming a Steward Isn't Enough.

03
Label every answer with where it came from and how fresh it is.

This used to be a purely epistemic argument. It isn't anymore — a German court has already held a company liable for presenting a confidently wrong AI-generated summary as settled fact, and separately, a cleaner-looking AI interface has been shown to reduce how much people scrutinize its answers, not increase it. Whichever tier an answer was pulled from, say so. Argued in full in The Answer That Sounds Too Sure.

04
Build provenance tagging once, and let it do two jobs.

Source, timestamp, and a trust score on every memory write is simultaneously what makes a promoted "fact" trustworthy and the specific defense that's been shown to drop poisoning-attack success to zero at every tested budget. Don't staff memory governance and memory security as two separate efforts — it's the same infrastructure serving both. Argued in full in When the Memory Lies.

Where to actually start, in order

01
Inventory what you already have, sorted by tier, before buying or building anything.

Nearly every artifact your org already produces — tickets, postmortems, runbooks, the pricing sheet, the glossary nobody owns — already belongs to one of the four tiers, or in a small number of cases splits across more than one. Doing this sort first tells you where your actual exposure is before a vendor tells you where theirs is. Walked through in full in A Company That Doesn't Exist, Mapped Anyway.

02
Govern procedural memory first — it's the tier you already know how to govern.

Runbooks and skills just need the same review bar your engineers already apply to code. This is the cheapest, fastest win on the list, and it closes the gap most orgs currently leave open between a well-run codebase and an ungoverned everything-else half. Detailed in Procedural Memory: How, Not What.

03
Name and fund the semantic steward before you evaluate a single vendor.

No product on the market ships all four tiers with differentiated governance — the survey behind this section checked five major players and found each solved a different piece. Buying a tool doesn't discharge this step; a steward with real authority is an org-design decision no purchase substitutes for.

04
Decide the weights-versus-external-store question deliberately, not by default.

Fine-tuned memory reasons better; external, revisable memory is the only kind this entire governance model — supersession, override logs, the ability to retract a fact — can actually work with. That's a real capability cost, worth stating to whoever's making the architecture call rather than discovering after the fact. Argued in full in Baked In, or Looked Up.

05
Assume the routing layer doesn't exist yet, because it doesn't.

Nothing surveyed anywhere in this research routes a question by which of the four tiers it actually needs — vendors route by query complexity, not by memory type. If a pitch claims to have solved this, that claim is the first thing to test. Covered in What Done Looks Like.

Where AI should and shouldn't write its own memory, right now

This one's counterintuitive enough to state plainly rather than leave buried, and the tier that looks easiest to hand to AI turns out to be the one with the weakest evidence it should be — argued in full in When the Agent Is the One Writing the Memory.

Tier Verdict Why
Working Go — mature and quantified Compaction cuts input tokens 80%+ with no measurable loss in task quality
Semantic Go, but only with a gate Propose-and-approve already exists, named and standardized elsewhere — nothing to invent in-house
Episodic Proceed — don't treat as equivalent yet The field hasn't established how much an AI-authored account should be trusted next to a human-filed one
Procedural Hold off outside narrow, checkable domains Self-generated skills currently underperform not having a skill library at all

What this doesn't resolve yet

Stated directly rather than smoothed over, because pretending these are solved would undercut everything above. Nobody has an answer yet for what happens when multi-agent conflicts arrive faster than a human or a steward can review them. A poisoned semantic fact can produce behavior indistinguishable from ordinary model error, and the standard fix — retrain or patch the model — doesn't remove the bad entry and creates false confidence the problem's gone. GDPR's right-to-forget has no clean answer for a fact synthesized from many sources once the sources themselves are deleted. And whether freshness labeling actually counteracts the miscalibrated-trust problem it's meant to fix hasn't been tested anywhere in the research behind this section — it's a reasonable bet, not a proven one.

None of that is a reason to wait. It's a reason to build the governance and the honesty about its limits at the same time, instead of shipping the first and backfilling the second.


Sources. This page synthesizes claims argued and sourced in full on the individual pages linked above: The Company Brain Is Four Different Problems, Naming a Steward Isn't Enough, The Answer That Sounds Too Sure, When the Memory Lies, A Company That Doesn't Exist, Mapped Anyway, Procedural Memory: How, Not What, Baked In, or Looked Up, What Done Looks Like, and When the Agent Is the One Writing the Memory. No new primary sources are introduced on this page; full citations live on each page above.