Your company brain — read by every agent.

What it is

A self-learning brain for your company. Stable Baseline reads every document, diagram, plan, and improvement you write — extracts the entities and the relationships between them, clusters them into themes, and writes wiki pages summarising each theme. The result is a single graph that any MCP-connected agent — public (Claude, ChatGPT, Gemini) or internal — can query directly. No skill files. No per-tool context sync. No ETL.

Underneath, the brain still ships everything Stable Baseline's full-text + vector search has always shipped — those layers stay live and untouched. The Company Brain adds the typed-entity, community, and wiki layers on top, plus a retrieval surface that reaches questions a bag-of-chunks index can't answer.

And — just as important — the brain teaches connected agents when to say “I don't know”. If the graph has no relevant entities for a question, the retrieval surface returns that absence cleanly instead of forcing a confident-but-wrong answer out of the model. Less guessing. More grounding.

One brain per scope

The brain is built per project within a workspace. That gives you control over how you segment company knowledge:

• One brain per company. Run a single workspace + project for the whole company. Every team feeds it; every agent reads from it. Best for small to mid-sized organisations.
• One brain per department. Spin up a workspace per function — HR, Finance, Operations, Engineering, Sales, Legal — each with its own brain. Departments stay isolated by default, sharable on demand.
• One brain per project. Inside a workspace, each project gets its own scoped brain. Great for confidential projects (M&A, restructure) where even other teammates in the same workspace shouldn't see the content.
• Mixed. The four-gate scope model lets you mix freely — a top-level “company brain” project plus a confidential side project, both in the same workspace, with different agents authorised differently.

Why it matters

Search alone struggles the moment your question requires connecting ideas that live in different documents — and that's exactly when humans tend to ask for help. The Company Brain is built for those moments. Concrete ways teams use it:

The KG Explorer

Open the Explorer from any project that has the Knowledge Graph enabled. It renders every entity in scope as a node, every typed relationship as an edge, and the communities discovered by clustering as soft coloured zones. Drag to pan, scroll to zoom, and click any node to focus on its neighbourhood.

Expand

Search vs Knowledge Graph

Both retrieval modes coexist on Stable Baseline — the graph never replaces search. Use whichever fits the question. As a rough heuristic:

Five layers, one graph

The Knowledge Graph is a five-layer system that sits on top of your existing chunked + embedded content. Each layer adds capability the layer below couldn't serve on its own.

• Layer 1 · Sources & chunks. Every document, diagram, improvement, plan, and task is split into chunks. This layer is what powers the existing full-text + vector search.
• Layer 2 · Entities & edges. An extraction agent reads each chunk and emits typed entities (e.g. OWASP ASVS, checkout flow, Stripe webhook) and the relationships between them. Both entities and relations are open-vocabulary — the extractor invents the types as it reads, scoped to your org.
• Layer 3 · Communities. A Louvain-style clustering algorithm groups densely-connected entities into communities. Each community represents a coherent area of your workspace — “Authentication”, “Compliance scans”, “Billing & credits”.
• Layer 4 · Curated wikis. An LLM writes a short CDMD wiki page for each community summarising its theme. New teammates can read the wiki page for “what is this project about?” instead of grep-walking dozens of docs.
• Layer 5 · Retrieval & agents. The chat surface and MCP tools combine all four layers into a single retrieval pipeline that supports four modes: local (chunk-centric), global (community summaries + wikis), graph (entity-neighbourhood walk), and path (shortest path between two entities).

Four-gate scope model

Knowledge Graph never opts you in by default. Every code path — the UI, every edge function, every MCP tool — checks four gates in order. Any single “no” is a hard stop.

• Tier entitlement. Your subscription tier must include the feature. Free and Pro plans are blocked at this gate.
• Org toggle. An org admin must turn the feature on for the organisation in settings.
• Scope walk. Each workspace and project is independently opted in. The scope is walked bottom-up: document → folder → project → workspace → org. The first non-inherit setting wins. Default is off.
• Storage cap. Each plan has a per-org KG storage cap. Hitting it pauses new builds (it never deletes existing data) and surfaces a warning banner in the UI.

MCP tools

Any MCP-connected agent (Claude Code, Cursor, ChatGPT, etc.) gains four new tools once Knowledge Graph is enabled for the project:

• kg_search — unified retrieval across all four modes. The default mode is local for chunk retrieval; pass mode: "global" for community summaries, mode: "graph" for an entity neighbourhood, or mode: "path" for the shortest path between two entities.
• kg_get_entity — fetch the full record for a single entity, including its types, aliases, and outgoing/incoming edges.
• kg_related_documents — list documents connected to a given entity, ranked by edge weight.
• kg_scope_status — check whether a target (workspace, project, folder, document) is currently in scope, with the reason if it's not.

Enabling the Knowledge Graph

On the Enterprise plan, follow these steps:

• Open Org settings → Features and enable Knowledge Graph at the organisation level. (Requires owner / admin role.)
• In each workspace, open Workspace settings → Knowledge Graph and flip the workspace into scope.
• For each project, leave the default (inherit → on once the workspace is on) or override per-project under Project settings → Knowledge Graph.
• Open the project's Knowledge Graph tab and click Build. The first build runs the extraction + normalization + clustering + wiki pipeline; subsequent edits trigger incremental updates automatically.

Security model

• Tenant isolation. Every KG row is org-scoped at the database layer. The same isolation that protects your documents protects your graph.
• No content filtering. Once a document is in scope, every chunk contributes equally — no system-side “skip this” rule. Curators have full control via scope.
• Zero-retention model providers. The agents that perform extraction, normalization, and wiki authoring run through ZDR-contracted model providers. Your content is never used to train a model.