An AI Brain brings a company’s knowledge and working procedures together in a place a language model can read. The company builds it from existing documents, decisions and rules, and its value grows as that information is updated and checked. A subscription or website chatbot can be part of the system, but cannot replace this work.

The practical difference is how the company preserves its knowledge. When information stays in people’s heads, they have to explain it to the model for each piece of work.

When that information is written down, organised and kept with its history, the system can retrieve the relevant context before starting. Organising the company’s knowledge is therefore the first step.

What is an AI Brain, actually?

An AI Brain has three parts that work together. The first is memory: relevant information about clients, work and decisions, kept in sources that people and the system can consult. The second is procedures: documented working rules, revised over time and applied with checks to each type of work.

The third part is verification, meaning the gates every produced artefact passes through before it reaches a client.

In our methodology, the model acts as a cognitive processor: it helps the company work with what it already knows. The quality of its output depends on the information it receives, which is why documenting company knowledge matters more than choosing a subscription.

The language model is the engine, while company knowledge remains in the documents around it. Replacing the model need not erase those documents, but the replacement must be tested against existing procedures and checks. Compare its handling of the same sources, permissions and acceptance criteria before relying on it for client work.

A conversational assistant such as ChatGPT can do some of this work and may retain information across conversations, depending on its settings. That memory does not replace company documents, approved procedures or a history of decisions. Consistent work requires access to those sources.

Why is a subscription to a conversational assistant not enough?

An assistant without access to company knowledge makes people reconstruct the context for each task. Someone opens a new conversation, explains who the client is, what was discussed on the last call, which tone to use and what the company cannot promise, then asks for the work. The next day, a colleague repeats the process and gets a different result because they explained it differently.

Two costs come out of this, and neither appears on an invoice. The first cost is the time lost re-explaining, which accumulates quietly across dozens of conversations a week. The second cost, and the expensive one, is inconsistency, because two people describing the same company in different words receive two results that do not resemble each other.

A well-organised AI Brain reduces that repeated work. When someone requests a deliverable, the system retrieves the client information, previous decisions and writing rules, so they do not need to be explained again.

What are its working layers?

A working AI Brain has separate layers, each with a clear owner, because information that lives in two places at once diverges and becomes, before long, a reason to distrust the whole system.

Layer What it holds Who writes it How often it changes
Sources Documents, call transcripts, platform exports The company’s people continuously, by addition
Durable memory Rules, stable facts, decisions and their reasons The system, every session weekly
Current state What is open now and what the next step is The system, at the end of each work block daily
Procedures How each type of deliverable is made, step by step People, once, then calibrated rarely
Verification The gates a deliverable passes before the client The system, automatically at every delivery

Each piece of information has one source, which the other layers refer to. If the same figure is manually copied into three files, those versions can diverge, leaving you unsure which is current.

The second rule, learned from using our own system, is that each layer needs a size limit, measured in bytes. Our context-loading tools can silently truncate files that exceed their limits. The system may therefore appear to have a memory file available even though the model has received only part of its instructions.

Which layer of the company does an AI Brain sit on?

The layers above describe the system itself. We also analyse the company through four layers to identify both visible problems and their causes.

L1, performance marketing. This covers cost per lead, cost per acquisition and conversion rate. These measures are easy to track, but they do not explain on their own why a customer buys or leaves.

L2, revenue and sales process. This covers sales opportunities, cycle length and movement between stages. If a prospect leaves after a third meeting, examine the sales process alongside the offer, price and fit with the buyer’s need.

L3, orchestration and memory. This is where the AI Brain sits. Company data, procedures and reasons behind decisions help preserve knowledge when team members change.

L4, positioning and category architecture. This defines the criteria buyers use to compare the company with competitors, which influence whether the other layers work in its favour.

Our analysis starts with available measures and works towards positioning. A company can form a positioning hypothesis without complete customer data, but it needs to test that hypothesis through interviews, buying behaviour and commercial results.

An AI Brain without commercial data can organise documents and support other work. To make useful recommendations about sales, it also needs relevant L1 and L2 measures interpreted in context.

Four layers of analysis, from measures to positioning
  1. L4 · Positioning and category The dimension you get compared on
  2. L3 · Orchestration and memory This is where the AI Brain lives
  3. L2 · Revenue and commercial process Pipeline, sales cycle, stage velocity
  4. L1 · Performance marketing Cost per lead, cost per acquisition, conversion rate

Commercial decisions also need data about demand and sales

What does our system look like in practice?

At UNRIVALS, the system brings together working documents, procedures, current project status and decisions recorded with their reasons. Memory files are marked by client, and access to information must be controlled for each task.

This structure helps the team find the source of a claim and the rule used in preparing a deliverable. A file count alone would not show whether the system helps; the retrieved information has to be correct, current and appropriate for the client.

We keep a history of recorded versions for tracked files so that changes can be reviewed.

For a founder, the useful part is what this organisation enables. At the start of a task, the system can bring in the client’s current situation, recent decisions and next step. A new deliverable uses the relevant procedure, while its quality still depends on the sources and human review.

At the end of the day, the decisions taken are written into a journal along with their reasons, because three months later the file on disk tells you what you did, while the reason you did it is lost unless you wrote it down at the time.

It is worth saying what it does not do. The system does not decide, does not speak to the client on our behalf, and does not send anything outward without a person looking first. Documentation, client profiles, call analysis, drafts and verification pass through it, while the decision and the relationship stay with people.

What breaks while you are building one?

Almost all of our problems arose from the gap between what we believed the system was doing and what it actually did. The choice of model did not explain that gap.

A stale pointer can lead to the wrong source. We once moved a file without updating its map; the system continued with information that was no longer appropriate. We now check mechanically that map pointers lead to files that exist.

A check must be tested on a defective example before you can trust it. Our checks kept approving work, which reassured us until we tested one against a deliberately defective deliverable and it approved that too. A check that cannot distinguish acceptable work from flawed work gives confidence without evidence.

A success response from a platform does not prove the thing happened. We wrote data through programming interfaces that confirmed the write, then discovered on an independent read that the result looked different. Since then, any change to a live system gets reconfirmed through a separate read, made from another direction.

In all three cases, the system continued without reporting an error. That is why we verify the final result independently.

The lesson from these failures is to keep corrections that matter. Recurring or significant corrections are documented with their reasons and can become rules for later work. We also test the checks against known bad examples and revise them when they miss a defect.

Written corrections can help future work when the system retrieves the right rule and the team checks that it was applied. That makes a repeatable process possible beyond a single conversation.

What happens when public information is hard to find?

The three defects above concern information available inside the company. Visibility audits reveal a related but distinct problem: public information may be missing or difficult for external systems to access.

In our audits, some companies received no citations in sampled AI answers. Crawler access is separate from internal memory and should be checked alongside page relevance and how each system selects sources. The Doctor Skin and Therezia cases are documented in their audits.

One possible response is to turn verified company knowledge into public pages that answer customer questions. External systems can then find relevant sources, although citation is not guaranteed. Internal documents and public pages serve different purposes and need separate management.

In some audits, part of the solution uses information or capabilities the company already has. These need checking and should be made accessible to the relevant audience, perhaps through a clear page or a concrete example.

Compliance also requires attention. The obligations described in our guide to the European regulation for AI depend on the system’s use and the company’s role. Keeping readable records can support documentation, but does not establish compliance on its own.

Why do some corporate AI projects stall?

Buying a tool before preparing the company is one risk examined here. MIT NANDA’s July 2025 report, drawing on more than 300 public initiatives, interviews in 52 organisations and responses from 153 leaders, says only about 5% of the integrated pilots examined produced measurable value in the millions. The authors describe a gap between pilots and profit-and-loss impact. The sample and definitions of success vary, so the figure cannot be extended to all companies or all uses of AI.

Gartner had already estimated, in 2024, that at least 30% of generative AI projects would be abandoned after the proof-of-concept stage, because of data quality and unclear business value.

The two measures in McKinsey’s 2026 survey tell different parts of the story. Forty-four per cent of respondents say their organisations are scaling AI across the enterprise, up from 38% a year earlier. Separately, 37% attribute at least some positive EBIT impact to AI, a share that is practically unchanged year over year.

Reported scaling has increased while the share reporting positive EBIT impact has remained broadly stable. The difference between 44% and 37% is not a count of companies using AI without a return.

BCG’s approach to allocating effort in an AI transformation reinforces the importance of working practices: 10% on algorithms, 20% on technology and data, 70% on people and processes. Documenting how the company works is therefore a major part of building an AI Brain.

Ethan Mollick, a professor at Wharton, describes a way of working in which a person chooses the task, checks the AI response and changes approach when the result is weak. The example leaves responsibility for decisions and verification with a person who has the context for the work.

Where your company sits geographically changes the size of the prize. Eurostat data for 2025 puts AI use among European companies with at least 10 employees at an average of 20.0%, with a spread across member states wide enough that the laggards sit at roughly a quarter of the European average.

Low adoption may leave room for useful applications of AI, but an advantage needs to be demonstrated through results. Among EU companies already using AI, 34.7% use it for marketing or sales, according to Eurostat. That use alone does not show whether commercial outcomes improved.

Where does a founder of a 3M+ EUR company start?

Start by inventorying the sources about clients and creating a controlled base of relevant information. Give the system access only to what a task requires, within the appropriate permissions. Buying an AI tool alone will not help if useful knowledge remains only in people’s heads or inaccessible inboxes.

The second step is to write the procedure for a single type of work, the one you do most often, and to carry it all the way through. One finished procedure beats ten started, because only then do you see which part actually consumes the time.

The third step is verification, and my recommendation here is to calibrate it on bad cases rather than good ones. You hand the gate a deliverable you know is weak and watch whether it rejects it. If it accepts it, the gate does not exist, however good it looks in the report.

The fourth step we learned by paying for it, so it deserves its number. Measure the running cost of the system, not only its output. On 17 September we ran our own log through a counting script and found that the same unique content had been re-read 124 times inside a single working day.

Eighty-two per cent of the content processed in that measurement was repeated context rather than new information. This measures context consumption, not money spent. We now cap the context files loaded at each step and resume long conversations from a summary.

These four steps give the model a basis for its work. It can use the information and rules the company has documented, while its results still require verification.

This order is not a technical preference. It comes from the same principle we apply in marketing architecture, where infrastructure gets built before campaigns, and in the way we look at strategy that uses AI, where the tool comes after the decision rather than before it. An AI Brain built on top of a company that has not written down its knowledge amplifies the existing disorder, at higher speed.

Our article on AI as the company’s processor explains the model’s role in more detail. That role affects whether the budget goes into subscriptions or into documenting the knowledge that makes them useful.

Frequently asked questions

What does it cost to build an AI Brain?

The cost depends on how many sources need organising, what access they require, which procedures must be documented and which checks are needed. The budget includes staff time, tools and maintenance. Without that scope, there is no monthly price that applies to every company.

Do I need a developer?

You can begin without a developer by inventorying sources and writing procedures in natural language. Some connections and checks can be built with no-code tools; more complex integrations or checks may need technical help. The choice depends on the company’s systems and permissions.

Does the company’s data stay the company’s?

Before signing, check what the contract and the provider’s policy say about data rights, access, storage and processing. Separately, review the account settings, permissions and how people in the company use the system. Our own rule is that sensitive, financial and personal data sits separately, in areas the system is not allowed to read.

How long until a result shows?

The first completed procedure allows a practical test. Two people apply it to the same task, and their results are checked against the same criteria. We look for fewer unjustified differences and fewer corrections. Improvement over time requires regular updates and verification; a few months of use alone will not guarantee it.

What happens when a new model arrives?

The documents remain available when you change the model. We have changed models several times without losing what we had written, because our memory and procedures live in files rather than an account tied to a single provider. Before using the new model for client work, test how it follows those procedures and handles the same sources, permissions and acceptance criteria.

Where does someone start who already pays for the subscriptions?

With an inventory of what you have already written. Almost every company owns more material than it believes, scattered across old proposals, presentations, long answers given by email and meeting transcripts. The step that returns the most, in the first week, is to gather that material in one place and to clean out whatever is no longer true.


If you want to see this principle applied to your own company, before any investment in tools, you can request a positioning analysis. It shows you what the market currently believes about you and where the system breaks, and from there it becomes clear whether your problem calls for AI or calls for order first.