Learn
What is a context layer? What an AI agent should know before it queries your data
A context layer is everything an AI agent should know about your data before it answers a question. That covers what each table and column means and which joins are real, plus the rules a result has to pass, the SQL your team already trusts and the corrections people made last time. A semantic layer is one part of it. The context layer adds the evidence and memory an agent needs to work without someone checking every step.
For a decade, data teams wrote definitions for dashboards, and a dashboard gets built once, by someone who knows the data. AI agents write new SQL for every question. They need to know more than a dashboard ever did, including which parts of the data not to trust. That extra knowledge is what people have started calling a context layer.
A context layer for AI agents has five parts
Meanings
Business names and definitions for tables, columns and coded values. A column called stat_cd holding the numbers 1 to 9 is useless until something says 4 means "dispatched" and 9 means "cancelled by the customer".
Relationships, with where each one came from
Foreign keys declared in the schema, and joins inferred from the data, kept apart. Each inferred join carries its evidence (for example, "98% of shipment references match an order") and a confidence the agent can weigh.
Rules a result must pass
What a sane answer looks like. A percentage of time can't exceed 100%, and a per-account total can't return more rows than there are accounts.
SQL your team already trusts
Saved reports, views and the queries people rely on. They show the agent how the business really computes things, and they become the fixed logic for questions that get asked again.
Memory
Corrections and approved findings, plus a record of what changed. When someone tells the agent that two product_id columns are unrelated, that should still be true next month.
Context layer vs semantic layer
A semantic layer answers "how do we compute this metric?". A context layer answers that and a second question as well: "how sure are we, and why?". If you already run a semantic layer, keep it. It's one of the best inputs a context layer can have.
| Semantic layer | Context layer | |
|---|---|---|
| Built for | Dashboards and BI queries | AI agents writing new SQL |
| Holds | Metrics, dimensions and joins | Those, plus evidence for each join, rules, trusted SQL and corrections |
| Joins | Declared by whoever builds the model | Declared and inferred kept apart, with confidence |
| When something is wrong | Someone edits the model | The correction is recorded and reused |
| Who builds it | Usually analytics engineers, by hand | Increasingly drafted by software, then reviewed by people |
The context layer decides whether an agent's answer is right
Take the question "which customers churned last quarter?". Before writing any SQL, the agent has to decide what "churned" means here (no order in 90 days, or a cancelled subscription?), which customer table to use when the CRM and billing system both have one, how to join to orders, and which accounts to leave out. Without a context layer, each of those is a guess, and four reasonable guesses in a row can still produce a wrong list.
With one, the agent looks up the agreed definition, uses the approved join and applies the standard exclusions. Then it checks the result against the rules before answering. If the check fails, a well-built agent says so. In Antcluster a check can pass a finding, flag it or withhold it, and the evidence travels with the answer.
Where context layers come from
Most teams write theirs by hand, as column comments, wiki pages and YAML files. That context is accurate when fresh and rarely stays fresh for long.
Metadata catalogs can help. Atlan, for example, reverse-engineers joins, filters and business questions from SQL history into reusable context. Warehouse vendors have started too: Snowflake proposes semantic views from query history, and Databricks builds Genie Ontology from governed tables, past queries, dashboards and notebooks.
The last route is to start from the database itself. You profile the data, infer the joins and read the trusted SQL, then have an engineer review the result. This is how Antcluster works.
How Antcluster builds a context layer
Antcluster connects read-only to your databases and builds the context layer from what is already there. Here is what your team can do with it.
Ask questions your business already knows how to answer
Ask in plain language and get the answer with the SQL and records behind it. Nobody has to hand-build a semantic layer first or write SQL for each question.
Capture what lives in people's heads
Antcluster proposes meanings for cryptic columns and coded values, and finds joins nobody declared, using profiles of the data and SQL your team already trusts. An engineer approves or rejects each one. Approved context is then shared by every later investigation and every agent that uses it.
Find connections nobody has made
When sales, operations and finance data share one context layer, you can ask questions that cross teams, such as whether late shipments from one site show up months later as fewer repeat orders. Those come back as candidates with their evidence, for someone who knows the business to confirm.
Why this is possible now
If you've watched a coding agent work, you've seen a harness. It's the working environment around the model: the files and tools it can reach, and the tests that tell it when it got something wrong. Harnesses like Claude Code are a big part of why small software teams now attempt work they wouldn't have scoped a few years ago, porting an entire console game to PC, for instance. Code makes this easier because it carries structure an agent can check against, such as interfaces, types where the language has them, tests and a build that breaks.
Data has far less of that. A schema tells an agent the shape of each value and almost nothing about what it means or how it connects to the rest of the business. That meaning lives with a few people. A context layer is the harness for data work: it gives the agent something to check against, which is what separates a plausible number from a correct one.
Teams that have one stop rebuilding context at the start of every investigation, so they can follow a new question when it turns up. For data engineers that means time for the projects that kept slipping. For people in finance, operations or risk it means investigating directly, whether the company has twenty people or twenty thousand, and spotting risks and problems before anyone had thought to ask about them.
It improves with use
The database, the agent and the context layer develop together. An engineer reviews each finding, and the approved version becomes context for the next investigation. The ontology at the centre is written in OWL 2 and expands itself as approved findings and new tables arrive, so the layer grows with the business. Repeat questions get the same logic, and new questions come with their assumptions listed. Antcluster never writes back to your source database.
An example from a plant database
In one plant database, the values that mattered sat in a single generic answer column, and what each value meant depended on a numeric question ID: one ID was an energy meter, another was biscuit production. To work out energy used per unit produced, the agent had to map the IDs, convert text to decimals, parse dates stored as strings, take meter differences, leave out EV charging and line up consumption with production by business date. None of that is in the schema. All of it is context.
See the context layer Antcluster builds on your data
Bring one database and the questions your team keeps answering by hand. We'll show you the context layer Antcluster builds, read-only, and how its answers compare with yours.
Questions about context layers
What's the difference between a context layer and a semantic layer? A semantic layer defines metrics for reporting. A context layer includes those definitions and adds what an AI agent needs to work unsupervised: evidence for each join, rules to check results against, trusted SQL and a memory of corrections.
Is a context layer the same as context engineering? Context engineering is the wider practice of deciding what goes into a model's context for any task. A context layer is the data-specific part: the stored knowledge about your databases that an agent draws on each time.
Does a context layer need a graph database? It doesn't have to use one, but relationships are easier to store and follow as a graph. Antcluster keeps its graph in FalkorDB. See what is a context graph.