Category
What is a context layer?
A context layer is the approved record of how an organization's data and business work: the definitions, rules and documents an AI agent consults before it acts. It sits between your data stack and your agents. It is not another agent. It tells any agent what “revenue” means here, which of four look-alike tables is official, and which exception has applied since 2025.
People pick that up over about six months of onboarding. Agents never do, because nobody wrote it down where they can read it. It lives in unused YAML, Slack threads, PDFs and a few people in the company. A context layer writes it down, the team approves it, and agents receive it when they answer.
Where the term comes from
The clearest articulation is “Your Data Agents Need Context” (Jason Cui and Jennifer Li, a16z, March 2026). Their diagnosis: data agents fail in production for reasons that have little to do with the model: brittle workflows, no contextual learning, a mismatch with how the business actually operates. The missing knowledge, which they call tribal knowledge, exists in every company. It is just never where the agent looks.
Their proposal is a context layer: a corpus where code sits next to natural language, kept up to date, refined by people and exposed to agents in real time. They break it into five components. The vocabulary of the category (tribal knowledge, abstention, typed citation, provenance) is defined in the glossary.
The five components, and where Renbase stands
This map includes what is not built yet.
- 01
Access to the right data
Reach the knowledge agents actually need, including tribal knowledge in internal systems, shared drives and chat threads, not only the warehouse.
In RenbaseDocuments are indexed with the rest of the corpus: PDFs, DOCX and HTML come in through asynchronous ingestion, next to dbt artifacts and warehouse schemas via connectors. Slack and Drive connectors don't exist yet.
- 02
Automated context construction
Use LLMs to extract definitions from what already exists (dbt, LookML, query history) instead of asking people to write a corpus by hand.
In RenbaseConnectors extract draft entries from dbt artifacts and warehouse schemas, without creating duplicates. Extraction from query history is not built yet.
- 03
Human refinement
The most valuable context is implicit and conditional; only the team can confirm it. Machines propose, humans decide.
In RenbaseEverything a machine produces lands as a draft, and nothing governs an answer until a human approves it. Feedback on a bad answer can be promoted into a permanent rule.
- 04
Agent connection
Expose the corpus to agents in real time, over API or MCP, so context arrives when they answer, not in a stale export.
In RenbaseMCP (Streamable HTTP) and REST with per-tenant API keys. Five tools: get_definition, search_context, list_entities, expand_source and ask.
- 05
Self-updating
A corpus that notices when its sources change, instead of going stale while agents keep answering.
In RenbaseConnectors re-sync and compare against their sources. Changes produce new drafts for review. Sources that disappear mark entries as stale. Last-verified dates travel with every answer.
What a context layer is not
Not a semantic layer. Semantic layers (Cube, dbt Semantic Layer) model metrics over tables, and they do it well. What doesn't fit their YAML is the conditional part (“for CRM, new USCAN deals since 2025 live in Affinity”) and the documents where policy actually lives. A context layer reads your dbt. It does not replace it.
Not a data catalog. Catalogs like Atlan are governance products for humans: lineage, quality, stewardship workflows. A context layer is consulted by agents at answer time, and its unit of value is the approved definition, not the inventory.
Not RAG over your wiki. Retrieval finds the most similar text. When an agent asks what “revenue” means, it needs the approved answer (one entry, one version, one approver), or “I don't know” when the context is missing or in conflict. That contract is an architecture decision, not a prompt. The docs compare this in detail against managed RAG platforms.
What Renbase does not do
Renbase serves context; your agent acts. It doesn't run or generate SQL against your warehouse, and warehouse credentials never leave your side. Schema introspection runs as a client-side CLI that only submits drafts. The product direction is for the layer to also verify approved SQL against its sources on every re-sync, and later to compose queries from approved definitions. That is direction, not a date. Running queries on definitions nobody verified is the agent the a16z piece describes failing.
It is also not lineage, data quality or stewardship tooling. If you need those, you need a catalog too. The two work side by side.
How it compares to what you already run
Each of these covers one boundary, including when the other tool is the better choice:
- Semantic layer vs. context layer : what dbt and Cube model well, and what doesn't fit their YAML
- vs. managed RAG platforms : Bedrock, Vertex and Azure sell retrieval; a context layer sells an approved answer
- vs. Snowflake Cortex Analyst : where the warehouse boundary stops
- vs. the dbt MCP server : the closest neighbor, and why they compose
- vs. Databricks Genie : instructions in a space are not governed definitions
Try Renbase with your own glossary.