The first chatbot we built at a large enterprise kept all its knowledge in one place: a retrieval layer over a curated set of documents. It worked. Then more use cases landed on the backlog, and each needed the same knowledge: the same procedures, the same work instructions, the same process docs.
That’s where it broke. Copied sources drift. Keep three versions of the same content and, before long, nobody can say which one is true.
So the question stopped being about chatbots. Work instructions, training material, SOPs — content scattered across SharePoint folders and half-forgotten drives. How does any of it become usable more than once?
Most of the AI conversation runs on capability: which model, what the demo showed, how close agents are to real work. The second chatbot pulled my attention somewhere less glamorous: whether the organisation is legible enough for the model.
Fig. 1 — The second is a diagnosis of the organisation.
With one solution, you can build around the mess. Collect the documents, stand up a knowledge base, wire in retrieval, tune the prompts. It works — for that one context.
Then the next one appears, needing the same knowledge. The procedure behind one assistant turns out to drive another workflow. The policy answer customer service leans on resurfaces in an escalation path.
Now there’s a fork. Copy the knowledge into the new solution, accept another silo, move fast today — or read the repeat as a signal that something should become reusable.
If every AI initiative keeps its own private copy of enterprise knowledge, the organisation doesn’t get smarter. It gets more fragmented.
Fig. 2 — Every new use case adds another place where the same content is copied, slightly changed, and slowly drifts from the source.
And there’s a number on this now. A widely cited MIT study found 95 percent of enterprise GenAI pilots produced no measurable return. Most people read that as a verdict on the technology. Read the detail and the failures trace to brittle workflows, weak learning, and organisations that couldn’t feed their systems the context they needed. The models were mostly fine. The organisations were illegible to them.
A useful data product is more than rows in a table. It carries what a second or third solution needs to trust it without rebuilding it from scratch.
Fig. 3 — The unit of reuse is the meaning that travels with the file.
One of those — the interface — now has a standard forming around it: a shared protocol for how systems reach context. Which makes the rest of the list more urgent, not less. A stable pipe to meaningless content is just faster fragmentation.
Most enterprise knowledge was never built for AI to use. It was built for people who already knew what was missing.
It lives everywhere and nowhere in particular — some of it maintained, some duplicated, most of it out of date.
Fig. 4 — The last source is the one no system can index — and the one the organisation actually runs on.
One team knows which document is the real one. A field engineer knows the exception. A senior leader remembers why a call was made three years ago — and that reasoning lives nowhere in the system.
The organisation runs on that tacit knowledge. And AI can’t use what it can’t see.
This is a visibility problem and an ownership problem — which makes it a design problem.
People translate between systems all day — between policy and practice, between the official process and how the work actually goes. They know which source to trust, which field to ignore, which rule is technically correct and operationally useless. Almost none of it is written down. We call it experience.
Leave it invisible and AI works from a flattened version of the organisation. It sees the document, not the judgement. The record, not the exception. The procedure, but never the reason people work around it.
So the answer comes back fluent, confident, and wrong in a very organisational way — wrong the way an outdated procedure is wrong. Outdated procedure? AI scales it. Unclear ownership? AI bakes in the confusion. Same rule in three places? It picks one and can’t tell you why.
That’s the risk we underestimate — and the opportunity hiding inside it. Put a capable system into a workflow and it surfaces everything the workflow was holding together on goodwill and memory.
Fig. 5 — The system does not create these gaps. It makes them legible — sometimes for the first time.
For product and IT leaders, this reframes the portfolio question. Next to “which use cases should we build?” sits a quieter one: which repeated knowledge needs should become shared capabilities? A repeated need is a capability trying to surface.
Fig. 6 — Read the repetition as a signal. The duplicated effort is the shape of a missing shared capability.
This is where service design earns its keep in enterprise AI. It makes the work visible enough to architect: where knowledge is created, where it moves, where it gets stuck, where handovers turn fragile. It shows the gap between the process on paper and the process in use, and translates between what the business means and what the system needs.
That translation matters because a system needs the right information in the right context at the right moment — and that bar jumps the moment you move from assistive AI to anything agentic.
Retrieve, answer, repeat. The context it needs is mostly the question in front of it.
- Know what it is allowed to do
- Discover which capabilities exist
- Retrieve the right context, not just text
- Understand which source is trusted
- Call tools and preserve memory
- Escalate to a human when accountability requires it
Fig. 7 — The jump from assistive to agentic is a jump in how much organisational context has to be made explicit.
Policies become constraints a system can call. Procedures become workflows you can inspect and improve. Tacit knowledge becomes something you capture, test, and maintain — with people in the loop.
The field finally has a name for this: context engineering — getting the right knowledge in front of a system at the right moment. And the finding that comes with it is blunt: most agent failures are context failures.
Multi-agent systems make the same point one level up. We describe them as specialists — one plans, one retrieves, one reviews. But organisations already run that way: distributed expertise, handovers, escalation paths, decision rights. How the agents coordinate is the technical question. What they coordinate around is the one that decides. Fragment the knowledge underneath and the agents inherit the fragmentation.
So the work is to make the enterprise legible before you try to make it reusable. And the questions that get you there are design questions as much as strategy ones.
Fig. 8 — Once an organisation moves from one AI solution to many, reuse stops being a build detail and becomes a leadership concern.
Get this right and a maintenance agent can combine telemetry, repair history, procedures, and incident records — all from sources the organisation actually trusts. The same building blocks serve the customer assistant and the planning workflow. That’s the layer real enterprise AI sits on.
The organisations that get the most from AI are the ones that make their own reality most usable.
Fig. 9 — This starts with mapping, ownership, handovers, tacit knowledge, repeated needs, and shared capabilities.
So the question was never really “which model should we use?” It’s this: what does our organisation need to understand about itself before AI can act inside it — safely, and for more than one team?
Want to test where you stand? Take your two most recent AI initiatives and write down what knowledge both of them needed. That overlap is your first shared capability — and the list usually takes about twenty minutes.
Sources: MIT NANDA — State of AI in Business 2025, Fortune — coverage of the MIT report, LangChain — Context Engineering for Agents, ML6 — MCP and AI agents