Building a Company Brain: A RAG Chatbot That Remembers Every Project

Most companies have a brain problem. The knowledge exists: it is in project documents, meeting notes and email threads. But it is scattered, and the usual way to get at it is to ask a person: "Where is that project at? What was decided last week? What is the timeline now?"

That interrupts someone, and the answer depends on who happens to remember. I want to fix that for Concept Dash with a company brain: a chatbot you can simply ask, and get a clear answer from the company's own data.

The idea in one line#

Ask a question in plain language. Get a simple answer, drawn from our own data, instead of chasing people for updates.

How it works#

The system is a RAG chatbot: retrieval-augmented generation. In plain words, it looks things up in your data first, and then answers.

1. Take in the company's data#

First, the system reads the company's data: project documents, notes, reference material. It splits them into manageable pieces so each one can be found on its own.

2. Turn each piece into an embedding#

Each piece of text is converted into an embedding: a list of numbers that captures what the text means. Two passages about the same subject end up with similar numbers, even if they use different words. This is what lets the system search by meaning, and not just by keywords.

3. Store the embeddings in a vector database#

The embeddings go into a vector database, which is built for exactly one job: given a question, find the stored pieces that are closest in meaning.

4. Chat#

Now the chat part. When someone asks a question, the system:

1. converts the question into an embedding,
2. asks the vector database for the closest matches,
3. hands those matches to the language model together with the question,
4. and the model writes a clear answer, based on what was retrieved.

So the answer comes from the company's data, not from the model's general knowledge.

The part I care about most: memory#

A knowledge base that never changes is just a search box. What makes this a brain is that it learns as the company works.

When someone adds data about a new project, that data is turned into embeddings and saved into the vector database, as memory. The next time anyone asks about that project, the system retrieves it from the new data. Nobody has to retrain anything or tell the bot that something changed.

That is the difference between a chatbot that knows what you loaded last month and one that knows what happened this week.

The next step: meeting notes and emails#

The plan I am most excited about is feeding the brain with the things that actually describe where projects stand:

• Meeting notes
• Emails

Those hold the current timeline: what was agreed, what slipped and what is due. The system would read them, pull out the project timeline and keep it in the brain. Then you could simply ask, "What is the timeline for this project right now?", and get an answer built from the latest meeting notes, with no one having to be interrupted.

Why a company should have this#

I think a company should have its own database and its own memory: a single mind that stays in sync with what the business is doing.

Today, finding out the status of a project means asking people: "Hey, what is the update on this?" That has costs. It interrupts the person being asked, it gives different answers depending on who you ask, and it makes the people who know the most the bottleneck.

With a company brain, a simple question in natural language gets a simple answer.

What I am watching out for#

A system like this is only useful if it can be trusted, so these are the risks I am designing around:

• Wrong answers. A model can still make things up. The answer should always show the source it came from, and the assistant should say "I do not know" when the data does not cover the question.
• Stale data. An old document can contradict a newer one. The system needs to prefer recent information and to be able to replace outdated memory.
• Privacy and access. Meeting notes and emails contain sensitive material. The brain must respect who is allowed to see what, and not leak a private thread to someone who should not read it.
• Messy input. The quality of the answers depends on the quality of what goes in. Chopping documents sensibly and cleaning the data matters as much as the model.

What is next#

I am implementing this at Concept Dash now. I will update this post with images of the system, how the ingestion works, how it handles meeting notes and emails, and what went wrong along the way.

If you want a company brain built for your own team, with sensible limits on who sees what, share a short brief through the project form on this site and we can scope it together. You can also read about the AI automation service or browse more case studies.