The most useful lesson in Cerebras’s account of its internal knowledge base is not that every company should copy its implementation. It is that an enterprise knowledge system looks much more like a data platform than a chatbot.
Cerebras describes a system used for more than 15,000 questions a day by people, automations, and agents. Underneath the interface is a collection pipeline that feeds a query-ready Postgres store and several retrieval methods. Authorization is explicit and scoped to projects. Auditing records access, while a planner assembles evidence for a final model.
That architecture points toward a broader shift: the warehouse and surrounding data platform are becoming the company brain, while agents and applications become new ways to use what the company knows.
The pattern is bigger than RAG
The Cerebras system starts by meeting information where it already lives. Slack and code repositories remain useful for their original jobs. The same is true of documents, issue trackers, and custom databases. Connectors extract from those systems and normalize their content into a shared query interface.
At the center is a Postgres table containing embeddings, raw summaries, and source metadata. Slack threads are stored as complete conversations rather than isolated messages, while code repositories are split along language-aware structural lines and updated incrementally.
Retrieval is deliberately hybrid:
- full-text search catches exact error strings, flags, and host names;
- vector search connects paraphrases that share meaning but not vocabulary;
- inverse document frequency separates rare technical signals from filler;
- age decay gives newer operational evidence more weight;
- model-generated thread summaries normalize noisy conversations; and
- message bursts preserve useful details that disappear from a thread-level summary.
No individual technique is treated as sufficient. The system combines ranked lists with reciprocal rank fusion and deduplicates sources. It also limits repeated results from the same file. After reranking candidates against the original question, it restores adjacent context before synthesis.
The agent layer comes last. A lightweight planner selects retrieval tools, an executor fans them out in parallel, and a final model synthesizes the returned evidence. MCP clients can call the retrieval primitives directly, while the web application runs the whole planner, executor, and synthesis sequence.
This is a production data system with an agent interface, not an agent demo with a vector database attached.
Why more teams will build this way
As agents move into engineering and customer support, they need more than access to documents. The same becomes true in finance and operations. Agents need a current view of business entities and their relationships. They also need agreed definitions, access rules, and historical state.
The company already has most of that context, but it is split across two broad forms:
- structured business state in warehouses and dbt models, including marts and metric definitions;
- unstructured evidence from the systems where work is discussed and documented.
An agent can search each source independently, but useful company context often depends on the relationships among them. An account-health model is more useful when it can be related to support incidents. A deployment question is easier to answer when repository state, runbooks, and recent engineering discussions can be retrieved together.
This creates a durable data problem. Teams must collect evidence with its provenance, resolve identities, and model relationships. They must also test transformations and manage freshness. Then they must apply access rules and deliver the result to many consumers.
Those are already data-platform responsibilities.
The existing data team can build the foundation
A recent post by Madhu Guru argues that enterprises struggle to move beyond basic chatbots because the talent needed to build harnesses and evaluations is scarce. That shortage matters if a company treats the knowledge system as a completely new AI platform requiring an entirely new team.
Most companies do not need to start there. Their analytics and data engineers already have many of the required operating skills:
| Existing capability | Knowledge-system responsibility |
|---|---|
| ELT and source connectors | Incrementally collect source content and application records |
| Warehouse and lakehouse modeling | Resolve entities, preserve history, and relate evidence to business state |
| dbt projects | Build tested models with documented definitions and lineage |
| Airflow, Dagster, or dbt Cloud | Schedule data preparation and index refresh pipelines |
| Postgres, warehouse search, or a vector store | Serve lexical, structured, and semantic retrieval |
| Data quality practices | Detect incomplete, stale, or malformed data products |
| BI usage analysis | Identify recurring questions that should become reusable data tools |
The new work is real. Teams need extraction logic for conversational sources, along with sound chunking and distillation strategies. They also need embedding jobs and retrieval evaluation. Permission mapping and online feedback close the loop. However, none of this requires abandoning the existing stack or creating a new organizational silo.
Data teams can own the collection, modeling, and evidence layer. Domain experts can judge whether the retrieved evidence reflects how the business actually works. AI and application engineers can own the planner and tool selection. They can also own synthesis and the user experience.
The division of labor is more practical than waiting for one person who is simultaneously an expert in warehouse architecture and information retrieval. That person would also need to understand agent evaluation and application security, then apply all of it to every business domain.
A practical stack
A company can begin with the systems it already operates:
Collaboration systems · Business applications · Operational databases
↓
Connectors and incremental ingestion
↓
Warehouse or lakehouse raw evidence and business state
↓
dbt models · entity graph · summaries with provenance
↓
Structured data · text and vector indexes
↓
Tested retrieval operations and approved data lookups
↓
Qry publication and serving layer
↓
REST endpoints · MCP tools · applications
↓
Agents and human workflowsThe physical systems can vary. A team might keep structured business models in Snowflake, BigQuery, or Databricks. It might use Postgres for full-text and vector retrieval, while original evidence remains in object storage. Another team may use warehouse-native vector search. The important design choice is not one database; it is a shared model for identity and provenance. That model should also define freshness and access. Publication and use build on top of those decisions.
Start with one source and one recurring question. Preserve the source record and build a normalized retrieval unit. Base the evaluation set on real questions and expected evidence. Add freshness expectations and permission cases, then measure retrieval relevance before answer fluency.
Then observe production behavior:
- Which questions return no useful evidence?
- Which sources dominate results?
- How often does stale evidence outrank current evidence?
- Which questions recur often enough to become direct tools?
- Which tool calls are slow, expensive, or unused?
- Which answers are corrected by domain experts?
This turns evaluation into normal data-product work rather than a one-time model benchmark.
Where Qry fits
Qry does not replace the collection or modeling stack. It also does not replace the retrieval engine or agent runtime.
Qry sits after trusted data and retrieval outputs have been built and before production software consumes them. An analytics engineer can declare an approved dbt model as an endpoint, publish a verified serving artifact from CI, and give downstream systems a scoped, read-only interface.
That separation matters because collection and retrieval are compute-heavy, variable processes. Production consumers need a stable release with defined inputs, response limits, and authentication. It also needs last-known-good behavior and request logs. A recurring question should not trigger warehouse work, an embedding job, or a new retrieval plan.
Today, Qry endpoints can be called over HTTPS or wrapped by an MCP server a team already operates. The planned native MCP surface will expose the same active endpoints as agent tools rather than creating another query engine.
This is the role of the Company Brain Stem. The data stack assembles what the company knows, Qry carries approved context into software, and the agent decides how to use it.
Build outward from the data platform
The Cerebras architecture is sophisticated, but its components are familiar. Connectors feed Postgres through incremental jobs. Full-text and vector retrieval cover different forms of evidence. Reranking improves the results, permissions restrict access, and logs make the system observable.
The larger lesson is organizational. Companies do not need to wait for a new specialist function before building useful knowledge infrastructure. They can start with the data team, the systems already in production, and one question important enough to answer reliably.
As those questions accumulate, the warehouse and surrounding data platform become more than an analytical destination. They become the company brain, and they need a dependable delivery system.