Building Your First Intelligence System: What Goes In, and In What Order

Over the last few weeks I have written about what an intelligence system is, what one contains, and why agents built without one produce confident, anonymous work. The question that keeps coming back is the practical one, and it is fair. Fine. How do we actually build one?

This is that post. Not the organisational capability roadmap, which is a different piece of work I have written about separately, but the system itself: what goes into it, in what order, how long before it is worth anything, and what it costs.

Why most businesses stall before the first source goes in

The stall is not where most people assume it is. In the government's research into AI adoption, among organisations that were already planning to adopt, 34% feel ready, 33% are unsure and 32% said they are not ready. Two thirds of the businesses that have decided to do this are either unsure or openly not ready, and they have not been stopped by cost or by regulation. They have been stopped by not knowing where to put their hands.

The same research has a useful clue about which part is hard. Businesses are most likely to face significant barriers implementing agentic AI (32%) and least likely to face significant barriers implementing natural language processing and text generation (18%). The autonomous end is close to twice as hard as the writing end, and the gap is almost entirely context. Text generation needs a good prompt. Agents need to know things about your business that are true today, and not having that layer underneath is what quietly kills agent pilots.

Which brings you to the first real question, and it is not which tool to buy. It is what goes in.

Start with what you already have

The instinct at this point is to declare a data project. Resist it, because that is where the eighteen months go.

An intelligence system is not a warehouse and it does not need one underneath it. The evidence that most businesses are nowhere near a warehouse anyway is fairly stark: the government's UK Business Data Survey found that only a quarter of UK businesses handling digitised data analyse data, either of personal, non-personal or both, to generate new insights or knowledge. If three quarters of the market is not doing analysis at all, then waiting for a clean data estate before you start is waiting for something almost nobody has.

What you need instead is a small number of documents that are current, owned, and specific about your business. Almost all of it already exists. It is in a proposal somebody wrote in March, in the deck used at the last board meeting, in a long email explaining why you turned a client down. The work is choosing what matters and writing down the reasoning, which is a thinking job rather than a migration job. That is why a first build can start the same week you decide to do it.

The same survey has one number that is worth building toward. Businesses whose AI tools were integrated into their existing systems were more likely to say that they analyse data (62%) and collect data (55%), against 30% and 37% for businesses whose AI tools sat apart from everything else. Roughly double on the analysis, and clearly ahead on collection. Connected to where the work happens beats clever and separate, every time.

What goes in first, and why the order matters

This is the part most first builds get wrong, and the mistake is always the same: starting with process documentation because it feels tidy.

Go in this order.

Decisions first. What your business has decided, and why. Which markets you chose and which you passed on. Why the pricing is shaped the way it is. The client you walked away from and the reason. This is the layer that exists nowhere else, that no competitor can buy, and that leaves the building when a long-serving person resigns. It is also the layer that makes everything downstream make sense, because a system that knows what you decided can tell you when a new situation resembles an old one.

Then the customer-facing truth. Who you serve, what you claim, what you refuse to claim, and what good work looks like. This is the layer that decides whether AI output sounds like your business or like the average of every business in your category. It is the same page I keep asking leaders whether they could write, and the difficulty of writing it is usually the finding.

Operational detail last. How the work actually gets done, step by step. It feels like the obvious starting point and it is genuinely useful, but on its own it produces a system that knows what to do and has no idea why. Put the reasoning in first and the process detail lands on top of something that can interpret it.

Three or four sources done properly will beat forty dumped in at once. A system with four current, cited, well-chosen documents answers questions. A system with four hundred documents of mixed vintage and no ownership is a search problem you have paid to create, which is what separates one of these from a company wiki.

What the first month actually looks like

Week	What you do	What exists at the end of it	The failure mode to avoid
Week 1	Pick one recurring question the business answers badly, and name an owner	A scope somebody is accountable for	Choosing "all our knowledge" as the scope
Week 2	Write the decisions and the reasoning behind them, in plain prose	Three or four current documents with dates and an author	Exporting existing files without deciding what is still true
Week 3	Make it answerable, with every answer citing the document it came from	A question in, an answer out, a source you can open	Accepting confident answers with nothing behind them
Week 4	Put it in front of the people who ask the question, and watch	Real usage, and a list of what it got wrong	Demoing it to leadership instead of the team who need it

Week four is the one that gets skipped, and it is the one that matters. A first build that impresses in a demo and never reaches the people who ask the question is the same pilot that quietly stops being used by week six.

How you know it is working

Three tests, none of which involve a dashboard.

The first is the citation test. Ask it something and see whether the answer arrives with a document you can open and a date you can check. An answer you cannot trace is a rumour with good grammar, and tracing answers back to a source is the thing that makes the whole system usable.

The second is the new-starter test. Give it to somebody in their first fortnight and see whether they stop interrupting people. If a new starter can get a good answer without booking time with your most senior person, the system holds knowledge rather than pointing at the people who hold it.

The third is the substitution test, and it takes longer. At some point somebody stops asking a colleague and asks the system first. That switch is the actual threshold, it usually lands in the second or third month, and it is the only one of the three that tells you the thing is compounding rather than sitting there.

What it is worth, and what it costs

The value case is hours, and it shows up in two places.

The first is the work that stops being done by hand. We built a weekly content engine for Excellerate Services across three regions, where producing one strong, research-backed post had taken roughly 12 hours a week and now takes around 2 hours of oversight, an 87% reduction. That did not come from a better writing tool. It came from the brand, the audience and the standards being written down properly first, so the system had something specific to be faithful to.

The second is the time nobody counts, which is the time spent finding out what the business already knows. That one rarely appears on a plan, and it is usually the larger number. If you want to put a figure on your own, the capacity calculator does the arithmetic in a couple of minutes.

On cost, plainly. A scoped first build with a partner typically sits in the £6,000 to £25,000 range for the first phase, and smaller scoping or consulting engagements start from around £3,000. The spread is driven by how many systems have to be connected and how much of the reasoning is already written down rather than sitting in somebody's head. Judge it against the hours it frees rather than as a software purchase, and if a first build cannot show you where the time comes back, the scope is wrong rather than the price.

You may well not need anyone. We built a member outreach system for a UK angel investment community on the tools the team already used, and it handed back 4 hours a week. The tooling is rarely the constraint. Whether the content is current, specific and traceable is the constraint, and no supplier can supply that part for you.

The uncomfortable finding underneath all of this

The ONS has been looking at which firms actually adopt new technology, and the answer is not the ones with the biggest budgets. Firms with higher management practice scores adopt more: while 88% of firms in the top management score decile adopted one or more technologies, only 51% did so in the bottom decile.

Nearly nine in ten against barely half, and the variable is how well the business is run, not what it spent. Structured management practice means knowing what you do, writing it down, measuring it, and reviewing it. Which is, more or less, a description of an intelligence system built by hand.

That is the honest version of this whole argument. Building one is not really an AI project. It is the act of writing your business down properly, and AI is what makes the written-down version pay for itself. Doing it once, in a store you control, is also what stops your own knowledge being rented back to you a slice at a time.

Practical takeaways

1. Do not start a data project. You need three or four current, owned documents, not a clean warehouse. Waiting for the warehouse is how this never gets built.
2. Decisions before processes. The reasoning is the part that exists nowhere else and leaves when people do. Process detail without it produces a system that knows what but never why.
3. Scope to one recurring question. "All our knowledge" is not a scope. One question the business answers badly is.
4. Make every answer cite its source. An answer you cannot trace back to a dated document is not usable by a new starter or an agent.
5. Ship it to the team, not to the board. The pilot that dazzles leadership and never reaches the people asking the question is the pilot that dies in week six.
6. Judge the cost in hours freed. If a first build cannot show you where the time comes back, fix the scope rather than negotiating the price.

The businesses that get value from AI in the next two years will not be the ones that bought the most capable models, because everyone will have those. They will be the ones that wrote down what they know while their competitors were still shortlisting platforms. If you want a view on whether to do that in-house or with somebody alongside you, the trade-offs are genuinely different depending on your team, and it is the conversation we tend to start with.

Frequently asked questions

What sources go into an intelligence system first?

Decisions first, then the customer-facing truth, then the operational detail. Start with the decisions your business has already made and the reasoning behind them, because that is the knowledge that exists nowhere else and walks out of the door when people leave. Next comes what you claim in public: who you serve, what you stand for, what you will not say. The process detail goes in last, even though it feels like the obvious starting point, because a process document without the reasoning behind it just tells a system what to do and never why. Three or four sources done properly will beat forty dumped in at once.

Do we need to tidy up our data before we start?

No, and waiting until you have is the most common way this never gets built. An intelligence system is not a data project and it does not need a clean warehouse underneath it. It needs a small number of documents that are current, owned by a named person, and specific about your business. Most of what goes in already exists in a slide deck, a proposal, or a long email somebody wrote at the time. The work is choosing it and writing down the reasoning, not migrating anything, which is why a first build can start in the same week the decision is made.

How long before an intelligence system is useful?

It answers useful questions in weeks, and it changes how the business works in months. A first build with three or four well-chosen sources is genuinely useful once somebody can ask it a question and get an answer with the document behind it, which is usually inside the first month. The compounding takes longer. The point at which people stop asking a colleague and start asking the system is the real threshold, and that tends to arrive somewhere in the second or third month once enough answers have come back right.

Can we build an intelligence system with the tools we already have?

Usually yes for a first build, and it is normally the right call. The constraint is rarely the tooling, because most businesses already have somewhere to keep documents and something that can search them. The constraint is whether the content is current, specific and traceable back to a source. We built a member outreach system for a UK angel network entirely on the tools the team already used, and it gave back 4 hours a week. Prove the value on what you own, then spend money on the parts that turn out to be genuinely limiting.

How much does it cost to build a company memory system?

A scoped first build with a partner typically sits in the £6,000 to £25,000 range for the first phase, with smaller scoping and consulting engagements from around £3,000. The spread depends on how many systems have to be connected and how much of the reasoning is already written down rather than living in people's heads. Judge it against the hours it frees rather than as a software purchase: if a first build cannot show you where the time comes back, the scope is wrong, not the price.