The New Context Layers: Names and Joins (and that’s about it)

10 context layer tools compared: virtually all ship fields for the two base layers of meaning. One open source context layer framework is deep enough for agents to produce trustworthy insights.

TL;DR. Virtually all context-layer tools — both standalone and those built into the popular and incumbent data platforms — ship fields for 1) a metric’s name/description/aliases, and 2) how it joins to other models. None expose the deeper analytical context as discrete, queryable, checkable fields: what counts as good, where to investigate movement, what other metrics are affected, and what action to take. That is where analysis becomes insight, and where a plausible, confident answer can be both wrong and costly.

The silent failure trap in agentic analytics

Getting accurate, trustworthy data back from an agent is a well-known challenge for AI data applications. Semantic layers have surged in popularity because they lay down deterministic rails for agents to use: get in and get out via the same data definition every time, instead of working out the SQL query on each call. But data pulls are among an analyst’s most basic tasks. What does basic analysis look like?

Imagine a business stakeholder asks an agent to retrieve payment transactions approval rate.

Our transaction approval rate is 89% this week.

They ask the follow-up: “Is that good or should we be concerned?”

Agent reassures: “89% is a healthy approval rate; no concern.”

It’s a clear, confident answer, and an accurate data point thanks to the semantic layer. But it’s the interpretation that’s on shaky ground. For this metric, let’s say the normal band is higher, and 89% is a problem. With no benchmark for reference, the agent is liable to invent one. This isn’t a hallucination in the usual sense — the query is correct and the number is correct; it’s the judgment that’s fabricated. A semantic layer, on its own, doesn’t carry that judgment.

One question at five depths of context

Late in 2025, I went looking for a context framework to pair with dbt’s semantic layer. I gathered a mountain of research — from ontologists, library scientists, and scholars in adjacent fields — and recruited Claude to scour it all and apply it in the dbt context.

Watch how an agent’s response improves with each piece of context. Each layer adds something useful, and each one heads off a specific way of being confidently wrong.

From top to bottom: one layer of lookup, three layers of judgment, one of action. The middle three — calibration, framing, cross-metric reasoning — are the difference between a system that translates a question into SQL and one that reads the answer as an analyst. The last layer, action, is where a wrong answer starts to cost something real: a missed SLA, for example. L2 through L5 — is it good? why? what else? what do I do? — are questions a stakeholder often asks; questions an agent cannot answer from names and joins alone.

I didn’t invent these five layers — I synthesized them from people who have studied the structure of meaning for decades, long before agents made it urgent.

• Jessica Talisman’s information-science work argues that meaning has architecture — layers of increasing semantic richness, not a flat definition — and her process-knowledge research shows that how experts investigate is the most valuable, and fastest-decaying, knowledge in an organization. Her work is the foundation this whole schema stands on; without her work, I would not have built it.
• Brian Jin mapped the mechanisms of context decay and found that investigation logic decays fastest — which is why framing is a layer of its own, not a footnote on the definition.
• Chris Gambill’s three-layer metadata anatomy — technical, process, business — gave the schema its spine.
• Shane Butler’s layered-validation argument — that logical coherence requires baselines — is why calibration earned a layer too.

Meta:context is the framework that synthesizes their insights: five layers of context stored as structured, queryable YAML fields rather than free-text strings — giving an analysis agent the depth to do real analysis instead of confident-but-wrong guesses at what the data means. I first published the research in March.

Meta:context, distilled once. The messy raw sources — documentation, analyses (ad-hoc and scheduled), SME interviews, decision history — refined by the model into one structured five-layer card the agent reads, instead of re-deriving the judgment from scratch on every question.

Two layers of context in common: names and joins

Amidst the “context” hype — much warranted, if a bit frothy — every data platform seems to be racing to ship a context layer. I researched the schemas of nine production tools, field by field: Snowflake Semantic Views, Databricks metric views, Cube, Omni, Lightdash, dbt itself, Wren, Microsoft’s Power BI “prep for AI,” and GoodData. With meta:context, that makes ten.

Everyone ships the same two pieces: descriptions and synonyms on tables, columns, and metrics; and join topology — which tables relate, on which keys. Plus a free-text field for everything else, variously called ai_context, custom_instructions, or just comment. Here is the queryable field coverage of all ten, across five layers:

Everyone owns L1. Nearly every schema has some combination of descriptions, synonyms, and sample values because that’s what text-to-SQL requires — it’s commoditized. The only other widely-covered layer is L4, but it’s “relationships” in the join topology sense: left_table, join_type: MANY_TO_ONE, foreign keys. That tells an agent how to assemble the query, not that approval-rate and decline-rate move inversely, or that this metric leads next week’s chargebacks.

Both layers help an agent build a query. Neither offer the agent guidance on whether the data value is good, why it moved, or what to do. The analyst’s actual job lives in layers 3 to 5, and the current tools do not encode them.

In May 2026 Fivetran published agents_schema, an open standard that materializes agent context as queryable warehouse tables (AGENTS.*) aggregated from dbt, Looker, and the Open Semantic Interchange — a genuinely good idea on a new axis: delivery — context an agent can SELECT instead of querying a metadata API. But it leaves the depth behind: its dbt ingestion, as documented at launch, keeps only fixed columns and discards the meta: dictionary — the exact place analytical layers should live.

The context is linked to the underlying data only loosely: to match dbt models to Looker views, the spec joins on table names with a SQL LIKE it calls “intentionally heuristic,” not a typed key. A name match like that can’t be validated or traversed reliably — the same weakness as a free-text field. Even the most infrastructure-grade version of “context for agents” carries only name and joins.

Meta:context doesn’t require a new graph store or a proprietary format. It rides on dbt’s open MetricFlow YAML — and ideally it stays portable, mapped to the interchange standards (OSI, and aggregators like agents_schema) so the payload survives whatever delivery method an agent uses. As of launch, Fivetran’s agents_schema strips the dbt meta: dictionary on ingestion. The standard should preserve meta:, not drop it upon delivery.

Why “queryable” matters

A fair objection: every one of those tools does have a place to write “89% is low, check the processor” — a free-text field. So isn’t the calibration “there,” just as a sentence?

Even if these deeper context layers were inserted into the text field, there’s a significant difference between context an agent can read and context a system can check; the difference between a paragraph and a field. Any analyst knows a phrase buried in a text blob they’d have to regex into is a different animal versus a value in a column you can SELECT, GROUP BY, and filter on.

The healthy range as a column is a query; the healthy range as a string is a parsing project. (Most of these schemas are structured YAML — the structure exists; they just spend it on the name+join fields, leaving the deeper layers as one long string.) Put the healthy range in a sentence and you have something the model re-reads and re-interprets on every call. As a queryable field — healthy_range: {min: 0.94, max: 0.99} — three things are possible that a paragraph never allows:

• Measurable coverage. “Does every metric have a healthy range?” is a query against discrete fields. Over a prose blob it’s unanswerable — so there’s no coverage number at all.
• Decline to answer. “No healthy range defined → decline to judge whether this value is bad” is a rule you can enforce on a missing field. A paragraph gives you no missing field to trip on; you’d have to parse and classify it first, far less reliably.
• Compounding. A queryable schema is an extraction template — it learns from agent analyses (“what’s the healthy range?”) and from asking the analyst/author (“what breaks this? what’s the SLA?”). A blank text box asks nothing, so those layers never accumulate.

This is a key advantage to the open source meta:context approach: queryable, multi-layer, and coverage-measurable. The free-text box — GoodData caps it at 255 characters, Microsoft at 10,000 — is a string that you cannot lint, cover, or hard-gate on.

There’s a cost advantage here too. The expensive part isn’t reading the context, it’s deriving it: working out, from docs and history and someone’s memory, what the healthy band actually is. In free-text prose the model redoes it (probabilistically) every conversation, re-reading the same paragraphs and re-inferring whatever they imply, for every user. Distill it once into a field and that derivation is banked. Every conversation after reads a compact, addressable value instead of reconstructing it. The per-turn cost doesn’t vanish, but it shrinks and stops drifting from answer to answer. As inference bills climb, that compression at build time becomes a lever on the marginal cost of every conversation. When the budget is capped, the same spend buys better answers.

The context layer is just another mart. Nobody reruns the morning pipeline for every dashboard open — you build the mart once and everyone reads it. Meta:context is that move for agents: distill the raw sources into a queryable card once, and every conversation reads the card instead of paying to re-derive it.

From query-writer to analyst

“Is 89% concerning?” is one layer’s worth of help — calibration, and nothing more. But the five layers aren’t five separate features; they’re one continuous motion. Give an agent all five and it stops answering questions and starts running investigations: it calibrates the 89% against the healthy band, frames the dig by slicing channel first because that’s where these drops start, reasons sideways to the decline-rate it knows moves inversely and the chargebacks it knows lead by a week, and lands on an action with a name on it — escalate to the on-call lead, inside the documented window — or, if the SLA was never written down, says so instead of inventing one. That’s the sequence a junior analyst takes months to learn to run in the right order, and the agent runs it because the order is encoded, not because it’s clever.

The advantage compounds across a whole portfolio: a queryable schema over two hundred metrics isn’t two hundred paragraphs, it’s a graph with named edges an agent can walk: follow the affected_by event, join to the escalation path, walk the correlates_with edges to the second-order damage. A free-text box can hold a good sentence about one metric; it can’t be traversed.

The five layers are deeper cuts of a single question: lookup, judge, diagnose, propagate, decide. Encoding the additional layers as fields is what promotes an agent from a query-writer to an analyst.

The semanticists have been making a harder version of this case for years. Jessica Talisman’s recent piece, The Semantics of Semantics, draws the line clearly: a BI “semantic layer” is mostly metric definitions, glossary, and SQL-generating structure. That is useful, but it is not formal semantics, not an ontology, and not automated reasoning. By that standard, meta:context does not clear the bar either: a dbt meta context card is not a knowledge graph. Its claim is narrower and more practical. It turns business context into discrete, dbt-native fields that can be audited, linted, retrieved, scored for coverage, and used to refuse unsafe interpretation when required context is missing.

Bringing the layered-meaning concept into the meta: block dbt already supports for every model — every column in fact — establishes a pragmatic on-ramp toward richer, governed semantics that Talisman and other scholars argue for.

Depth is only one axis for comparing these tools. How the context binds to the data is another factor with several parts: does it sit on a single metric, or inherit down a whole model or project (the way a repo’s claude.md overrides the global claude.md); does it bind to the data through a typed key or a fuzzy name match; is it version controlled in your own repo or does it live inside a SaaS vendor’s platform? A follow-up piece will lay out all six axes in a single comparison matrix.