Seventh page in Operation Scarecrow. If you haven't read the argument page, the four memory-type pages, and the Meridian worked example yet, start there — this page assumes all of it and pulls the pieces into one picture. Source citations at the foot of this piece.
Pull the four memory-type pages, the worked example, and everything the rest of this section still has to cover into one answer, and it isn't a product. It's an org design plus an assembled architecture — most of which already exists in parts, built by different teams for different reasons, with exactly one piece that doesn't exist off the shelf anywhere: a routing layer that actually knows which of the four tiers a question belongs to.
The org chart
A named semantic steward per domain, not "everyone's responsibility." Real authority to approve or reject a firmwide fact, sitting in Platform or Data or wherever organizational knowledge already lives, with an SLA on approval requests. Facts scoped to one project rather than the whole firm — a specific budget, a specific deadline — stay owned locally, by Finance or the PMO, and only escalate to the firmwide steward if the blast radius crosses domains.
Naming the role isn't sufficient on its own, and treating it as sufficient is a documented, named failure pattern: the "Unfunded Mandate," where a governance council approves policy on paper but never actually empowers anyone to execute it — a pattern research puts behind roughly 80% of data-governance initiatives failing. A steward without a structurally independent reporting line, a tested veto that's actually been held at least once, and an enforceable consequence for overriding the process is indistinguishable from that failure pattern with better branding. Ostrom's commons-governance principles — accountable monitoring, graduated sanctions, cheap and independent conflict resolution — are the rigorous version of what makes a steward role durable; a leaderboard or a quarterly shout-out is not a substitute for actual authority. For an agent fleet specifically, the steward's job extends to calibrating how much unsupervised write authority each agent has earned — Palantir's framing of a new agent as a new hire whose purview widens only as its track record accumulates. "The Unicorn the Org Chart Wants" reaches the same conclusion about a coherence-review function from an entirely different direction, arguing a verification role without the standing to halt a work stream is "documentation of drift, not a remedy for it" — independent confirmation this needs to be owned above the level of any single team.
A coherence-review function does two jobs: watching episodic entries for independent-context repetition, which is the promotion trigger, and receiving challenges to settled facts, which is the demotion trigger. This is the editor of the organization's episodic memory — not a new team, just a mandated practice enforced by whoever already reviews decisions. Engineering ownership extends to cover procedural memory in full, so runbooks and skills get the same PR-review-plus-CI bar as production code, owned by the same tech leads who own the services those runbooks describe — closing the split most organizations currently leave open between a well-run code half and an ungoverned everything-else half. Working memory gets no dedicated owner at all; it's plumbing, run by whichever team owns orchestration infrastructure, because assigning governance here would be the wrong ceremony applied to the wrong tier. And there's an explicit executive escalation path for high-blast-radius semantic challenges, with one hard rule: an override on conviction, without evidence, is allowed, but it gets logged as an override, so a future reader of that fact knows whether it changed because independent signals converged or because someone senior overruled them.
Procedural and working memory are owned independently by engineering and orchestration — they don't route through the semantic steward, because governance weight follows blast radius, not org-chart proximity.
What they're actually doing, day to day
A decision doesn't count as made until its record gets filed — lightweight, dated, reasoned, the same schema whether it came from engineering, sales, or support. Metrics and status get frozen on a schedule rather than whenever someone remembers: budgets close monthly, status reports snapshot weekly, and each snapshot becomes an immutable episodic record the way closed accounting books already work. When the same conclusion shows up in three separate, non-coordinated episodic entries, it gets flagged for promotion review automatically instead of waiting for someone to notice the pattern by feel — and the steward checks provenance before approving, because five teams "confirming" something they all inherited from one all-hands slide isn't independent evidence, it's an echo.
The promotion itself follows a propose-don't-commit pattern: an agent or a person proposes the fact, the system computes a structured diff against current state, and the write commits only once the steward approves it, never automatically. "Agents Run the Line, Humans Hold the Gates" names the same split in different language, for product discovery rather than memory specifically — agents can run all the labor, but a small number of gate decisions never transfer, not from a capability gap but because the ground truth for a gate decision lives outside anything a test can check. Promotion-to-semantic is exactly that kind of gate.
Runbooks get versioned, tested where a step is scriptable, and deprecated on a schedule instead of rotting silently in a wiki — with one caution worth carrying forward plainly: letting agents write their own procedural memory is not yet a settled win outside narrow, deterministically-verifiable domains, and self-generated skills in general-purpose settings currently underperform not having a skill library at all. Procedural self-authorship gets the same review bar as human-written code, not a lighter one, until that changes. When a semantic fact changes, lineage tracking flags every downstream procedural artifact that baked in the old version — battlecards, pricing tiers, onboarding copy — so the fact doesn't quietly stay wrong in practice for another year after it's corrected on paper.
The technical architecture
No vendor ships all four tiers with differentiated governance today. That finding held across everything surveyed for this section — Mem0 and Zep blend episodic and semantic behind one retrieval mechanism, Palantir gets the object separation right but still runs one governance model across procedural and episodic inside its Kinetic layer, and a wider pass across Glean, Microsoft Copilot and Graph, Salesforce Data Cloud and Agentforce, and ServiceNow found five vendors each solving a different piece and none assembling all of them. The end-state stack is assembled, not purchased whole, and one substrate decision underlies all four tiers before getting into them individually: memory needs to live in an external, revisable store rather than get fine-tuned into a model's weights. Weights-based storage reasons better on transfer tasks, but the entire governance model this architecture depends on — supersession, reconsolidation, an override that gets logged rather than hidden — requires being able to cleanly retract or demote a fact, and unlearning something baked into weights is still largely unsolved. Governability costs some capability. That trade is made deliberately here, not by default.
Tier by tier: working memory is a checkpointed, task-scoped state store, TTL-based, no embeddings, no review gate — on close, a summary hook hands a compressed version to episodic or discards it, and conflicting writes across a multi-agent fleet resolve automatically via CRDT-style merge, because the cost of a wrong merge here is low and short-lived. Episodic memory is a bi-temporal, provenance-tracked store recording dated, reasoned entries with explicit origin tracking, supersede-don't-edit enforced structurally, with conflicting writes resolved through deterministic supersession — timestamps and provenance, never an LLM's own judgment call about which of two contradictory memories is correct. Semantic memory is a governed knowledge graph or data catalog with named stewards, real approval chains, and explicit versioning — and this is the one tier where a contradiction between agents should never resolve silently: conflict-preserving handling keeps the disagreement visible as its own object until a steward resolves it, because an agent that sees an unresolved conflict can decline to act on it, while an agent handed an auto-merged answer has no way to know a disagreement ever existed. Procedural memory is version-controlled skills and runbooks invoked by agents as callable tools rather than read as documentation — the one tier where the leverage is direct automation, not faster human decisions.
The consolidation engine is a scheduled or event-triggered process, Dreaming-style, that reviews accumulated episodic entries, checks for independent-context repetition, proposes promotions routed to the relevant steward rather than auto-applying high-blast-radius changes, prunes and merges redundant entries, and flags contradictions into the reconsolidation pipeline instead of letting them sit unresolved. A real, smaller-scale version of this already runs in production: "The Best Context, In Practice: A Bot Named Chiefys" describes an internal tool that holds a curated, ratified document set and actively audits it against new material, surfacing contradictions and forcing a retire-or-declare-intentional decision — the consolidation engine's contradiction-flagging function, minus the promotion mechanism, already running at one company.
The routing layer is closer to existing than it might look, but still not the thing this architecture actually needs. Adaptive RAG — a query classifier that routes each question to the pipeline suited to its complexity — reports gains as large as a 35% accuracy improvement when the right pipeline gets chosen. But that classifier routes on complexity, not on memory type. Nothing surveyed anywhere in this research routes a query based on whether it needs a live number, a settled fact, a precedent, or a how-to specifically — that four-way, tier-aware version is still the piece that has to be built rather than adopted. Every answer it returns needs to carry its own provenance and freshness — this is live as of now, this was true until this date, this was decided but not yet firmwide — instead of sounding equally authoritative regardless of source tier. That labeling matters for a second reason beyond epistemic honesty: a real court ruling has already held a company liable for presenting a confidently wrong AI-generated summary as settled fact, and an honestly-labeled provisional answer is plausibly the difference between that outcome and not. There's a human-factors reason too — a cleaner, more transparent-looking interface can produce less scrutiny from the humans using it, not more, which is exactly backwards from what a tier-labeled, honestly-hedged interface is trying to achieve. This whole question — what an org owes the human on the other end of the answer — gets its own full treatment later in this section.
Wrapping all of it: governance and observability
Every memory write, across all four tiers, carries structured provenance metadata — source, timestamp, a trust score assigned at ingestion, and the path it was written through — not just an audit log appended after the fact. Attack success rates against a provenance-gated store drop to zero at every tested budget in the research behind this, because injected entries score below the trust threshold before anything acts on them. Audit logs remain the record of what happened; provenance scoring at read time is what stops a bad entry from being acted on before anyone reviews it; and a forensic layer built for causal attribution and anomaly detection catches what the first two miss. Access control is scoped per tier — broad read with narrow, steward-gated write for semantic and procedural; broad read and write within schema for episodic; task-scoped only for working. A memory-health dashboard tracks the unreviewed episodic backlog, staleness in the semantic layer, and drift between code and the runbooks that describe it.
The assembled architecture this page argues for: four differently-governed tier stores feed a consolidation engine, which feeds the routing layer that still has to be built, wrapped throughout in provenance tagging and access control.
Two gaps that don't get smoothed over
Two limits get named directly here instead of smoothed into the architecture's confidence. A poisoned or wrong semantic fact can produce behavior indistinguishable from ordinary model imperfection, and the standard response — retraining or patching the model — doesn't remove a bad memory entry, consumes real remediation effort, and leaves a false sense the problem is fixed. Provenance scoring reduces how often this happens; it doesn't guarantee it never does, and this page doesn't claim otherwise. And at real fleet scale, a monitor built to catch conflicts assumes a human or a privileged process is available to intervene when one crosses a decision boundary — what happens when boundary-crossing conflicts arrive faster than that intervention capacity is a capacity-planning problem this architecture doesn't yet have an answer for. Both gaps get named here specifically so they don't quietly disappear into the confidence of the rest of the page.
Where this actually shows up
A PM asks an agent, "what's our remaining budget on Project X?" A router that knows what it's doing has to decompose this into three separate lookups, not one: the formula for "remaining percent" lives in semantic memory, governed, so Finance and the PMO aren't quietly computing it two different ways; the current value is working memory, recomputed from live actuals, cheap and disposable; and if the PM instead asks "what did we report last month," that's an episodic snapshot — the closed, immutable record from last month's close, not this month's moving number. An agent that can't tell these apart gives a confidently wrong answer that sounds exactly as authoritative as a correct one. An organization that's actually built this out gives an answer with its own freshness label attached, and that's the entire difference between a Company Brain that plateaus after the easy retrieval wins and one that keeps getting more useful the longer the organization runs it.
What follows from here
This page previews six problems it assumes an answer to without fully arguing any of them: how a poisoned or falsified entry actually gets caught, what happens when two agents in the same fleet disagree with no human in the loop at the moment of conflict, why naming a steward isn't enough to make the role survive contact with a real org, what changes when an AI proposes the memory instead of just reading it, the tradeoff between baking a fact into a model's weights and keeping it in an external store, and what an organization owes the human who asked the question in the first place. Each gets its own full page next.
Sources. This synthesis draws on the full Operation Scarecrow research base rather than primary sources directly. The steward "Unfunded Mandate" failure pattern and Ostrom's commons-governance principles, the propose-don't-commit promotion pattern, the CRDT-versus-conflict-preserving multi-agent handling, the weights-versus-external-store substrate decision, Adaptive RAG, the court ruling on AI-generated summary liability, and the provenance-gated defense numbers are each sourced in full on the individual pages that treat them directly later in this section. Three published ProductHarness essays are cross-linked above as independent corroboration, found rather than sought: "The Unicorn the Org Chart Wants", "Agents Run the Line, Humans Hold the Gates", and "The Best Context, In Practice: A Bot Named Chiefys".