Third page in Operation Scarecrow. If you haven't read The Company Brain Is Four Different Problems yet, start there. Source citations at the foot of this piece.
A postmortem. A one-pager explaining why the team picked X over Y for a feature. A closed customer escalation, with the resolution attached. A sales call's objection-and-response, tied to a specific deal. An Architecture Decision Record. All of these are the same kind of object wearing different clothes: something specific happened, on a date, for a reason someone wrote down — and the next person who hits a similar question should be able to find it.
That's the whole distinction this tier exists to hold. A decision is a precedent, not a law. It's worth recording and worth retrieving, but it isn't yet something an agent should state as settled fact the way it would state a glossary definition. The gap between "this is what we decided, and here's why" and "this is simply true, firmwide" is the entire difference between this tier and the next one up — and collapsing that gap, filing a logged decision and a settled fact under one review process, was the specific mistake the original ProductHarness backplane made before this section split the two apart.
Where it already lives, and why that's the actual problem
At Meridian — the illustrative mid-market SaaS company this section's worked example uses throughout — this tier already exists, just without a shared shape. Postmortems and incident retros live in Confluence. Product decision one-pagers live in Notion. Closed customer escalations live wherever CS closes tickets. Sales call notes tied to a specific objection live in Gong or Salesforce. And only in engineering does anything look like a deliberate practice: a docs/adr folder that borrowed the versioned, supersede-don't-edit discipline on purpose.
Every one of those is a dated, reasoned record. None of them can be cross-referenced against each other, because each lives in a different tool with a different review bar, or no review bar at all. A postmortem and a decision one-pager are the same kind of thing, and today nothing about how they're stored reflects that.
What's already built
Unlike working memory, this tier doesn't have one clean, already-solved answer — it has several real implementations, each proving a piece of the pattern works. Zep and Graphiti store episodic content as a dedicated "episode subgraph" inside a bi-temporal knowledge graph: every fact carries both when it happened and when it was recorded, with provenance attached structurally rather than by convention. Letta's "recall memory" tier holds conversation history outside the active context window, searchable on demand rather than always loaded. On the human-process side, Architecture Decision Records — Michael Nygard's 2011 format — are the direct non-AI precedent: a short, dated Status/Context/Decision/Consequences record, one per decision, versioned as markdown next to the code it governs.
Access, across all of these, follows the same shape: broadly readable by anyone or any agent doing precedent search, but write-append-only. A new ADR supersedes an old one; nobody edits history in place. Zep's graph enforces this structurally, through temporal validity intervals that close rather than rows that get overwritten.
One implementation is worth calling out on its own. Palantir's Ontology auto-generates a permanent, dated log entry for every write-back action in Foundry — who, when, what changed — without anyone having to remember to file it. That's the most mature version of this tier surveyed anywhere in the research behind this section, running in production across hundreds of enterprises rather than existing as a pattern someone still has to adopt. Most of what this page argues for is a design goal; this specific piece is already a shipped, running system.
Governance: lighter than semantic, heavier than working
This tier's review bar sits deliberately in the middle. PR-based review before an entry gets treated as filed, not the heavier approval chain a settled fact needs, but not the zero-governance-by-design of working memory either. A four-state minimum — Proposed, Accepted, Deprecated, Superseded — with an explicit ownership chain covering who can propose versus who can accept is the standard scaffold, and it isn't optional ceremony. The ADR literature is blunt about what happens without it: a practice with no review process and no regular cadence "degrades into write-only and the team eventually stops trusting it." A decision log nobody checks is worse than no decision log, because it creates the appearance of institutional memory without the substance of it.
The actual leverage, and why it isn't just filing
Giving postmortems, decision one-pagers, closed escalations, and ADRs one shared shape — dated, reasoned, supersede-don't-edit — and making them one queryable store instead of five separate tools is most of the fix. The ADR discipline already proves the pattern works inside engineering; the job is extending it, not inventing something new.
But the part that actually creates leverage for an agent, rather than just for a future human doing an archive search, is narrower and more specific: "has this exact question already been decided" needs to become a single retrieval an agent runs before it drafts a new decision or handles a new escalation — not a search a human has to think to run. That's the difference between episodic memory as an archive and episodic memory as something an agent actually consults mid-task. The leverage this tier buys is non-repetition: the same debate doesn't get re-litigated from scratch by a different team six months later, simply because nobody knew it had already been settled once, with reasons, on the record.
What follows from here
This page covers the tier itself — what it is, where it lives today, and what fixing it actually takes. Two things it deliberately doesn't cover: the full mechanics of promoting a well-evidenced episodic pattern into a settled semantic fact, which the next page in this section takes on directly, and the specific worked walkthrough of challenging and superseding an already-settled fact — the reconsolidation model, grounded in real neuroscience — which belongs to the Meridian worked-example page later in this section, where there's room to walk through it properly rather than compress it into a paragraph here.
What retention actually costs
There's a real cost question sitting underneath the governance model this page argues for, and nothing in the research behind this section resolves it. Supersede-don't-edit — the rule that preserves provenance and lets a future reader trust what they're looking at — means this store grows monotonically forever. Nothing is ever deleted, only closed. Graph-backed implementations like Zep add entity resolution and reconciliation on every ingest, which is real, recurring compute, not a one-time cost. How long an organization actually keeps every superseded record, and whether "never delete" survives contact with a real retention and storage budget the way it survives contact with the argument for why it's correct, is a genuinely open question. This page states the rule with confidence because the rule itself is right; it doesn't claim the economics of running it forever have been worked out.
Sources. Michael Nygard, Architecture Decision Records template and practice, via github.com/joelparkerhenderson/architecture-decision-record and analysis at hidekazu-konishi.com. Zep / Graphiti: "Zep: A Temporal Knowledge Graph Architecture for Agent Memory," arxiv.org/abs/2501.13956; Neo4j, "Graphiti: Knowledge graph memory for an agentic world," neo4j.com/blog/developer/graphiti-knowledge-graph-memory. Letta/MemGPT tiered memory: Letta, "Agent Memory: How to Build Agents That Learn and Remember," letta.com/blog/agent-memory. Palantir's Ontology architecture: Palantir Foundry documentation, "Overview • Ontology" and "The Ontology system," palantir.com/docs/foundry/ontology/overview; Palantir Blog, "Connecting Agents to Decisions," blog.palantir.com. Meridian is an illustrative, composite company invented for this section — not a real business — standing in for the shape most mid-market software organizations are already in.