One shared, permission-aware, auditable AI memory for an entire organization. Every employee's agent reads and writes the same institutional knowledge, over whatever surface they already work in, under one compaction and degradation-avoidance discipline. This is a vendor-neutral blueprint you hand to a coding agent, and it builds the system with you, stopping to ask at every decision that your cloud, your identity provider, and your regulator would answer differently.
If this blueprint saves your team a design cycle, a star helps other people find it.
A personal AI agent that remembers what it learned last week is a solved shape. The sibling project RAG-OS is one such blueprint: one developer, one always-on agent, a git-Markdown knowledge base it maintains itself. This repo answers the much harder question that shows up the moment more than one person is involved:
How do two hundred people, and their two hundred agents, share one memory without leaking it, poisoning it, letting it rot, or losing the thread?
That question is not RAG with more machines. It breaks specific invariants that make the single-user design simple, and each break has a right answer that is expensive to discover and cheap to copy. This guide is the compiled answer.
A single Markdown file, BUILD-GUIDE.md, plus an agent protocol that makes your coding agent build the system with you rather than dumping a fixed stack on you. It is not a framework to install. It is a compiled architecture: thirteen pillars, seventy decision forks each with a recommended default and its alternatives, thirty-eight failure modes to design against (five carried from the personal system, thirty-three new at org scale), and a sixteen-milestone build order where every step is proven with a real command and its real output before it counts as done.
The founding rule is the same one that makes the personal system work, restated for a crowd: durable state lives in files and a database whose authority is explicitly ordered, the model sessions are ephemeral, and the coordinating layer holds zero model context. What changes at org scale is that the database is no longer one file with one writer, the operator is no longer one trusted person, and the blast radius is no longer one laptop. The whole guide is the disciplined consequence of those three facts.
This is the spine of the guide, and it is worth seeing before you decide whether to read the rest.
| Personal invariant | Why it holds for one person | What it becomes for an org |
|---|---|---|
| One process is the only writer | One event loop serializes every write; coordination is free | One writer per aggregate, enforced by the database, with a fencing token so a zombie coordinator cannot resurrect |
| Identity is a boolean | Are you the operator, yes or no | A graph: who you are, your groups, your clearance, and which agent acts for you, checked freshly on the candidate set, never on the answer |
| The operator reviews every ingest | One trusted human diffs every promotion | Tiered trust by source, a human merge as the untrusted-to-canon boundary, and a rate-capped review queue with named stewards |
| You trust the corpus you built | Poisoning needs you to ingest something hostile | A write is a privilege-escalation primitive; a poisoned memory persists and propagates to everyone |
| One conversation window | The kernel owns it; restart if it fills | Per (surface, thread) windows, because you cannot ask forty people to restart the shared brain |
| One budget, one bill | Your spend, your cap | Per-team attribution and admission control in front of one gateway, before you can even think about control |
| Fences are filesystem paths | One filesystem, and it is yours | The sensitive thing is now a row, a tenant, or a document ACL; path fences stay necessary and stop being sufficient |
| Invalidate, never delete | Correct for knowledge, harmless for one person | Still correct for knowledge, and wrong for personal data, which must be erasable against GDPR while git history is immutable |
Two things are entirely new and have no personal analogue: a legal retention-and-erasure machine, and, for regulated orgs, model-risk governance that forbids the same team from building the system and validating it.
- Open
BUILD-GUIDE.md. - Confirm the six preconditions it lists (an identity provider, a signed data-classification policy, a named owner and librarian, legal sign-off, a capped budget, a behavioral baseline). If any is missing, the guide tells your agent to stop. That is deliberate: a perfect build on a missing legal sign-off is a liability, not progress.
- Paste the file into your coding agent and say: "Help us build this. Follow the agent protocol at the top." It writes your answers into a
DECISIONS.md, builds in milestones, and proves each one with real output.
A defensible pilot for one team lands at Milestone 9. Turning it on for the whole company needs everything through Milestone 14. Regulated banks and insurers add Milestone 15. You do not have to build all of it, and the guide is honest that the later milestones are where most of the real cost and risk live.
Thirteen pillars, each carrying the forks your agent will ask you about. The three marked NEW have no counterpart in the single-user design.
- The coordination plane. Stateless, horizontally-scalable coordinators that hold zero model context, with one writer per aggregate and a fencing epoch instead of one process owning a file.
- Persistence and the authority ladder. An append-only Postgres claim ledger is truth, git-Markdown is a projection of it, the hybrid index is a rebuildable cache over that, and transcripts are disposable.
- Identity, authorization, and tenancy (NEW as a top-level concern). OIDC and SCIM, ACLs keyed on the immutable object ID, Zanzibar-style ReBAC with forced-fresh reads, and permission filtering on the candidate set as the asking human.
- The write path and the curation economy. Tiered staging with a human merge as the structural boundary between untrusted input and canon, and a review queue an org can actually staff.
- Retrieval at organization scale. Hybrid BM25-plus-vector with reciprocal rank fusion and rerank, a two-level index-first curated tier, a permission pre-filter, and read-time supersession.
- Compaction and degradation avoidance. The kernel owns each conversation window, scoped per surface and thread, with three-zone prompt caching and a mutation-time canonicalization hook.
- The interface fabric. One dual-era MCP server, one chat surface, one thin web app, all adapters over one REST API, which is the only reason the memory stays identical everywhere.
- The harness seam and the model layer. One choke point builds every session; model names live in one config; the vendor contract's output indemnity has to follow your consumption channel.
- Security and the agentic threat model. A Rule-of-Two split, sandboxed workers with default-deny egress, and hash-pinned MCP approvals, because the corpus itself is an attack surface.
- Cost governance and chargeback. A gateway with per-team virtual keys, a degrade-then-park ladder with a zero-cost local rung, and attribution before control.
- Governance, compliance, and the record (NEW). Four retention classes, per-subject crypto-shredding, a legal-hold table, and an immutable WORM audit tier with citation-level forensics.
- Operability, DR, and evaluation. Two SLO families, a degradation ladder that fails closed, no index backup (rebuild is the recovery path), and a nightly cross-tenant isolation canary.
- Rollout and stewardship (NEW). A hybrid ownership model, a narrow-and-deep cold start, brownfield coexistence, and behavioral phase gates instead of satisfaction surveys.
The individual ideas are not new, and the guide says so plainly. Git-backed Markdown agent memory shipped as a product in early 2026, and more than one commercial system proves the shape is not exotic. The value here is the org-scale discipline that makes the shape survive a security and compliance sign-off, and the fact that you own and can audit every byte. Here is an honest map of the field.
| System | What it is | How this blueprint relates |
|---|---|---|
| Glean | Permissions-aware enterprise search; the real product is cross-SaaS identity resolution and connectors | Buy this for the connector and identity-mapping work, which is genuinely hard and genuinely rentable. It gives you no git-blame provenance, no supersede semantics, and no authority-ordered store. Reported loaded TCO runs to six figures. |
| Dust | MIT-licensed, self-hostable agent platform with company knowledge | The closest commercial analogue, and proof the architecture is not exotic. A plausible buy if you want the shape in weeks; this guide is the owned, auditable, supersede-native version. |
| Microsoft 365 Copilot | Graph-grounded assistant with connectors and permission trimming | Wins outright if roughly 90% of your knowledge already lives in SharePoint, Teams, and Exchange, conditioned on E5 plus Purview DLP. It inherits ACL trimming you already paid for; it does not compile authored decisions. |
| Amazon Bedrock AgentCore Memory | Managed short and long-term agent memory with namespaces | The AWS-native path in the guide builds on it. Note it lacks supersede-not-delete, uses async extraction with no read-your-writes, and has hard namespace and region limits. |
| Letta (formerly MemGPT) | Stateful-agent runtime; shipped git-backed Markdown memory in early 2026 | The closest philosophical cousin, and cited in the guide as convergent validation rather than a competitor to dismiss. It is per-agent memory; this is org-shared memory with ReBAC authority. |
| mem0 / OpenMemory | Drop-in memory API with hybrid retrieval | Simpler and more mature at per-user memory. Its update semantics mutate in place, which the guide argues against for a shared corpus. |
| Zep / Graphiti | Temporal knowledge graph with a bi-temporal, invalidate-not-delete model | The design the guide's supersession model most resembles. Adopt its bi-temporal discipline; the guide adds ReBAC, the retention machine, and the cache-not-truth line. |
| Amazon Q Business / Kendra | Managed enterprise RAG assistants | Named in the guide's anti-patterns as the cautionary tale: both closed to new customers in 2026. The plain-Markdown-in-git substrate is the hedge against exactly that rug-pull. |
| Devin, Cursor for Teams, Copilot enterprise | Team coding agents with shared rules and dispatch | The worker-dispatch and shared-rules ideas, productized. None is a permission-aware shared memory with an authority-ordered store. |
The guide's own competitive verdict: the two things vendors do better (identity resolution, connectors) are the two things you can rent, and the two things no vendor sells (a reviewable diff of what the org believes and when it changed, and the curation of decisions rather than crawled documents) are what the build delivers. So the recommendation is rarely build-everything and rarely buy-everything. It is: own the knowledge substrate and the compaction policy, rent the model, the identity provider, and the connectors, and keep a clean line between truth and cache so every rented piece stays swappable.
Is this just enterprise RAG? Retrieval is one part. The parts that are not RAG are the write side (a human-merge boundary between untrusted input and canon, deterministic dedup, and supersede-not-delete so the base does not rot) and the governance side (per-subject erasure, legal hold, and a WORM audit trail). A retrieve-and-stuff pipeline over your wiki has none of those.
Why not just buy Glean or Copilot? Sometimes you should, and the guide says when: if your knowledge already lives in one SaaS estate, buying inherits permission trimming you cannot easily rebuild. What you cannot buy is a version-controlled record of what the organization decided and when it changed, with git blame, revert, and a supersede history. If that auditability is the point, you build the substrate and rent the rest.
Our agent could surface HR or compensation data to the wrong person. How is that prevented? That is the central threat, and the guide treats it as one. Retrieval runs as the asking human, not a shared service account; permissions filter the candidate set before the model sees anything, never the generated answer; group membership is resolved server-side so it does not break for senior staff above the identity-provider overage cliff; and the authorization check is forced-fresh so a just-revoked access does not linger for a cache TTL. A nightly cross-tenant canary proves it still holds.
One employee could poison the shared memory for everyone. Also the right thing to worry about, and worse than a prompt injection because it persists. The defense is structural: untrusted content is write-confined to staging with no automated path to canon, the boundary into canon is a human merge, every claim carries provenance, and because the index is a rebuildable cache over version-controlled Markdown, a confirmed poisoning is a git revert plus a reindex, with citation-level logs to scope who was affected.
How does GDPR erasure work if you never delete? Supersede-not-delete is for institutional knowledge. Personal data lives in a separate retention class, encrypted per-subject at write time, so erasure destroys one key and rebuilds the index. A legal-hold table is checked before every delete, and a tombstone list is re-applied after every restore so a point-in-time recovery cannot resurrect erased data.
Does the always-on, shared design cost a fortune? Most scheduled work is deterministic and spends zero model tokens, bulk work runs on a zero-priced local tier, and a gateway enforces per-team budgets in plain code before any session starts. The real capacity constraint is usually the provider's org-level rate limit, not your bill, which is why one runaway fan-out is a bigger risk than steady usage and why the guide caps it.
Isn't this lock-in? Less than the alternatives. The knowledge is plain Markdown in git you can walk away with, the model sits behind aliases in one config across vendors, the harness is a swappable seam, and the whole design keeps a clean line between truth and rebuildable cache so every high-churn piece (the MCP wire format, the embedding model, the memory vendor) sits in a replaceable position.
Relevant if you are searching for any of these: organization-wide AI memory, shared agent memory, enterprise agent memory, permission-aware RAG, ACL-aware retrieval, multi-tenant agent platform, Model Context Protocol (MCP), remote MCP server, ReBAC, Zanzibar, OpenFGA, SpiceDB, OIDC, SCIM, agent identity, on-behalf-of delegation, RFC 8693, retrieval-augmented generation, hybrid search, BM25 plus vector, reciprocal rank fusion, pgvector, contextual retrieval, cross-encoder reranking, temporal knowledge graph, supersede-not-delete, bi-temporal memory, context compaction, context rot, degradation avoidance, prompt caching, prompt-injection defense, memory poisoning, agent security, Rule of Two, budget governor, LLM cost attribution, chargeback, GDPR right to erasure, crypto-shredding, legal hold, WORM audit, SOC 2, ISO 42001, EU AI Act, model risk management, SR 11-7, knowledge management, institutional memory. It is also an org-scale alternative or complement to Glean, Dust, Microsoft 365 Copilot, Amazon Q Business, Amazon Bedrock AgentCore, Letta, mem0, Zep, and Graphiti, and the multi-user sibling of RAG-OS.
Issues and pull requests are welcome. The most useful contributions: a worked example of one milestone on a specific stack (name the cloud, the identity provider, the authorization store, and the model vendor, and show the proof), a decision fork the guide missed written as a question with two to four options, an org-scale failure mode for the anti-patterns section with the design rule that prevents it, or a correction with a primary source. See CONTRIBUTING.md.
MIT. Use it, fork it, build on it, sell what you build with it.