--- title: "How to build a company brain" description: "To build a company brain, connect the tools where work happens, resolve identities, track facts as they change, and answer with evidence. The architecture." canonical: https://past.dev/guides/build-a-company-brain last-updated: 2026-09-03 --- # How to build a company brain Source: https://past.dev/guides/build-a-company-brain To build a company brain, ingest the records where work actually happens (email, meetings, tickets, chat) with their original timestamps, resolve the people and projects they mention into single identities, store facts so changes supersede rather than overwrite, and answer questions with dated evidence, scoped to what each asker may see. The model layer is interchangeable; the brain is the memory underneath it, and each of those four properties fails independently when skipped. ## What a company brain is A company brain is shared memory over an organization's own records: ask it a question and it answers from what the company actually said and did, with the sources behind the answer. This page is the build guide for it. The distinguishing property against a document wiki is that a brain tracks the current state of changing facts rather than storing pages someone must update. ## The four requirements, and how each fails - **Ingestion from real sources, at their real times.** The brain is only as good as what reaches it, and backfilled history must carry the source's own dates. Importing two years of email stamped with the import date collapses every timeline; [event time vs ingestion time](/guides/event-time-vs-ingestion-time) covers the trap. - **One identity per person and project.** The same account manager appears as a CRM row, an email address, and a chat handle. Without [entity resolution](/guides/entity-resolution) the brain holds three strangers, and questions answer with a third of the history. - **Facts that change must supersede.** Budgets move, owners rotate, renewals slip. Overwriting destroys the audit trail; appending without windows makes current and stale indistinguishable. [Facts that change over time](/guides/facts-that-change-over-time) is the hub for the mechanics. - **Answers need evidence and a way to say no.** A brain that guesses is a liability. Recall should return dated, source-attributed evidence with an explicit [evidence status](/glossary/evidence-status), including the case where the records cannot answer; see [abstention](/glossary/abstention). ## The architecture, in two calls The write path takes each record with its own timestamp; extraction, entity resolution, and temporal storage happen behind it. The read path takes a question and returns evidence. ```ingestarecordaskaquestion POST /api/v1/ingest { "content": "Meeting note, 2026-09-01: Meridian renewal moved to Q1, Dana owns it.", "timestamp": "2026-09-01T15:00:00Z" } POST /api/v1/recall { "query": "Who owns the Meridian renewal?" } ``` The response carries ranked evidence with dates and sources, and one of four status values (Supported, Conflicted, NoKnownSupport, UnknownBecauseDegraded), so the application can cite, surface a disagreement, or say the records do not answer. Poll the ingestion until it reports settled before expecting recall to reflect it; the [quickstart](/docs/memory-api/quickstart) walks all four endpoints. ## What to connect first 1. **Meetings and email first.** They carry the densest decision history and the most identity variety, which exercises entity resolution early, while the corpus is small enough to inspect. 2. **Backfill with original timestamps, then verify.** Ask a date question and check the answer cites source dates rather than the import date. 3. **Add tickets and chat once identities hold.** Cross-source questions ("what did Dana report this quarter") only work when the joins do. 4. **Decide retention before scale.** Which classes expire, which supersede, who can trigger erasure: [data retention](/guides/ai-data-retention) and [the forgetting policy](/guides/forgetting-policy) are cheaper to set at 10,000 records than at 10 million. ## Permissions and audit are part of the build A brain that shows everyone everything is unshippable in a real company. Recall must be scoped to audiences, so what a caller can retrieve is bounded by what that caller may see, and the scoping has to hold at the memory layer rather than in prompt instructions. The second obligation arrives with the first executive question: why did it answer that? Storing the recall evidence behind consequential answers gives the brain an [audit trail](/guides/ai-audit-trail), and erasure requests follow the same mechanics as [the right to be forgotten](/guides/gdpr-memory-deletion). ## Evaluating whether the brain works Test it the way you would test any memory system, on your own records: change a fact and ask for the current and previous values with dates; backfill and ask a date question; refer to one person three ways and ask a question requiring the join; ask something the records cannot answer and expect the explicit status. The protocol is written out in [how to choose a memory system](/guides/choose-memory-system), and the [benchmark methodology](/benchmarks/methodology) documents how we evaluate the same behaviors. past.dev is this architecture as an API: managed, or self-hosted so the brain lives in your own Postgres. ## Frequently asked questions ### What is the difference between a company brain and a knowledge base? A knowledge base stores documents people write and must maintain. A company brain ingests the records work already produces and tracks the current state of changing facts, answering with dated evidence rather than with a page that may be stale. ### Do I need a knowledge graph to build a company brain? You need the properties a temporal knowledge graph provides: entities resolved across sources, facts with validity periods, and links from each fact to its evidence. Whether you assemble that yourself or use a memory API is the build-versus-buy decision. ### Can a company brain respect permissions? Yes, if recall is scoped by audience at the memory layer: the store can hold everything while each query is filtered to what the asking person or agent is allowed to see. Scoping enforced only in prompts does not survive a determined question. ### How long does it take to build a company brain? With a memory API, the first working version is the two calls plus a backfill: days, dominated by connecting sources. Building the layer itself from scratch means solving entity resolution, supersession, and evidence tracking before the first useful answer. ## Related - [How to choose a memory system](https://past.dev/guides/choose-memory-system) - [Building an assistant that remembers](https://past.dev/guides/ai-assistant-that-remembers) - [Entity resolution](https://past.dev/guides/entity-resolution) - [Facts that change over time](https://past.dev/guides/facts-that-change-over-time) - [Quickstart](https://past.dev/docs/memory-api/quickstart)