Case Study: Building a Company AI Brain That Answers Questions, Then Starts Handling Them
Quick answer: A company AI brain is an internal assistant that lives in the tools your team already uses (Slack, Teams, WhatsApp, email), answers questions from your own documentation, and connects to live systems like your CRM, marketing stack, and online store. We built one for a client whose processes were spread across Google Drive guides, old Slack messages, and training videos. It started by answering questions about operations and HR. Then we added connectors, so it could pull a full picture from several systems at once. Then we cloned it into specialized versions that do the work, including handling customer return requests without a human in the loop. Time to a first working version in a real channel: four to six weeks.
Most companies do not have a documentation problem. They have a retrieval problem.
The client we worked with had written almost everything down. Onboarding guides on Google Drive. Process rules typed into a Slack channel two years ago, still correct, completely unfindable. Screen recordings that explained a workflow better than any document, sitting in a folder nobody opened. HR policies in one place, operational procedures in another.
So people did what people always do. They asked a colleague.
The real cost of scattered knowledge
The cost is not the five minutes it takes to answer a question. It is everything that sits around those five minutes.
Experienced people get interrupted all day for information that already exists in writing. New hires take longer to become useful, because their speed depends on who happens to be online. Two people give two slightly different answers to the same question, and both believe they are right. And when a question needs live data, not documentation, the whole system falls apart: no document can tell you where order 4821 is right now.
That was the starting point. Not "we want AI." More like: "we know the answers exist, we just cannot get to them."
Step 1: We sorted the knowledge before touching any AI
This is the part most AI projects skip, and it is the part that decides whether the assistant is trusted or quietly abandoned.
Documents are not equal. A call transcript and a meeting note are raw material: they tell you what happened once, in one conversation, possibly based on assumptions that changed a month later. A playbook or an SOP is an instruction: it tells you what should happen every time.
If you dump both into the same index, the assistant will eventually answer a policy question by quoting a side comment from a meeting in March. Confidently. That single answer is usually enough for a team to stop trusting the tool.
So we split sources by type, transcribed and indexed the screen recordings, and prioritized ingestion by one boring criterion: which sources people actually ask about.
Step 2: Permissions on day one, not later
Not everyone should see everything. HR material, commercial terms, and internal financials all have different audiences, and an assistant that quietly ignores that is a liability, not a productivity tool.
Access control went into the design from the first week, with read-only credentials scoped to each source. It is much harder to retrofit permissions into a system that already answers everything for everyone.
Step 3: We put it where people already talk
The assistant lives in the company's own communication channel. No new portal, no separate login, no browser tab that people forget exists.
This sounds like a detail. It is not. A tool that requires a context switch gets used during the first enthusiastic week and then dies. A tool that answers in the same window where someone was about to type "quick question, does anyone know…" gets used for years.
Step 4: Connectors, so answers include live data
Once the static knowledge was reliable, we gave the assistant access to external systems: marketing tools, the CRM, the e-commerce platform.
This changed the type of question it could handle. Instead of only explaining how the return process works, it could look up a specific customer, a specific order, and the relevant policy, then put all three into one answer. The documentation says what should happen. The connectors say what is actually happening. Merging both in a single response is where the assistant stopped feeling like a search box.
Step 5: From answering to acting
With a working knowledge layer and live access in place, we cloned the assistant into specialized variants. Same brain, narrower job, different permissions.
One of them handles customer return requests on its own, end to end.
Our default posture for anything that writes to an external system is draft plus human approval. The agent prepares, a person signs off. We only move to fully automatic execution when two conditions hold: the scope is narrow, and the blast radius of a mistake is small. Every run is logged, so any action can be traced back afterwards.
Returns met both conditions. Most tasks do not, at least not in month one.
What we deliberately did not build
Being clear about the limits is part of the deliverable.
Not a general-purpose intelligence. It will not figure out an undocumented process. If the knowledge does not exist in a structured form, the assistant cannot invent it, and it should not try.
Not a "connect everything" project. Some tools have no usable API. Some workflows need small changes before automation makes sense. We said which ones upfront rather than discovering them in week five.
Not an open-ended agent loop. Where a workflow is known and repeatable, a fixed, deterministic path beats an agent deciding its own steps. It is easier to test, easier to audit, and easier to fix.
Where the data lives
Everything runs in the client's own cloud account. AWS by default, because Bedrock, storage, and compute give the fastest path to a working system, though other providers work where a client's stack or policy requires it.
Knowledge base content stays in the client's storage. It is not uploaded to a model provider's cloud, and it is not used to train anyone's model. Only the specific snippets needed to answer a given question are sent to the model at the moment of the query.
Compute, storage, and model usage are billed directly to the client's account. Every line item is visible to them, with no markup from us.
What we would tell you before you start
Five things we now say in the first meeting, because each of them cost someone time to learn.
Name one owner on your side. One person who makes decisions and unblocks access. Projects stall on "we are waiting for someone to decide," not on technical problems.
Bring the people who do the work to the workshop. The CTO knows the vision. The team knows the shortcuts, the exceptions, and the step everyone skips. You need both in the room.
Expect to improve your documentation. Building a knowledge base exposes what was never written down properly. That work is worth doing whether or not you deploy an assistant.
Plan for freshness. A one-off import goes stale in weeks. Wherever the source allows it, sync pipelines keep the knowledge base current as documents change.
Protect early trust. Start with tasks whose answers can be verified. One confident wrong answer in week one costs more adoption than ten correct ones buy.
Results
The assistant became the first place people go with an operational or HR question, instead of the second place after a colleague. Onboarding stopped depending on who was available. Answers stopped varying by who was asked. And the specialized agents moved a category of repetitive work off the team entirely.
FAQ
What is a company AI brain? An internal AI assistant built on your own documentation and connected to your own systems. It answers questions about how your company works, and it can execute defined tasks in the tools it has access to. It runs inside your existing communication channels, so nobody has to learn a new interface.
How long does it take to build one? Four to six weeks from the discovery workshop to a first working version in a real channel. Setups with several specialized agents and more complex integrations typically take eight to twelve weeks.
Is our data used to train AI models? No. The knowledge base stays in your cloud account. Only the snippets needed to answer a given question are sent to the model at query time, and that content is not used for training.
Can it do things, or only answer questions? Both, in that order. We start with answering, because it is low risk and it proves whether the knowledge base is good enough. Actions come once the assistant has earned trust, and they start in draft mode with a human approving each one.
What if our documentation is a mess? That is the normal starting condition. The first phase is mapping and structuring what exists, separating instructions from raw material, and prioritizing the sources people actually ask about. You do not need clean documentation to start. You do need to accept that cleaning some of it is part of the project.
Which tools can it connect to? It depends on your stack. We map the tools you use and build integrations that fit your workflow. Some systems connect easily, some need workarounds, and a few are not worth connecting at all in the first phase. We tell you which is which before the work starts, not after.
Talk to us about your own knowledge problem
If your team keeps asking the same questions, or the answers depend on who is online, the material for a company AI brain probably already exists inside your company.
The first step is a discovery workshop. You bring the tasks you would like to hand over. We help pick the one that is easiest to measure and prove, then map the tools, access, and documents needed to scope it.