Team KMS

A team KMS is the same eight principles, applied across a multi-person trust boundary, with three things added: role-based access, institutional-knowledge extraction, and a warehouse layer for the structured tail.

What this tier is

A knowledge layer attached to an organisation. It captures customer touchpoints, internal decisions, project state, sales motion, and the soft knowledge that lives in heads. It compiles all of that into entities (customers, deals, decisions, processes) and surfaces it where the next person needs it — in a doc, in a Slack thread, in a sales call.

Trust is partitioned. Different roles see different slices. Compiled knowledge is cited by other people, so the bar for accuracy is higher than personal.

Which principles it uses

All eight, with these adjustments:

• Route, Don't Organize — same, but the routing table has to be ratified by the org, not invented per-user.
• Separate State / Knowledge / Interface — gains a warehouse layer. Tickets, events, customer records live in structured stores; the knowledge layer pulls from them but does not own them.
• Automatic Compilation — runs continuously, but compiled artifacts that get cited externally need a review/promote step.
• Bouncer-Promoter — strict; a team can't tolerate signal pollution because every reader pays the cost.
• Design for Neglect — load-bearing in a different way: the system has to keep working when the person who set it up leaves.
• Entity Context — central. Customers, deals, employees, processes are first-class entities with stable schemas.
• Ripple & Contradiction — the highest-value behaviour at this scale; surfacing "this customer's stated need contradicts the contract" is what makes the system pay for itself.
• Hybrid Authorship — the line is much more conservative than personal. Compiled content that other people cite must be either explicitly marked or human-promoted before it's referenced.

Tier-specific divergences

• Role-based permissions. Knowledge access is partitioned by role. The agent enforces partitioning at retrieval time, not at the storage layer (storage stays uniform; the agent filters).
• Institutional knowledge extraction. A huge portion of team knowledge lives in heads. The KMS has to actively extract it — meeting transcripts, post-call summaries, "tell me how you handled X" interviews — and convert unwritten know-how into compiled knowledge. This is not optional.
• Warehouse intelligence. Structured data (CRM, support tickets, billing) lives in a warehouse. The KMS reads from the warehouse, joins it with knowledge, and produces synthesis (e.g. "this customer has filed three tickets in two weeks AND we have a note from the account owner that they're considering churn"). The pattern is zero-copy of records, full-fidelity of meaning: the KMS stores extracted facts with citations back to the underlying records, not copies of the records themselves.
• Tenant separation. Multi-tenant orgs need clean separation between tenant data and shared knowledge.
• Audit + provenance. Every compiled claim carries provenance — which sources, which timestamp, which agent run. Required for trust and for compliance.

The shape of the system

Four layers, stacked. Lower layers are plumbing; upper layers are where the knowledge lives.

04Interfaces

Web UI · CLI · MCP server (for your AI agents) · API

↑

03Knowledge

Concepts · Decisions · Playbooks · Customer dossiers · Maps · Index · Audit log

↑

02Compilation

Bouncer (quality gate) · Promoter (router) · Linker (cross-references) · Lint (health checks)

↑

01Connectors

Email · Calendar · Transcripts · Chat · Files · CRM · Warehouse · Runbooks · Ticketing

• Connectors read from source systems. Read-only by default; the KMS does not own the records.
• Compilation is the pipeline from automatic-compilation — bouncer, promoter, linker, lint — applied continuously.
• Knowledge is the compiled layer: entities, dossiers, concepts, decisions, with provenance back to Layer 1.
• Interfaces are how humans and agents query it — including an MCP server so internal AI tools read from the same source of truth.

What it is NOT

• A wiki. Wikis are human-authored and hand-organised; a team KMS is mostly compiled.
• A search-over-everything. Search returns lists; a team KMS returns synthesised answers with provenance.
• A replacement for Salesforce / HubSpot / Linear. The warehouse layer pulls from those; the KMS sits above them.

The reference implementation

We've built a team KMS for client work on the same eight principles — with role-based permissions, warehouse joins, and a much stricter stance on where the hybrid-authorship line sits.