Context layer: what your AI sees and with what permissions

The context layer is everything an AI system has in front of it at the moment of answering: which sources it sees, where they come from, in what order they're presented and under what permissions. The discipline of designing that is called context engineering. It isn't about the model, or the prompt. It's about the information that reaches the model before it writes a single word.

It's the part that decides whether the answer is useful. An excellent model with the wrong context gives you a flawless, false answer. A mediocre model with the right context gives you something you can use.

So much for the definition. The rest of this article is the part almost nobody is writing: what this means if you run a forty-person consultancy and have no data team.

Isn't that the same as RAG?

No. RAG, retrieval-augmented generation, consists of finding documents similar to the question at query time and passing them to the model. It works, and it's the basis of nearly every assistant on the market. But it's one piece, not the system.

Context engineering contains that piece and four more: what the system remembers from before, what quality the incoming data has, what policies are applied when retrieving it and how everything is assembled before answering. Atlan separates them like this: RAG answers «which documents resemble this question?»; context engineering answers «what does this system need to know, now, to get it right?».

The difference shows better with a case. Someone asks: «what discount do we apply to this client?». RAG returns the three documents where the word discount appears most. One might be the current policy, another a draft from two years ago and the third an email from a salesperson negotiating a one-off exception. All three resemble the question. Only one is the answer. Deciding which one governs, which is expired and who has the right to see which: that is the context layer.

And doesn't the chatbot's memory already do that?

They get confused a lot, and separating them is probably the most useful thing in this article.

Memory has agent scope. It makes an assistant smarter with one user, in one conversation. It remembers that you work in operations and that yesterday you asked about the same supplier. It's a real improvement and you notice it straight away.

The context layer has business scope. It makes every system in the company get things right more often over time, because they share the same version of what is true in here. So that «active client» means the same thing when sales asks as when finance asks.

A company can have memory in five different tools and still have no context layer. In fact that's the norm. Five assistants remembering five different things and contradicting each other are not a living memory of your company: they're five loose memories.

Why does this matter to you if you have no data team?

Here's the problem with almost everything published about this. The people naming the category (Atlan, Snowflake, Tellius) sell to companies that have a chief data officer, a catalogue and documented lineage. They write for that reader, and rightly so. But that isn't you.

The translation is short: you don't have to build a context layer. You have to know it exists so you can ask about it. The context work gets done in your company either way, whether anyone calls it that or not. Either the vendor does it by design, or you end up doing it by hand every time you correct a bad answer, resend the right document and explain to someone that that PDF is no longer valid.

That second option costs money too. It just doesn't appear on any invoice.

What exactly happens when context is missing?

The worst thing that can happen happens: the system answers just as fast, with the same confidence, and gets it wrong. It doesn't fail out loud. It fails in a normal voice.

The figures circulating about this come from the material of the very vendors defining the category: Atlan and Tellius, among others. There you'll read that 57% of companies traced some confident but incorrect answer back to absent or inconsistent business context, and that 38% used document retrieval as the default route to obtaining that context. Also that declared trust in fully autonomous agents fell from 43% to 27% in a year, and that only 7% say their data is AI-ready.

A warning, because I mean it: those are vendor surveys, not audited independent studies, and whoever publishes them sells the solution to the problem they measure. I'm not giving them to you as facts. I'm giving them to you because they all point in the same direction and that direction matches what you see in any real rollout. If someone shows you the 57% on a slide without telling you where it comes from, distrust the slide.

The predictions go the same way. Snowflake argues that agent context, not the model, will be the main product as models become commoditised. Gartner reckons that by 2028 context engineering will be present in 80% of enterprise AI tools. These are predictions, not measurements: they're worth something as a signal of where the sector is heading, not as data to decide anything on.

Why do permissions belong inside the definition?

Go back to the first sentence: what the system sees, from which sources, in what order and under what permissions. That last clause doesn't usually appear in other people's definitions, and it's the one that costs most to omit.

A context is built by finding what is most relevant to the question. Relevant doesn't mean permitted. If the permission is checked after assembling the context, the restricted fragment has already travelled from the database to the application and all you have left is trusting a filter written in code. The mechanism, with its example, is taken apart in why AI assistants leak information.

That's why «under what permissions» isn't a compliance tag stuck on the end. It's part of what a well-built context is. A context that includes the salary table isn't a correct context missing a filter: it's a badly built context.

Where does the context of a forty-person company come from?

From where it already is. Nobody is going to sit down and write the house manual: that has never worked and isn't going to start now.

An SME's context lives spread across three places. The documents that already exist. The work conversations where things actually get resolved. And the heads of three or four people, which is where the good stuff is and what has never been written. The first two can be captured without asking anyone for anything. The third is the hard one, and it's where it's decided whether you have a system that learns or a search engine with a chat. I covered it in AI knowledge management; what interests me here is the fit. That work is building a context layer, even if nobody calls it that when selling it.

And there's a part you won't be able to delegate. When two documents contradict each other, deciding which governs is a business decision, not a technical one. No tool is going to take it for you, and the one that says it will is lying. What a tool can do is show you the clashes instead of hiding them under a well-written answer.

And the day AI acts instead of answering?

The arc is predictable. First the system retrieves context. Then it advises with it. And one day it executes: it places the order instead of explaining how orders are placed.

That jump isn't only technical. As soon as a system acts instead of answering, its regulatory position changes and so does who answers for its mistakes. An assistant that gets it wrong produces a bad answer somebody can review. An agent that gets it wrong produces a fait accompli.

I mention it because it's worth holding in mind when choosing today, not because it's what we do. Savia answers, it doesn't execute. There are no autonomous agents, no actions on your systems and I'm not going to promise you a roadmap that doesn't exist yet. Which box of the EU AI Act this service falls into, with the articles in front of you, is on the security page.

What to ask, then?

All of this reduces to one question you can ask without knowing anything about architecture, in a meeting, in front of whoever is selling it to you: «show me what the system saw in order to answer this».

If they show you the specific fragments, which document they came from, what date they are and why that person had the right to see them, there's a context layer behind it. If they show you only the answer, you have a demo. Demos are easy to make and very hard to maintain for six months.

If the engineering side is your thing, there are practical guides on taking context engineering to production. But if your job is to decide and not to implement, the question above is more than enough.