The Knowledge Problem

Most organisations adopting AI hit the same wall. The early wins are real: people write faster, summarise better, and answer questions more quickly. But a few months in, you notice the way the team actually works hasn't changed. AI is sitting on top of everything, touching nothing underneath.

This is a knowledge problem rather than the tool problem many think it is.

I've been exchanging ideas on this with Victor, our CEO, and the conversation sharpened something I'd been circling: the problem is how organisations think about knowledge in the age of AI.

Knowledge and context are not the same thing. And this is the distinction that unlocks everything else.

Knowledge is the raw material: documents, emails, project files, proposals. Most organisations have more of it than they think, spread across SharePoints, inboxes, and, in consulting, client systems.

Context is the interpretive layer on top. It tells an AI how to connect knowledge, what matters, and why. It's the difference between an AI that retrieves a document and one that reasons across your whole system of work (what we call at Riverflex a WorkOS, or Work Operating System).

Many AI implementations today are built on RAG (Retrieval-Augmented Generation): connect a language model to your documents so it can answer grounded in your actual knowledge, not just its training data. RAG is a good foundation, but retrieval is not understanding. Enterprises have landed in a contradictory position: they feel they cannot live without RAG, yet remain deeply unsatisfied with the results. The reason is usually not the model but the absence of a structured context layer. Without one, a RAG system reads your files the way a new hire reads a shared drive on day one - i.e., it can find things, but it doesn't know what to make of them.

Context also needs active management, especially because enterprise knowledge changes constantly, documents get updated, projects close, teams restructure. A static context layer will quickly start producing answers that are plausible but wrong.

Decision memory is the layer most teams never reach. It's the accumulated trace of past reasoning, approvals, and judgements that makes an AI's actions auditable and, over time, genuinely better. Where context tells an AI how your organisation works, decision memory tells it how your organisation thinks. A concrete example: imagine a procurement team whose AI has access to every supplier contract in the system. Without decision memory, it can retrieve contract terms. With it, it can recall that a particular clause was explicitly waived in a prior negotiation, and why, and apply that judgement the next time the same situation arises.

Building these layers, particularly the context layer, doesn't happen automatically. Someone has to play the role of "librarian": go through the knowledge base, label what's good, connect what's related, surface what matters for a given type of work. In most organisations, no one internal has the time or the distance to do that well, which is usually where an external party comes in. Someone who can look at the knowledge base without the assumptions baked in, and build the context layer with fresh eyes.

We see this play out repeatedly with clients. A European retailer we worked with recently had invested in an AI agent for their commercial team, connected to their documents and ready to act. But without a clear context layer, it had no reliable way to interpret what it was retrieving or why it mattered for a given task. It could find things but couldn't do anything useful with them.

If you're building toward this kind of system, there are three mistakes worth avoiding:

Three mistakes worth avoiding

Mistake 1: Building context on top of broken data

A context layer built on poor knowledge is just a faster way to get poor answers. If your documents are inconsistent, outdated, or filed in ways that made sense five years ago, that's the first problem to solve. AI can help with the cleanup, but context architecture is not a workaround for messy data.

Mistake 2: Assuming more context means better outputs

The instinct is that more context means better outputs. The opposite is true. The more you feed a model, the more it drifts. What you want is value density: the minimum context that carries the maximum signal. Think of it like a briefing for a new consultant. You wouldn't hand them 400 pages. You'd give them ten, and tell them exactly what to focus on.

Mistake 3: Treating this as a cleanup project, not a system design

The temptation is to organise what you have, build the context layer, and call it done. But if the system for filing new information is still broken, you'll be cleaning up again in six months. The more durable investment is designing the system for what comes next. Build the new house first, move the good stuff in, leave the rest. Gartner predicts that by 2028, 33% of enterprise software will include agentic AI capable of handling complex tasks and making decisions, up from less than 1% today. The organisations that design their knowledge systems now will be ready for that shift. The ones that don't will be retrofitting.

Get this right and AI starts to drive value beyond the individual.

Imagine every project with its own AI workspace. Every team with a context document that both humans and the AI read, and when that document changes, the AI's understanding changes with it. A shared agreement between your team and your AI collaborator on how you work together.

This is also where AI in organisations is heading. The next step beyond answering questions is completing work: agents planning, retrieving, acting, and handing off across a team. But agents without good context are unpredictable. The organisations investing in context architecture now, are building the foundation that those agents need to be useful rather than chaotic.

There's one more reason to do this work now rather than later.

The harness. The system that connects your AI to your knowledge, routes tasks, and manages how context is passed between agents and tools, is built once and reused as models improve. When a more capable model is released, it slots into the same infrastructure and immediately performs better against the same context layer you've already built. We've seen this directly in our projects: harnesses that produced mediocre results on earlier models started delivering genuinely useful output once a more capable model was dropped in. The investment compounds. Which also means the inverse is true: if your data and context are poor, better models don't save you. They just produce wrong answers faster.

The organisations that figure this out in the next three months will have built something genuinely hard to replicate: an enterprise whose intelligence compounds as the team works, instead of resetting every time someone opens a new chat window.