A Context Layer Tells an AI Agent What the Data Means
A context layer is the curated knowledge an AI agent reads before it answers a question about your data. It holds the things a new analyst would learn in their first month: what each metric means, which table is the trusted one, which terms are synonyms, which comparisons are misleading, and which rules apply to whoever is asking.
The term is new and vendors do not use it the same way. Some mean a product that serves this knowledge to agents; others mean the knowledge itself. In this entry it means the content: the context an agent needs, wherever it is stored.
Why AI Agents Need It
A language model connected straight to a database sees table names, column names and maybe a few comments. From that it has to guess what amt_net means, whether status = 3 is a cancelled order, and whether last quarter's revenue should include refunds. It will guess fluently, which makes a wrong guess hard to notice.
A context layer replaces the guess with a written answer. Typical failures it is meant to prevent:
- Wrong metric. The agent sums gross order value when the business reports net revenue.
- Wrong source. It queries a staging table that is still being backfilled instead of the reporting table.
- Wrong comparison. It compares two regions whose fiscal calendars differ.
- Wrong audience. It answers with data the person asking is not allowed to see.
What a Context Layer Contains
There is no fixed standard yet, but most designs include the same parts.
- Definitions. Business terms tied to the exact metric or column they refer to, with synonyms people actually type ("sales", "revenue", "bookings").
- Relationships. Which entities connect and how, often borrowed from the semantic layer rather than restated.
- Examples. Questions with their correct answers or correct queries. Worked examples are often the fastest way to show an agent what "good" looks like.
- Caveats and rules. Known data gaps, metrics that must not be summed, date ranges to avoid, and policy rules such as which fields are sensitive.
- Provenance. Who owns each definition and when it last changed, so an answer can be traced back and a stale definition can be found.
Context Layer, Semantic Layer and RAG Compared
| Semantic layer | Context layer | RAG | |
|---|---|---|---|
| What it is | Executable metric definitions | Curated knowledge for agents | A retrieval technique |
| Main question it answers | How is this metric calculated? | Which metric fits this question, and what should the agent know about it? | Which information is relevant to this prompt? |
| Who mainly reads it | Query engines and BI tools | AI agents and assistants | The model, at prompt time |
| Runs queries itself | Usually yes | Usually no | Only when retrieval includes a query |
The three work together. A semantic layer makes the calculation consistent; a context layer helps the agent pick the right calculation and explain it; RAG or a protocol such as MCP is one way of handing that context to the model when it needs it.
Where Access Rules Fit
A context layer can describe who may see what, but describing a rule is not enforcing it. If an agent is allowed to query data on behalf of a user, the restriction has to be applied where the data is read, through row-level security in the database, the semantic layer or the service in front of them. An agent that connects through one shared service account can slip past a policy that only sees that account. In a multi-tenant product, the context layer can tell the agent that tenants exist; the data path must make sure it only ever reads one.
What a Context Layer Does Not Solve
It does not make bad data good. An agent with perfect context will still report a wrong number if the source table is wrong. It also does not guarantee the agent uses the context it is given: models can ignore or misread instructions, so answers still need a visible definition and a way to check them. And it needs maintenance. A context layer written once and never updated becomes a confident source of outdated answers.
How to Start
Start small and measurable:
- Pick the ten questions people ask most often about your data.
- For each, write the metric it should use, the table it should read and one correct example answer.
- Add the caveats someone on the data team would mention out loud.
- Test the agent against those ten questions before and after, and keep the test set as the layer grows.
The work is mostly writing down what experienced people already know. The test set is what tells you whether the agent has learned it.