What is a company brain?
A company brain is a queryable model of how an organisation actually fits together: which systems depend on which, which components are load-bearing, what a proposed change would reach, and where today’s state has drifted from the last known good one. The defining property is that it is derived from the organisation’s own material rather than authored by hand, so it does not go stale the moment somebody stops maintaining it.
A company brain is a deterministic context layer for an organisation
The category name for this is a deterministic context layer. Deterministic is the load-bearing word. If you ask the same question of the same material twice and get two different answers, you do not have a model of your organisation, you have a search box with good manners. A company brain is worth the name only if the derivation can be re-run and the result compared.
That is why every answer carries a receipt: the structural fingerprint of the build it came from, which anyone can recompute from the same bytes. We publish those fingerprints and the measurements behind them on the validation page, including the cases where the guarantee is narrower than the headline.
What it is not
Three things get called a company brain and are not one. Saying which is which is more useful than a definition.
Not a wiki. A wiki is authored, so it is exactly as current as the last person who remembered to update it, and it has no way of knowing what it is missing. That is not a criticism of wikis; it is a description of what authoring costs. A derived model has the opposite failure mode: it can only tell you about material it can read.
Not a data catalog. A catalog inventories datasets and what they mean. A company brain models the dependency structure underneath and answers questions about consequence. If this schema changes, what breaks. The two sit at different layers and neither replaces the other, which is a longer argument we make in context layer vs semantic layer.
Not a retrieval index. Embedding your documents and searching them finds passages that resemble the question. That is genuinely useful and it is not structure: two similar questions can return different context, and neither answer can be reproduced on demand. A company brain returns named nodes and real edges, and the same question returns the same answer.
What is actually in one today
This is the part worth being exact about, because the vague version of this page would claim we understand your entire company and you would find out otherwise.
Code is the deepest layer. JavaScript, TypeScript, Python and Rust are resolved structurally, meaning real imports and real call relationships rather than text similarity. Other languages are indexed as content, so they appear but do not contribute dependency edges.
Database schemas come in from a SQL DDL file, which is how the brain learns that a column is referenced by three services rather than one.
Documents are extracted deterministically, including PDF and DOCX. One honest caveat: only Markdown is currently sectioned into parts, so a two hundred page PDF enters as a single node rather than as its chapters. It is present and queryable, but it is not yet granular. Spreadsheet ingest is built and test-locked but is not a shipped feature, so do not plan around it.
Read that list as the floor rather than the ceiling of the idea. It is also the reason the first useful company brain in most organisations is built from the codebase and the schemas around it, where the dependency structure is real and machine-readable today.
What you can ask it
The questions a company brain answers are the ones that need consequence rather than recall. What does a change to this file or this column reach. Which components are load-bearing enough that breaking them breaks everything downstream. Where has the system drifted from its last known good state. Which parts look small and reach far, which is the shape most incidents have in hindsight.
Those answers are available to people in a terminal and to AI agents over the Model Context Protocol, from the same brain, which is the point. An agent that can query structure stops guessing about consequence. The connection details are on the API and MCP page.
How you get one
You point it at the systems you already have. There is no modelling project, no ontology workshop, and nothing to keep manually in sync, because a derived model has no authoring step to fall behind on. In practice the first brain is one repository and takes minutes; the first genuinely useful unit is one team.
The organisation-scale version, set up and tuned for you rather than self-served, is Conductor. If you want the plain-language walk from a personal second brain up through a team brain to this, that ladder is on the Spiderbrain explainer.
Questions people ask
What is a company brain?
A company brain is a queryable model of how an organisation fits together: which systems depend on which, which files and schemas are load-bearing, what a proposed change would reach, and where the current state has drifted from the last known good one. The defining property is that it is derived from the organisation’s own material rather than written down by hand, so it does not go stale the moment someone stops maintaining it.
How is a company brain different from a wiki?
A wiki is authored, so it is only as current as the last person who remembered to update it, and it has no way to know what it is missing. A company brain is derived, so it reflects the state of the systems it was built from and can say what a change would touch. A wiki holds what someone chose to write; a company brain holds what is actually connected.
Is a company brain the same as a data catalog?
No. A data catalog inventories datasets and their meaning, which is genuinely useful and mostly authored. A company brain models the dependency structure underneath and answers questions about consequence: if this changes, what breaks. The two are complementary, and neither replaces the other.
Is a company brain just RAG over company documents?
No. A retrieval index finds passages that resemble your question, which is why two similar questions can return different context and neither answer is reproducible. A company brain returns structure: named nodes, real dependency edges, and a fingerprint you can recompute to prove the same input produced the same answer.
What goes into a company brain today?
Source code with JavaScript, TypeScript, Python and Rust resolved structurally; database schemas read from a SQL DDL file; and documents, where PDF and DOCX are extracted deterministically while Markdown is additionally sectioned into parts. Everything else in a repository is indexed as content rather than parsed into structure. Spreadsheet ingest is built and test-locked but is not a shipped feature.
How do you build a company brain?
You point it at the systems you already have. There is no modelling project, no ontology workshop and nothing to keep manually in sync, because the structure is derived rather than authored. The practical starting point is one repository, which takes minutes, and the useful unit after that is one team.
Every capability claim above is bounded on purpose. The languages, the substrate and the determinism guarantee are stated as they are, including where they are narrower than a marketing page would prefer, because the whole proposition is answers you can check. If you find a claim here that the product does not honour, that is a defect and we want to know.