That person is your business’s memory. And almost none of what they know lives in a system.

You have spent the last decade building the opposite. You have moved your documents into a data lake, a SharePoint, a Veeva, and a dozen other repositories. Everything the business has ever produced is in there somewhere; the essence of that knowledge remains elusive. Your data lake became a basement full of boxes. Everything is there, but no single box knows about any other, so the value has to be mined out. That is what your analytics team does all day: mining for data, mining for reports, mining for connections. The mining never ends, because nothing down there remembers what the last search uncovered.

For the last twenty years, IT has been trying to break down the silos that result. But silos are resilient, surviving reorganisations and platform migrations. The reason silos survive is simple, and it has nothing to do with technology being immature. The valuable part of the knowledge never made it into a system in the first place. A specialist’s judgement, the reason this budget maps to that objective, the context behind a decision, lives in their head and in the hundreds of files on their desktop. Integration projects move data between systems. They cannot move the meaning.

Finding is not understanding

In the first article of this series, I described RAG, the standard way AI reads company documents today. RAG is a good librarian for the basement. Ask it for the 2025 media plan, and it will find the file. That is useful, and it is also where most AI pilots stop.

Suppose the file is a media plan for a Q3 campaign in Poland. RAG can hand you a document in seconds. What it cannot tell you is that the plan spends against a specific brand budget. That the budget exists to defend market share before a patent expiry, that the creative was produced by one agency while the media was booked by another, their budgets, or that last quarter’s almost identical campaign underdelivered by twenty per cent. All of those facts sit in the same basement, in other boxes, and nothing connects them. Finding the box is not the same as understanding what is inside it, or why it matters.

What a memory is

A memory is the layer of meaning that sits on top of the basement. It is the colleague, not the boxes. Building one takes three plain ingredients.

First, a shared dictionary of meaning, an agreed definition of what the words of your business actually mean. What a campaign is, what a brand plan is, who counts as a stakeholder, and how those things relate to each other. When the technically minded call this an ontology, that is all they mean. An agreed model of your business, written down so a machine can use it.

Second, a map of connections where every document, dataset, deck, and spreadsheet is linked to the things it touches, so the media plan is wired to its budget, its objective, its agencies, and its results. This map is what people mean by a knowledge graph. It is a web of connections rather than a list of files.

Third, a sense of resemblance, which creates the ability to recognise that two things concern the same subject even when they use different words. So that “critical success factors” in a presentation and “csfs” in an Excel column are treated as the same concept based on their meaning and business context. This is the quiet work a vector database performs beneath the surface.

A memory built from these three ingredients does three things, in this exact order:

  1. It reads everything the business produces and stores it as connected facts rather than loose files.

  2. It gets better as more is added, because every new document or dataset strengthens the web around what’s already there.

  3. When someone asks a question, it returns the answer with all of that context attached, instead of handing back the closest-looking document and hoping.

Integration without the integration project

This solves a second old problem. The traditional way to make two systems talk is through IT integration. Someone decides what a Salesforce field means, maps it to a Veeva field using code, and maintains that wiring forever. It is slow, fragile, and dependent on IT’s interpretation of each department’s needs.

Instead of plumbing, a shared memory captures the meaning, enabling systems to understand each other. Once a system’s data is described in this shared dictionary, it joins everything else using a common language, with no bespoke pipe to build and rebuild every time something is added or changes.

And the things that draw on that memory are not only people. The AI embedded in your tools, the assistant in your CRM, the one in your marketing automation platform, your finance system, even your DAM, can read from the same memory to understand context that sits well outside its own four walls. Now the Salesforce AI assistant can see why a brand’s priorities shifted last quarter, the content tool can see the regulatory constraint recorded in Veeva, and all systems can get context from information recorded somewhere else entirely. Humans, large language models, and the AI baked into the systems you already own can now operate from a unified understanding of your business.

You have already paid for the hard part

If that sounds like another two-year transformation programme, it is the opposite. The most challenging part of building a business memory is developing the dictionary of meaning applicable to your business.

Large consulting firms try to prove their value here by claiming they should build it from scratch, ignoring all your previous efforts and investment, in yet another lengthy transformation programme. In reality, it doesn’t need to be created from nothing; each business function already has its systems and standards. You have probably already invested in countless transformation programmes, and most of the meaning is already there, hidden in Excel files and polished consultant decks. Also, because the way commercial organisations operate is much more similar than most acknowledge, the pieces of the puzzle match within the same industry.

Take pharma. Two companies face the same regulatory constraints, the same market pressures, and largely the same processes; what differs is the vocabulary and where accountability sits. One company calls a channel ‘rep email’, another names it after the platform that sends it; it is the same channel doing the same job, even if the MLR details wrapped around it differ. What separates your dictionary from a competitor’s is mostly the labelling and business rules. The foundation is shared, so nothing starts from scratch; the layer fitted on top is what makes it yours.

Once the dictionary exists, it does the sorting for you. It already knows where a media plan belongs, what it ought to connect to, and how it relates to a budget and an objective. The work that remains is mostly about making your documents and data available to the layer, and that work pays for itself, because the system gets sharper the more it is used. A team points it at a shared drive, and IT provides the relevant database schemas to begin with. Within weeks, people are adding their own files, their own annotations, the information relevant to their function that until now lived on their local desktop, and each one drops into the web of meaning on its own. It compounds, and it is useful long before it is finished.

You cannot rent a memory

This memory cannot live inside a SaaS platform; that magic solution your vendor is trying to sell you is not memory, and not for a technical reason. A memory layer holds the meaning of your business; it learns your processes, identifies your objectives, knows your strategy, and understands the connections between every function you run. A layer that can span every platform and every department cannot sit inside any one of them, least of all rented from a vendor whose commercial interest is to keep you there. The memory has to belong to the business it describes. You host it, secure it, and walk away with it. Ownership of your own business memory is not a procurement footnote. It is the whole point.

A data lake is a basement full of boxes, a RAG is a catalogue of boxes, and a memory is the colleague who knows where everything is and what it means. One gives you a chatbot that has read your files. The other gives you a system that knows your business, is owned by you, and gets smarter every week that you use it.

That leaves one question. Once you have a memory like that sitting underneath everything, what should you build on top of it?

Next in the series

The final article, One memory, many agents, answers exactly that: how a shared business memory sits underneath your existing stack, owned by you, so every AI tool you have already bought, and every one you buy next, can finally do the job the demo promised.

Fabio Barboza is CTO and Strategic Partner at Forge DC, where he leads R&D on DataBridgeAI and writes Forge Field Notes. He has spent more than a decade at the intersection of data, technology, and commercial pharma. Based in London.