The knowledge layer: think big, act small

A knowledge layer is a governed model of what a business means and how it works. It holds the concepts the business runs on: customer, contract, invoice, active customer; with definitions someone has signed off on. It holds the processes those concepts move through, written down step by step instead of living in people’s heads. It is bolted onto the systems that are already running. The data stays in the ERP, the CRM, the contract repository and the data warehouse. The layer only records what that data means and where to find it. Nothing gets migrated.

What that enables is people and agents answering from governed knowledge rather than from raw tables. A person or an agent is served the slice of concepts, rules and process steps its question touches, answers within them, and leaves behind a record of which sources it read, which rules applied and which version of the process it followed. So the answer is grounded and the decision it made can be reconstructed months later.

Concretely, it usually starts with a person asking. An account manager asks how much can be credited to Acme Corp for a late delivery. The answer comes back as €10,000: Acme’s master agreement caps SLA penalties at 10% of monthly invoice value, and the ERP shows €100,000 a month. The clause and the invoices are cited, so the account manager can check the answer themselves.

The next step is an agent that acts on the same knowledge: an agent is asked to issue a €15,000 credit note to Acme Corp for a late delivery. Pointed at a refunds table it would issue it, because nothing in those rows records that Acme’s master agreement caps SLA penalties at 10% of monthly invoice value. Instead, working with the knowledge layer it retrieves the approved credit note process, follows it to that contract clause and to the €100,000 monthly invoice value in the ERP, finds that the requested €15,000 exceeds the €10,000 cap, and routes the case to a human.

The first three posts in this series describe what the layer holds, how it gets built and how it stays accurate. In this post I will go into the question if you should build one at all, and if so: how to start.

Build the business case #

Compared with a point solution, the marginal cost per use case on the knowledge layer falls with each one added. The first use case is more expensive: you pay for the ontology, the source mappings, the platform that stores and serves them, and deeper expert review (not just the output needs to be right, the definitions inside the knowledge layer need to be good enough for other use cases to be built on). The second use case is cheaper, because most of the concepts, definitions and processes it needs already exist. Whether that pays off depends on how many questions over the same concepts, processes and data you have.

With one use case it does not pay off. But picture the credit note agent and a collections agent built as separate projects. One knows Acme as a customer, the other as a debtor account, with nothing linking the credit note to the open invoice. Acme gets a payment reminder for the €10,000 it was just credited. Each point solution works on its own; together they do not. Every new automation requires the links to be created again, or more likely: the links don’t get created at all.

Expert time dominates the cost. Graph databases are cheap and the tooling is commoditizing, so the constraint sits with the people who decide what the model says and check that it is right. The gains below are unlocked when the model describes the business accurately, while the costs are what is needed to keep the model accurate.

The gains #

The gains land in four places: in every individual answer, in what the next use case costs, in what the accumulated execution traces make possible, and in how the model keeps aligned with the business.

Every answer is grounded and traceable. Take the Acme request from the opening, walked through step by step in post 2. The agent correctly declined to issue the €15,000 credit note, because the cap rule sat in the model and the process told it where to look. The answer came out of governed knowledge. Every run also records which sources it read, which rules applied and which version of the process it followed. If the agent made a mistake, then that error could be traced back to a definition which can be corrected. It makes decisions reconstructable, even months later.

Reconstruction is what the EU AI Act asks of high-risk systems in its record-keeping and traceability obligations, so for these use cases reconstruction is a must have requirement.

The next use case is cheaper. What accumulates is the ontology, the source mappings, the reviewed definitions and the processes. The credit note process built for Acme covers the next SLA dispute as well, and the customer and contract concepts it needed are already in place when a churn question arrives. The next consumer does not even have to be AI: a dashboard or an application can read the same governed definitions. Delivery time falls with each use case. The cost of an individual run stays bounded because an agent is served the slice its question touches, so it spends fewer tokens on both the data and on working out how to answer.

The execution traces support redesign. Every recorded run of a process adds to the evidence of how the business actually operates. That makes what-if questions answerable: what happens to lead times if this approval step goes away, which cases would have been decided differently under a different cap.

This is AI-driven business process re-engineering as I described it in the conceptual framework: mapping how the business operates, surfacing alternative designs, training models to simulate them, and monitoring what the changes actually did. Redesigning a process becomes much more grounded in evidence when there is a model of the current process accurate enough to simulate against with evidence of how it really runs. I will come back to this in a later post.

Experts review rather than author. Self-evolution changes what an expert spends their time on. Drafting a class or a process step from scratch is expensive and needs a modeler; judging whether a proposed one is right is something a domain expert can do from their own knowledge, in minutes, from a queue. The expert’s input directly influences how well an agent can carry out work that used to need an expert. If the agent does not make the experts more effective, the layer is not delivering what AI is supposed to deliver.

The review approach is also what lets the model keep up with a business that changes faster than a quarterly model review cycle. Each approved change compounds into the three gains above: more questions land on governed knowledge, more of the next use case is already built and agents act against a model that still matches the business.

The costs #

Four things determine the cost: owning the model, reviewing it, keeping up with a model that keeps changing, and keeping it coherent while it grows.

Ownership is not optional. The layer surfaces that finance and marketing do not agree on what an active customer is, but it does not settle that disagreement. The plurality can be modeled technically, but deciding when plurality is acceptable is a business decision that needs an owner senior enough to make it stick. That is a political cost: senior attention and goodwill spent arbitrating between departments. The same owner keeps the model alive in the long run: without someone reviewing and maintaining it, the model goes stale. A stale map is worse than no map, because agents keep trusting it. Governance abandonment after the project ends is a documented risk for failure.

Expert review is the bottleneck. The people who know how things really work are usually also in high demand for their day job. The recurring failure is exhausting domain experts in refinement workshops, until model maintenance stops. Bootstrapping from governed artifacts and running approve/reject queues instead of review meetings lowers the load without removing it. The ontology and processes are hundreds of concepts that change every few months. Experts need to have time for this work, be recognized for it and benefit from it themselves.

An evolving model drifts. Machine proposals can outpace review capacity, at which point the queue backs up or reviewers end up rubber-stamping, which is why proposal volume against review latency is important to monitor. The citizen ontologists participating in the evolution loop require them to be trained in modeling well enough to judge a proposal, and given tools that fit that job. Both require budget.

One modeling tool I imagine will be very powerful in the age of LLMs is fact-based modeling, in plain English with simple diagrams. It is the language that both citizen ontologists and LLMs can understand.

Growing across domains is challenging. When ontologies need to join across domains, there is a good chance that things break down. This is because the same concept might have different identity or structure. This is fixed by aligning the domains deliberately, which costs review time from someone who can decide cross-domain. The self-evolving loop helps here but does not resolve that: it will surface a cross-domain join that contradicts itself, but then still requires a modeling decision from people who have to agree with each other.

How to start #

Think big, act small. The 2006 lesson has two sides: modeling the enterprise top-down was too slow and rigid to be effective, while delivering increment by increment left us with domain silos we still work around today. Starting well means holding a picture of where the knowledge layer is going while building only the part the current question needs.

Name the owner before modeling anything. Someone accountable for the model, data owners for the domains it touches, and experts who can validate. Arranging this after the first use case means users rely on ungoverned definitions and data. Potential owners will need to take ownership of something that is not their own, instead of being involved from day one.

Start with one use case in a domain that supports multiple. Select a business domain that has a well-defined set of data, and a portfolio of use cases that are valuable and will benefit from a knowledge layer. For the first use case, pick one that has reasonable value, committed stakeholders and required data available, usable, and well-documented. Conversational analytics is a good first candidate: a person judges every answer, so the risk is low, it only needs the what of the model, and every correction users make improves the definitions. Agents that act, and need the how and guardrails, follow once the model has proven itself.

Lay just enough foundation to serve that use case. Start with an industry-standard ontology and create the minimum viable ontology and minimum viable graph needed for the use case. Build just enough platform: a store for the graph, sources relevant to the question mapped, and the processes used. Everything else in the architecture can be added later. Get data in the hands of users as soon as you can, so both value and feedback arrive fast.

Budget expert hours as the real constraint. Bootstrap from the governed artifacts that already exist: glossaries, BI logic, lineage, ETL code and runbooks. Experts will then review a draft instead of starting from zero. This is the difference between an hour of their time and a series of workshops. Data quality gets the same treatment: improve what this question requires, since “good enough for this question” beats abstract perfection.

Repeat. The second use case adds concepts, sources and users to what is already there, so that the platform grows with the demand rather than ahead of it. Once several use cases run at the same time you are out of the starting phase and into ontology operations.

The differentiating work sits in value creation and operations. Graph databases, mapping tools and the modeling ideas themselves are all available and mostly decades old. What decides success is whether the model outlives the project that initiated it. The first use case has to deliver on its promises, but the second use case is what proves its value: if the concepts, definitions and processes it needs are already in place, and it takes less time and money than the first, the layer is working as intended. If it pays the full modeling cost again, you have built a point solution at the price of a platform.

Should you build one? #

Twenty years ago the data warehouse made the same promise, but never fully delivered. What has changed since 2006 is not the modeling thinking, but the consumer. Back then analysts could work around an inaccurate model. Conversational analytics already moves that interpretation from the analyst to the AI. Agents do not have the context to see the inaccuracies, yet will still act. That is why agents need the knowledge layer to get the full context of the organization. You need to decide if you want to build and maintain it.

Structure that decision around more than one use case. Write down the questions the business wants answered, look at which ones share the same concepts, and start in the domain where they overlap most. A single use case justifies a point solution; only a cluster justifies a layer.

Then check what each use case gives back to the experts, beyond the other value it delivers. Expert attention is the scarce input, so it should also be the return: hours given back, work they used to do themselves that an agent now does under their supervision, or a definition that stops being re-argued. Traceable AI and reduced token spend are valuable, but not the primary value drivers.

I have not yet built a full knowledge layer end-to-end and I have not spoken to anyone who can show what running one gains over several years. Implementation has started and I feel confident this is the right direction. I will share my findings as I learn.