The contextual layer, part 2: what it takes

October 1, 2026

This is the second of two posts about the contextual layer. Part 1 tells the story of Amira, new at the fictional online shop Bolle.com, who is given the recommendation engine. On her third day, a parent buying a single pen was offered a pallet of coffee pads. The model was fine. It took Tomasz, who had built the order platform, to explain that business customers, “accounts” in his team, had moved into the orders table overnight. An agent in her place would have had better access to the data, but not that knowledge.

This post is about the layer that holds that kind of knowledge: what a contextual layer is, the four steps I believe it takes to build one, and if you really need one. Like part 1, it draws on two books: Bridging Knowledge, Data, and AI (2026) and Knowledge Graphs and LLMs in Action (2025).

What a contextual layer is

A contextual layer sits between your data assets and the agent that uses them. Data assets can be anything: tables, documents, people, skills. The layer holds what things mean in your organisation: which words mean what, which kinds of things exist, how they relate, and where they live in the data.

As I currently see it, you build one in four steps, each resting on the one below. The books cover more than this, so it is not the full picture, but each of these four shows up somewhere in Amira’s day.

Step 1: a business glossary

A glossary records what words mean, and which other words mean the same thing. At Bolle.com, two words caused most of the trouble.

“Customer” meant consumer to Amira’s team, because until two months ago that was the only kind there was. To Tomasz’s team, a business customer was an “account”. Both were right within their own team. Because nobody had written down that the two words overlap, the one message that mattered went past Amira unnoticed.

The same goes for “owner”. Marieke is the owner of the recommendation engine, but she is its business owner. Amira needed whoever was responsible for the data, and the wiki did not tell the difference.

The important part is agreement. A glossary only works if people across the organisation, or at least within a domain, accept the same definitions and the same synonyms.

Step 2: an ontology, or knowledge model

The ontology describes which kinds of things exist and how they relate to each other. For Amira’s day, a small one is enough.

Read each arrow as a sentence. An application has a business owner and a technical owner, and both are people. An application learns from a dataset. A person is a member of a team, and a team maintains a dataset. A change modifies a dataset and is carried out by a team. A document describes a change.

The change deserves its own place in the model. At Bolle.com the news post did not change the orders table, the migration did. The news post was only where someone had written it down. Once a change is a thing of its own, you can ask what changed, when, who did it and what it touched, and the document becomes the evidence rather than the event.

One relation is deliberately missing: a single, general “owned by”. The wiki page had exactly that, and it sent Amira to Marieke. Putting it in the model would only copy the confusion from the wiki. The model forces you to be precise where the wiki was vague.

Step 3: mapping the data

The model describes kinds of things. The mapping connects it to what actually exists. Many people think of tables at this point, but the strength of this approach is that any data asset can be mapped onto the same model.

In Amira’s story, the orders table is structured data. The click data from the app is semi-structured. The news post and the wiki pages are documents. The migration itself is a change, which you might find in a release log or a planning tool. Marieke and Tomasz are people, with skills worth knowing about: Tomasz built most of the order platform. Systems, products and locations could be added the same way.

Step 4: the knowledge graph

The knowledge graph is what you get when the mapped data fills the model.

If you know object-oriented programming, you can think of the ontology as the class and the graph as its instances. It is not an exact match, but it helps. The model says that every application has a technical owner. The graph says that the recommendation engine’s technical owner is Amira, that it learns from the orders table, that Tomasz’s team maintains that table, and that on Tuesday night a change carried out by that team modified it.

With that in place, Amira’s morning becomes one question: what has changed recently in anything the recommendation engine depends on, and who knows about it? The graph follows the arrows from the engine to the orders table, finds the change that modified the table on Tuesday night, and from there reaches the team that carried it out, Tomasz, and the news post that described it. An agent can ask the same question, and it can show the path it took, so a person can validate the answer.

The path works in the other direction too. Before the migration, Tomasz’s team could have asked which applications learn from the orders table, and warned Amira’s team.

None of this is new with agents. A contextual layer already helps search, reporting, and people finding their way around the data. Agents just need it more, because they cannot walk past someone’s desk.

It only works if the earlier steps are right, though. Without the glossary, nothing links a news post about “business accounts” to the “customers” the engine learns from. Without the model, there is no difference between the owner Marieke is and the owner Amira needed.

What it gives you

You could also skip all of this: give an agent access to every table, schema and document you have, and hope it picks the right data. That is usually not a good idea. Sometimes it will pick right, sometimes it will not, and from the outside you cannot tell which is which. The agent at Bolle.com would have found an orders table, a customer column and a wiki page, and put together an answer that sounded right.

With a contextual layer, the agent follows the paths in the graph instead of finding its own way through the data. Every answer comes with the path it took, so you can trace it. Every definition and every relation has an owner and a source, so you can audit it. Where the answer is a lookup, the same question follows the same path, so the answer is the same every time. And because the definitions are agreed on, not guessed, people have a reason to trust what the agent does with them.

Amira’s note to Rahul was exactly that: what happened, why, and what she changed. A contextual layer gives an agent the means to write the same note.

Start with one use case, grow one layer

Both books give the same advice: start from a use case, not from your data. If you map everything you have, with every technique available, you get an enormous graph, and most of it has nothing to do with the problem you are trying to solve. At Bolle.com, one question was enough to start: what does the recommendation engine depend on, and who can I ask?

The next use case, say pricing or customer service, reuses most of that model: applications, people, teams, datasets. It adds a few of its own. That is where the leverage is. Not one contextual layer per use case, but one layer that grows with each use case. Separate layers would each define “customer” again, and you would be back where Amira started. Questions that cross use cases, such as which applications depend on the orders table, only become possible when there is one layer to ask them of.

Which of the four steps is the hard one?

The knowledge graph sounds like the hardest part, probably because it sounds technical and complex. But the technology behind it has been proven for more than twenty years. The Resource Description Framework (RDF), a standard for describing things and how they relate, became a recommendation of the World Wide Web Consortium (W3C) in 1999. Google made the term “knowledge graph” familiar in 2012.

The mapping has become much easier. Once you have a model and access to the data, connecting a table, a document or a person to it is work that LLMs do well. The result still needs validation, but you no longer write every mapping by hand.

The ontology is driven by subject matter experts. They know which kinds of things matter and how they relate, and they decide what goes into the model. An LLM can help along the way: it can go through your documents and data, pick out what is mentioned and how things relate, and propose a first version or a missing relation for the experts to discuss.

I believe the glossary is the hardest of the four, but that depends on the organisation: how many people are involved, how they work together, and how complex the domain is. A small team in one domain can agree on what “customer” means over coffee. An organisation with dozens of teams, each with its own systems and its own history, cannot.

That may also be where the difference lies. If the technology is available to everyone, the graph itself is not what sets you apart. How quickly you can agree on what your words mean, and how things relate, might be. And because the layer grows one use case at a time, every agreement you reach makes the next use case easier.

Do you really need one?

I am not sure yet. If your agents only answer questions that a person reads before acting, good documentation and search may be enough for now. It starts to matter when agents act on their own, when teams use the same words differently, and when you need to explain afterwards why an agent did what it did. On her first day, Amira did not need one either. She needed it on day three, when nobody who knew was around. That is the situation an agent is always in.

No sponsored or affiliate links. If something here is new to you, the link is an easy way in.