The contextual layer, part 1: a story

September 30, 2026

A story first

A few months ago, the contextual layer was one of the themes of a Gartner conference in London. Since then, with (autonomous) agents on everyone’s agenda, it has become the talk of the town. Yet a lot is still unclear: what a contextual layer is exactly, how you build one, and if you actually need one. My first understanding of it became two posts, and this is the first.

I did what I usually do when a topic is new to me: I bought a few books. The two that helped most were Bridging Knowledge, Data, and AI (2026) and Knowledge Graphs and LLMs in Action (2025).

This post is a bit different from the others. Some of the books about work I have enjoyed most are stories. Patrick Lencioni wrote several, such as The Five Dysfunctions of a Team (2002). Gene Kim did the same for IT with The Phoenix Project (2013, with Kevin Behr and George Spafford). They start with a story, and by the time the theory arrives you already know why it matters.

This post is my small tribute to Lencioni’s and Kim’s books. It follows a new colleague through her first few days, and ends with what would have happened if she had been an agent. The theory follows in part 2.

Amira’s first week

Day one

Amira started on a Monday at Bolle.com. For years the company had sold only to consumers: books, toys, kitchen gadgets, the things people order on the app at eleven in the evening. Two months ago it had opened up to businesses as well.

Her CV was the strongest the team had seen in years, so they gave her the recommendation engine: the row “Often bought together” under every product in the app. It was the team’s flagship, because a significant share of the company’s sales came through that row. Her team lead Rahul added that it was also the system most likely to wake you up at night.

Rahul walked her through the model. It was trained on consumer data a few weeks before she started, and it looked at two things:

1. What each customer bought and searched for in the app.
2. What customers in general bought together, counted across all orders of the past weeks in the orders table.

For a new customer without any history, the second was all it had.

Every night, the bought-together numbers were recalculated and the model predicted recommendations for more than a million customers. The results were stored in a fast database behind the app, ready for the moment someone opened it.

She asked for access to the wiki, the data platform and the monitoring tools. That would take a few days, Rahul said. It always did.

Day two

It was the week before the schools started, the busiest week of the year for anything that goes in a school bag. Amira spent the day reading code, the one thing she did have access to. The recommendation engine was hers now, and she wanted to know it inside out.

Late in the afternoon a message appeared in the company news feed:

Tonight, business accounts and their orders move to the central order platform.

Everyone in the team read it, Amira included, and everyone came to the same conclusion: we work on customers, not accounts.

Day three

At half past nine in the morning, customer service got in touch. A parent had bought a single ballpoint pen for school, and the app had suggested forty boxes of A4 paper, a pallet of coffee pads and an office chair. By ten in the morning the screenshot was on social media, and it was about to go viral.

Three days in, the flagship was in trouble, and Amira wanted to show she could handle it herself. She opened the one dashboard Rahul had shared with her. Everything was green: no errors, no failed jobs, and the model’s scores looked normal. The team had a proper machine learning operations (MLOps) setup, so going back to the previous model version took two clicks. She did it and ran the predictions again for a sample of customers. Nothing changed. The previous model recommended pallets of coffee pads just as happily. Whatever had changed, it was not the model.

She needed someone who knew the data. The wiki still said “access pending”, so she asked a colleague, who let her read it over his shoulder. The page on the recommendation engine said: “Owner: Marieke”. Marieke, head of e-commerce, had already seen the screenshots. She asked if Amira could switch the recommendations off until it was fixed. In the busiest week of the year, that meant giving up a large share of sales. And Marieke owned the row in the app, not the data behind it. She could not tell her what the engine learned from.

Amira asked to see one more page, the one describing the data: “Customer: anyone who has placed an order.” Nothing wrong with that. Nothing she could use either.

At half past twelve she found Tomasz, who had built most of the order platform, eating a sandwich at his desk. She showed him the screenshot, and he started laughing before she had finished her sentence.

“The business accounts,” he said. “They moved onto the central platform last night. They’re in the orders table now. Companies buy paper by the pallet. And they order everything at once: pens, paper, coffee, a chair for the new intern.”

“Accounts?”

“Business customers. We call them accounts.”

Amira thought of the message she had dismissed. So had everyone in her team. Nobody had warned them, because nobody in Tomasz’s team knew that the recommendation engine learned from their table. He opened the orders table on his screen and pointed at one column, customer type, with two values: consumer and business. Every row marked business had arrived the night before.

Amira left the business rows out, recalculated what consumers bought together, and looked up the pen again. Notebook, pencil case, highlighters. Then she ran the predictions for all consumers, and by the end of the afternoon a parent buying a pen saw a notebook next to it again, not a pallet of coffee. By the evening, sales through the row were back to normal.

That evening she wrote a short note for Rahul:

What happened: from this morning, consumers buying school supplies were recommended bulk office supplies, and sales through the recommendation row in that category halved.

Why: last night, business accounts moved into the orders table. Our bought-together numbers count every order in that table. Business orders are large and contain many products at once, so in office and school supplies they outweighed the consumers. The model itself was fine; rolling it back changed nothing.

Fix: business orders are left out of the bought-together numbers for now.

Still open: business customers have been getting consumer recommendations for two months. A company ordering a pallet of coffee is offered a single pen. Nobody has noticed yet.

Then she saved Tomasz’s number in her phone.

Now replace Amira with an agent

Imagine Bolle.com had given the recommendation engine to an agent instead of Amira. In some ways, it would be a strong candidate. It has read nearly everything ever written about recommendation systems. That is what pre-training gives it.

The agent would probably also have had better access. Amira waited days for the wiki, the data platform and the monitoring tools. An agent can reach systems like these from the first minute, as long as they have been set up for it. The usual way is the Model Context Protocol (MCP), a standard that lets an agent ask a system what it offers and then use it. Internal systems typically do not have MCP out of the box, so someone has to build it. For this story, assume Bolle.com had.

So how would its third day have gone? It would have seen the screenshots and the green dashboard. It would have rolled back the model, seen nothing change, and looked further. It would have read the wiki page and contacted Marieke, because the page says she is the owner. It would have read “Customer: anyone who has placed an order” and concluded that the data was fine. It might even have read the message in the news feed. Whether it connected “business accounts” to its own “customers” would have been a guess.

What it would not have done is walk past Tomasz’s desk. Amira solved the problem because she found the one person who knew what “customer” meant that week. And what she learned that day stays with her. Unless someone writes it down in a form an agent can use, the agent starts its next task where it started this one.

Access was never Amira’s real problem. Meaning was. That is the gap a contextual layer fills.

Part 2 describes what that layer is, the four steps I currently believe it takes to build one, and if you really need one, with Amira’s day as the example throughout.

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