Every company brain has four operating loops

Across the architectures in Slite’s study - open source and commercial, file-based and graph-based, built and bought - the same four jobs recur. I would name them capture, memory, reconciliation, and delivery.

1. Capture. The brain learns from scheduled syncs, live events, agent-written summaries, or retrieval from a source at the moment of a question. The choice is a trade-off among freshness, noise, cost, and whether the original system should remain the only copy.

2. Memory. Durable context can live in plain files, owned documents, a vector index, a knowledge graph, or a deliberate combination. Richer storage is not automatically better. It earns its complexity only when the questions require relationships, history, or scale that simpler forms cannot answer. Long context is a delivery buffer, not the memory itself; position and distractors still change what a model can use.

3. Reconciliation. Consolidation, expiry, drift detection, contradiction checks, and human review keep new knowledge from becoming new clutter. This is the loop most weekend builds omit and the one production systems spend their lives improving.

4. Delivery. People need cited answers in search or chat. Agents need the same context through an API or MCP endpoint. A dedicated workflow may deserve its own interface, but every door should lead back to the same permission and provenance rules.

A reviewed folder of Markdown can therefore be more of a company brain than an impressive context graph nobody maintains. Architecture is the means. Trustworthy recall is the product.

Trust is the product

The strongest result in Slite’s survey was not demand for smarter retrieval. Accuracy was the top adoption concern at 77 percent. When respondents were asked what would make them trust documentation, 78 percent chose a named human owner, 63 percent chose a link to a live source of truth, and 56 percent chose recency. In an environment where plausible prose is nearly free, authority becomes more valuable, not less.

That changes the unit of design. Do not return an answer alone. Return an answer receipt: the sources it used, who owns the underlying rule, when each source was retrieved and last verified, which audience or situation the answer applies to, and whether credible sources disagree. Enforce access in retrieval on every query; NIST’s zero-trust model is explicit about least-privilege, per-request decisions. A prompt that tells the model to keep a secret is not a permission system.

The brain also needs a legitimate refusal. If the relevant source is stale, two owners conflict, or a required system is unavailable, the safe answer is “I don’t know yet” plus a route to the person who can resolve it. A brain that never abstains is a content generator wearing a governance costume.

This matters more for agents than for people. A person who finds an odd policy page may ask a colleague before acting. An agent can turn the same page into a proposal, customer reply, or automated decision at machine frequency. Stale context moves from inconvenience to executable risk.

A company brain can poison itself

The dangerous mistake is not merely storing something false. It is laundering one false assertion through enough generated documents that repetition begins to look like consensus. A confident meeting note becomes an AI summary, the summary becomes a planning document, and three agents cite the plan. The system now sees five documents. It still has one source.

Treat memory as an evidence graph, not a truth database. Every durable claim should keep its original source, accountable owner, scope, verification time and derivation history. The W3C provenance standard provides a useful vocabulary for entities, activities, agents and “was derived from” relationships. The implementation can be much simpler than RDF; the non-negotiable property is that ancestry survives summarisation.

New assertions should enter as provisional, not true. They can become corroborated, disputed, superseded or expired. A generated summary cannot independently corroborate the note it summarised, and ten descendants of one claim still count as one line of evidence. Retrieval should show conflicting claims together instead of silently selecting whichever wording appears most often.

The same opening can be exploited deliberately. In PoisonedRAG, researchers induced chosen answers by injecting only five malicious texts per target question into databases containing millions of documents, reaching a 90 percent attack success rate in their experimental settings. That is an adversarial result, not a measured rate for company knowledge systems, but it proves that “the corpus is internal” is not a security boundary.

Put controls on the write path, not only the answer. Separate primary evidence from generated material; require a human gate before high-impact claims can influence pricing, legal policy, security procedures or customer commitments; limit automated actions when evidence is provisional; and make corrections travel downstream. When a source is superseded, every derived summary and answer should be marked for regeneration or review.

NIST calls confidently presented false generated content confabulation and warns that fabricated explanations or citations can deepen inappropriate trust. A safe company brain therefore answers with the disagreement intact: “A 2025 retrospective attributed churn to onboarding; it was one team’s interpretation, is not independently validated, and conflicts with three later customer interviews.” Compression must not erase epistemic status.

Capture at the place of work

The old knowledge-base bargain was that everyone would stop after doing the work and document it somewhere else. Reality declined. In Slite’s survey, 56 percent said company knowledge lived in Slack or Teams, 65 percent named shared drives, and 22 percent named email, even though most respondents also had a dedicated knowledge base. The stack does not consolidate as a company grows. It accumulates.

So do not make “remember to feed the brain” a new job. Capture should ride along with work that already happens: approve a pricing exception, close an incident, change a roadmap commitment, decide why a candidate was rejected, revise the refund policy. Those moments can emit a small structured record or open a draft for review.

The goal is not to preserve every transcript. Keep the decision, its owner, the constraint that shaped it, the evidence it relied on, the scope in which it applies, and the outcome when you learn one. Raw conversation remains available as evidence; the durable layer carries the part the next person or agent will actually need.

Start with one costly question, not every tool

The fastest way to build a maintenance problem is to connect every source before naming a use case. Start with one question people ask repeatedly, where a wrong answer has a visible cost and one person can judge whether the result is correct. Good candidates include “What can sales promise this customer?”, “Which refund rule applies here?”, or “Why did we reject this architecture last time?”

Week 1: collect twenty real versions of the question and the evidence a trusted employee uses to answer them. That becomes the first evaluation set and exposes the sources you actually need. Retrieval research increasingly points the same way: benchmarks built around representative private queries reveal failures that generic public sets miss.

Week 2: connect only those sources. Return draft answers with citations, an owner, a freshness signal, and an explicit abstention path. Do not let the system write back to durable knowledge yet.

Week 3: add a review queue. Every correction should become structured feedback: wrong source, stale fact, missing exception, permission failure, or unanswered question. The queue is not temporary scaffolding. It is how the brain shows where its model of the company is weak.

Week 4: measure the answer rate, correction rate, stale-source rate, permission failures, and how many colleague interruptions the workflow replaced. If the question is not becoming faster and more reliable, do not add five more integrations. Fix the loop or stop.

Build or buy the maintenance burden

The real build-versus-buy question is not whether your team can wire a model to search. It is whether you want to own ingestion, retrieval, evaluation, permissions, cost controls, and governance indefinitely while the underlying techniques keep changing.

Build when the brain is strategically differentiating, the access model is unusual, context must remain in infrastructure you control, and a named internal team can treat the system as a permanent product. Buy when the sources and permission patterns are conventional and a vendor can carry the undifferentiated upkeep. For a very small technical team, reviewed plain files in version control remain a strong starting point because people can inspect every change and leave without exporting a proprietary graph.

Whichever path you choose, protect context sovereignty. You should be able to export the durable knowledge, preserve links to original sources, enforce source-system permissions, inspect changes, and change the model or delivery surface without rebuilding the company’s memory. The brain sits above your tools and models; it should not quietly become captive to either.

The Monday-morning version is intentionally small: one recurring question, one source set, one named editor, one review queue, and one place to ask. Earn the second workflow with evidence from the first. A useful company brain starts as a disciplined editorial operation with retrieval attached, then becomes infrastructure only after the maintenance loop survives contact with real work.

Source note: this article adapts the findings and architecture described in Slite’s 2026 survey of 149 AI-forward teams and its full interactive ebook into an implementation playbook for small and mid-sized teams.