How to build a company brain,
and know what you are taking on.
What the job actually contains and in what order, roughly how long each stage takes, what to budget beyond infrastructure, and the two limits that stay in place however well you build. Useful for holding a vendor to account as well as your own team.
Brief
You can build one, and the first version is quicker than you expect. Retrieval over your own documents is a solved problem with commodity tooling. Something demonstrable takes days.
The job is six parts, and they constrain each other in order: ingestion, chunking and embedding, retrieval, permissions, retention and redaction, and evaluation. Work through them in that sequence. Skipping ahead to retrieval quality before you have settled permissions is the most common way to end up rebuilding.
Budget attention. Inference and storage are cheap. A named owner with real hours is the cost that decides whether this is still working in a year.
Know the two hard limits before you start, because neither is solved by better engineering: most of what decides revenue was never written down as a document, and a retrieval system holds no position on how you win.
What you need to plan for.
Whatever stack you pick, a company brain is made of the same parts. Take them in this order, because each one narrows the choices in the next. Every card ends with the decision to make before you move on.
1. Ingestion
You need content out of the tools you already run and into your own store: the CRM, the drive, the ticketing system, the call recorder, email. Plan for incremental sync rather than full re-imports, and for the fact that every one of those vendors ships changes on their schedule rather than yours.
Decide firstWhich tools are in scope for version one, and who is on the hook when a connector breaks.
2. Chunking and embedding
Documents get split into passages and turned into vectors. This is the part that fails invisibly: bad chunk boundaries produce answers that are fluent, confident and subtly wrong, and nothing in your logs tells you. Keep enough surrounding context in each passage that it still makes sense read alone.
Decide firstYour chunking strategy and how you will re-embed everything when you change the model.
3. Retrieval
Finding the right passages for a question. Vector similarity alone plateaus quickly, so plan to blend it with keyword search, weight for recency, and re-rank the shortlist before it reaches the model. Treat this as its own project rather than a step inside ingestion.
Decide firstHow many passages reach the model, and how you break a tie between a good match and a recent one.
4. Permissions
A person should reach only what they were entitled to reach in the original tool, and that has to stay true when they change team or leave. Carry the permissions through with the content at ingestion. Retrofitting this later means reprocessing everything, and getting it wrong is the failure mode with legal consequences.
Decide firstWhether you mirror source permissions or run your own model, before you ingest anything.
5. Retention and redaction
Personal data arrives whether you planned for it or not, especially in call transcripts and email threads. Under GDPR it needs a defined life and a way to be removed on request, which means knowing every passage a given record was copied into. Redact at ingestion rather than at retrieval.
Decide firstWhat gets redacted on the way in, and how you honour a deletion request end to end.
6. Evaluation
You need a way to notice that answers have got worse. Build a set of questions with known good answers and re-run them on a schedule. Without this, quality degrades silently as content grows, and you find out from a colleague who stopped using it three months ago and never said so.
Decide firstYour question set and who reads the results, before you invite anyone else in.
The same six are what to hold a vendor against. Anyone selling you a company brain has solved these six somehow, and asking how is a faster way to judge a product than watching a demo.
Where the time goes, and where to put your effort.
Plan the investment in these blocks. In our experience the demo takes days and the version a team will actually trust takes months, and the expensive mistake is budgeting for the first while expecting the second.
If you take one scheduling lesson from this: put the evaluation set in place during the weeks stage, not the months stage. Teams that leave it until quality is already in question end up arguing about whether quality has dropped when they could have measured it.
Budget attention as well as infrastructure.
People expect the bill to be inference and storage. For a company of this size those are modest and falling, and they are not what decides the outcome. To get value out of a self-built brain you have to be ready to invest sustained attention in it, and that is worth naming out loud before the project starts rather than discovering in month four.
Plan for these lines:
- A named owner. One person, with hours actually ring-fenced, whose job includes this. Not a rota, and not whoever has capacity that sprint. Anything without a named owner drifts.
- Connector maintenance. Assume something breaks every few weeks and that somebody has to notice before your users do.
- Evaluation time. Re-running the question set and reading the results is a recurring hour, and it is the hour that keeps the whole thing honest.
- Curation. Somebody deciding what belongs in there and removing what has been superseded. This is the one teams forget, and it is the one that decides answer quality more than any retrieval tuning.
- Infrastructure. Real, and the smallest of these numbers.
Even a quarter of one engineer, permanently, is a salary line. Price that honestly against a vendor's annual figure before you decide.
None of which is an argument against building. It is an argument for going in with the running commitment costed, because a brain that nobody maintains becomes another place answers go stale, and it will have cost you a quarter to get there.
What a self-built brain is unlikely to do for you.
These are the hard limits. Neither is a skill problem or a budget problem, and neither is solved by better engineering, so it is worth knowing where the ceiling sits before you build up to it.
Limit one: it only knows what could be written down
You will get documents in. What mostly does not make it in is the material that actually decides revenue.
What stays outside: call recordings and what was really said on them, the live state of a deal and why it stalled, the support thread where a customer explained the problem properly, the renewal conversation, and the reasoning behind a price that was agreed verbally and never written up.
The system then answers from whatever part of your business happened to be written down, with total confidence, as though it were the whole picture. Nobody reading the answer can tell the difference.
What to do about itDecide up front which questions it will never be able to answer well, and say so plainly to everyone who uses it.
Limit two: it holds no position on how you win
A store of documents knows which file is newest. It has no view on which one is the company's current position.
What that looks like in practice: the pricing rationale from two strategies ago sits beside the current one and reads identically. The buyer definition superseded in the spring is still returned in April. A pattern building across several accounts contradicts something you agreed six months ago, and nothing notices, because nothing was told you had agreed anything.
Retrieval hands back the closest match to the words you typed. Deciding which match should have won, and whether last quarter's evidence changes it, is the actual work.
What to do about itGive a named person the job of deciding what is current, on a fixed rhythm. That is a role with hours attached.
The gap between what a system holds and what it sounds like it holds is where the expensive decisions get made. Better retrieval narrows it. Only structure and somebody's judgement close it.
Build it, or buy it.
All of it applies whichever way you go. Building and buying suit different businesses, and a few signals will tell you which one fits yours.
Build it yourself when
- The knowledge is technical, and already lives as text in systems your engineers own
- You have engineering capacity that is genuinely spare, this year and next
- The requirement is bounded, and you can name the questions it has to answer
- You want to own the stack for strategic or regulatory reasons
- Somebody wants the job of keeping it alive, and will still want it in a year
- The people using it are technical enough to spot an answer that has gone stale
Paying for one is the better call when
- What decides your number is in calls, deals and conversations as much as in documents
- Ingestion, permissions, retention and evaluation should be somebody else's standing problem
- You want a structure that holds positions, so an answer can be current rather than merely close
- You want somebody senior deciding what new evidence means, which is the part no build delivers
- The people who need the answer sit in sales, marketing and customer teams
- Your engineers have more valuable things to build than an internal search product
Both can be true at once, and often are. Plenty of companies run something internal for engineering knowledge and buy for the commercial side, because the two are read by different people and fail in different ways.
Your company’s commercial brain
and a senior operator to maintain it.
A senior commercial architect, the method they work from, and the brain that holds what your company knows about winning.
The architect
A senior commercial operator, twenty years from scale-up to PLC, working alongside your team on the strategy itself. They decide what new evidence means before anyone acts on it, which is limit two answered by a person rather than by code.
- From 20 hours a month
- Has carried a number, set pricing, built a motion
- How an engagement runs
The method
A structure that says how the parts of a commercial strategy relate: the value you deliver, the buyers it is worth most to, how you reach them, and what happens after the win. This is the piece that takes longest to invent from an empty repository.
- Built from work with companies across Europe
- Your version of it is yours to export
- The method in full
The platform
It reads the systems you already run, holds what matters about how you win, and answers in plain English with the evidence attached. We own all six parts, including the ones that break at inconvenient moments.
- Calls, deals and threads, as well as documents
- Ask from Slack, Claude, ChatGPT, Gemini, Copilot or Mistral
- An MCP endpoint, a versioned REST API and a CLI
If you want to see what you would be building towards, there is a recorded walkthrough of a working commercial brain, and a five-minute diagnostic that names the weakest part of your commercial picture without you talking to anybody.
Questions people ask.
Can we build a company brain ourselves?
Yes. If you have an engineer who can hold a project, this is well within reach. The shortest path that actually works:
- Pick one question set. Write down ten questions the business genuinely needs answered. Everything else follows from these, and without them you will build breadth instead of usefulness.
- Prove it on a folder. Embeddings and retrieval over a curated set of documents, no connectors yet. Days, not weeks.
- Add one real tool, with permissions. Whichever holds the most of your ten answers. Solve access control here while the surface is small.
- Put the evaluation set in before you invite anyone. Your ten questions with known good answers, re-run on a schedule.
- Then widen. More tools, better retrieval blending, deduplication and recency weighting, in that order.
- Name the owner. Before launch, not after. Somebody's job includes this or it decays.
What tooling do we need to build a company brain?
A vector store, an embedding model, an orchestration layer and a good language model will take you a long way, and the specific choices matter less than people expect. What decides quality is chunking, retrieval blending, recency weighting and evaluation, which is work rather than procurement. Pick the boring options and spend the saved time on retrieval.
How long does it take to build a company brain properly?
Days for a demo, weeks for live connections to real tools, and months to reach the point where somebody acts on an answer without checking it first. After that it is permanent upkeep rather than a project, because connectors change, people leave and content grows.
How do we stop a company brain’s answers going stale?
Three things, in order of how much they help. Weight retrieval for recency so newer material wins a close call. Remove superseded documents rather than adding the replacement beside them, because both will be returned. And give one person the standing job of deciding what is current, since no amount of tuning substitutes for somebody holding the position.
How should we handle personal data in a company brain we build?
Redact on the way in rather than at retrieval, so nothing sensitive is ever sitting in your store waiting to be surfaced. Keep a record of which passages came from which source document, so a deletion request can be honoured completely. And give every category of content a defined retention window before you ingest it, because deciding afterwards means reprocessing.
How do we know whether our company brain is working?
Two measures worth more than usage stats. Re-run your known-good question set on a schedule and track whether answers drift. And watch whether people stop checking the source before acting, because that is the moment it became trusted, and it is also the moment its accuracy starts to matter a great deal more.
What does a company brain cost to run once it is built?
The build is the visible cost, and running it is what decides whether it lasts. Budget four standing lines: engineer time on connector changes and retrieval tuning, inference and embedding spend that rises with usage and with every re-index, storage, and somebody’s hours deciding what is current. The first three become predictable within a month of going live. The fourth is the one worth naming an owner for on day one.
With Liffey that becomes a single monthly line with the upkeep inside it, and a senior commercial architect doing the fourth job as their actual work rather than alongside it.
Who maintains a company brain when the engineer who built it moves on?
Write the design down while you are building it. The chunking decisions and the reasoning behind them, how retrieval blends recency with relevance, what the evaluation set contains and what a passing score looks like, and which connector runs on which schedule. That document is what lets the next engineer change something without guessing, and it takes an afternoon during the build.
Under a Liffey engagement the upkeep sits with us and the structure exports at any time, so continuity holds through any change of people on either side.
How do we handle company brain permissions so people see the right things?
This is the part that takes longest to get right, and three decisions early save most of it.
- Whether the answer layer mirrors permissions from the source tools or holds its own model. Both work. Mixing them halfway is where surprises come from.
- What the day somebody leaves triggers, across the assistant, the index and every connector token.
- Whether an answer may quote something the person asking could not open themselves. Decide it deliberately and write it down.
A passage extracted from a document has left the document’s access list behind unless you deliberately carry it, which is the detail that catches most builds.
In Liffey what gets indexed is what you approve at connect time, down to the channel, the repository path and the part of a drive, and widening that is a separate deliberate act. Membership is invite-only, every record carries a workspace identifier verified on every request, and the audit log is append-only, recording the actor, the time, and the before and after state.
How do we keep a company brain EU-resident and pass a security review?
Residency is settled layer by layer rather than once: where the database sits, where application compute runs, where inference happens, and where embeddings are generated. Each is a separate choice, and a review will ask about all four, alongside your named sub-processors, your data processing agreement, and how you answer an access or erasure request inside a calendar month.
Liffey was built EU-resident from the ground up. Database, application compute, AI inference and embeddings all run in Frankfurt, adhering to ISO 27001:2022 and GDPR, and the named sub-processors and the data processing agreement are published in full, so most reviews complete from the published material.
Who decides what the evidence in a company brain actually means?
Retrieval returns passages. Somebody still has to state what the company’s position is, notice when new evidence contradicts it, and decide what changes as a result. That work is judgement, it stays with a person whichever way you build, and it is worth resourcing as explicitly as the infrastructure.
Liffey carries both halves. The structure holds your positions and how they depend on each other, and a senior commercial architect works inside the business to judge what new evidence means before the team acts on it.
Can we just sync everything into GitHub and query that?
For text that already belongs in a repository this works well, and it inherits versioning and review for free. It runs into limit one quickly: call recordings, deal state, support threads and renewal conversations have no way to live there, and those are usually the things your team is actually arguing about.
When is buying a company brain a better call than building one?
When the knowledge that decides your number is commercial rather than technical, when the engineering underneath should be somebody else's standing problem, and when you want a person applying judgement to what the evidence means. Judgement is a role, so it comes with a person doing it.
If we start with Liffey, can we move to our own build later?
Yes. You can export the full architecture at any time, and we delete or return the underlying content within 30 days at your choice. The terms are in the data processing agreement. Some clients treat the first year as the fastest way to work out what the structure should be, which is the part that takes longest to get right from an empty repository.
“We’ve grown by nearly 50% over the past year. In that time, Liffey has helped us better articulate our unique value proposition, evolve our pricing model, reset our go-to-market strategy and build scalable commercial systems. All of which has enabled us to make better decisions on a day-to-day basis and grow with more confidence.”
Nick Comer, Founder & CEO
Twenty minutes on your commercial strategy.
Where the strategy is thin, what a commercial brain would hold, and whether building it yourself is the better call. If it is, we will say so.