Beyond the Knowledge Base: How a Company Learns to Understand Itself

A customer asks for a revised security report. The request is in email. The report comes up again in a meeting. On Thursday, someone sends the approved document. On Monday, a colleague asks your company assistant, “What do we still owe this customer?”

A good search system can find all three conversations. It may even put the original request first, because “still owe” sounds most like the email that asked for the report. But that is the wrong answer if the document was delivered.

The assistant needs to know that the request happened, that the right report was sent, and that the promise is now history rather than unfinished work. Finding the messages is the beginning of that job, not the end.

First, give search its due

Company knowledge is scattered across chat, code, documents, meetings, calendars and people's heads. Bringing those sources together without making everyone move their work into a new filing cabinet is a serious achievement.

Cerebras described how it built its internal knowledge base: it makes conversations and other company material searchable, combines different ways of finding relevant information, and serves people as well as agents. Cerebras says employees ask it more than 15,000 questions a day, three months after launch. That is not a trivial feature. It is a habit people actually use.

Search is also something people can check. It can show the thread or document behind an answer. If the result is weak, a person can often spot the problem.

What search does not do by itself is decide what is true now. The best-matching message may be old. The latest message may describe an event from last week. Two people may disagree. An email from a stranger may be accurately quoted and still have no reason to interrupt the founder.

The report is sent. What changes?

Return to the security report. The original request should stay searchable. So should the meeting and the sent document. But the next time someone asks what is open, the delivered report should no longer be on the list. That depends on whether the right document reached the right customer.

That last part matters. A meeting about the report is not delivery. A message saying “done” without the document may not be delivery. The system has to connect the later action to the exact thing that was owed.

This is one reason we keep evidence and conclusions separate. A source can explain why Team0 believes something. It should not become authority just because its words happen to match the question.

What Team0 keeps besides documents

Our World Model connects people, organizations, claims, meetings, decisions and work to the sources they came from. It does not treat every sentence it reads as a fact. A customer email proves the customer wrote something. It does not prove their account of the situation is correct, that they know the owner well, or that an agent may act on the request.

Team0 keeps supported beliefs apart from source material that can be searched and cited, and from claims that still need checking. A claim marked “trusted” has met the model's rules. That does not mean it will always be true. When evidence corrects a belief, the old answer stays in the history without continuing to pose as the current one.

We also keep two dates. One is when something happened. The other is when Team0 learned about it. If a transcript of last Tuesday's meeting arrives today, the decision was made last Tuesday. A newer database row is not necessarily a newer event.

The next question is what an agent should receive. An assistant preparing a meeting and an external agent doing a narrow task should not each invent their own account of the company. They should draw from the same underlying model, within their different permissions. That way, a correction has one place to start instead of leaving stale copies everywhere.

Even a well-supported fact may not belong in a morning brief. A new email can be real and still be unimportant to this owner. Team0 therefore has to ask a second question after “is this supported?”: “does this matter here, to this person, right now?” Our first-contact case shows what goes wrong when those questions collapse into one.

And permissions come before the answer, not after it. A public-facing agent should not retrieve a private email and rely on an instruction to keep quiet about it. The read itself has to be limited to what that conversation may see. Who is asking, whose information it is, what the agent may say, and whether it may take an action are separate decisions.

A company is not one person's memory

This becomes harder when more than one person is involved. A sales lead may know what the customer agreed to. An engineer may know how an incident was fixed. They may hold different evidence, and they may not be allowed to share all of it.

Our Company Chief design does not start by copying every employee's private world into one giant index. Each person's Chief keeps their own context. Company-relevant knowledge can cross over with consent and attribution. The Company Chief can also ask a member's Chief a narrow, permitted question rather than taking the whole underlying conversation.

Say a founder asks, “Who knows about Northstar's security review?” A document search can return files mentioning Northstar. A company understanding ought to tell the founder who has the commercial decision, who knows the technical fix, whether those answers disagree, and which parts each person has actually agreed to share. If consent is withdrawn, the company view must stop using that person's contribution.

We're building the Company Chief around that boundary. “More shared knowledge” should not mean “everyone's private context in one pile.”

The answer is not the end of the work

If an agent says “I handled it,” what happened? Did it send the message? Did the message reach the right person? Did the reply actually settle the question? Which earlier matter was it meant to close?

Without those links, an assistant can mark the wrong task complete, mistake its own summary for evidence, or keep raising something the user already resolved. We need to be able to trace the path from the original source to the answer, then to the action and its outcome. We test that chain because this is where an agent's mistakes become expensive.

Search remains the right doorway. Cerebras's reported usage is a reminder that people will return to a tool that helps them find what they need. We should earn the next step the same way: let people inspect the source, show what changed, be honest about what is uncertain, and only then ask them to trust an agent with more work.

A knowledge base helps a company remember what it said. A Company Brain should help it notice when the answer has changed. Then the right people and agents can act on that change without losing the evidence or each other's trust.