The Context Layer Is Real Now — It Can Read Your Data but Can’t Refuse a Bad Question

In one week the “context layer” stopped being a Gartner phrase and became shipping infrastructure: Fivetran and dbt closed their merger and put a context standard in the warehouse, and a catalog vendor published the field guide. All of it is structured, queryable, real — and none of it can yet look at a question and decline to answer. Structured context is now table stakes. The layer that acts on it is the one still missing.

Two earlier pieces in this arc kept arriving at the same wall from different sides. The Exhaust Brain and the Modeled Brain argued that a retrieved sentence is not a governed number — the substrate under a company brain has to be modeled data, not organizational exhaust. Which Graph Goes Under the Brain? pushed one rung up: a governed number is not yet a safe answer, and the differentiator is not where context lives but whether it is typed, evaluable, and able to refuse. Both were written against a field that was still mostly arguing about vocabulary.

That changed the week of June 1. The field stopped arguing and started shipping. Fivetran and dbt Labs completed their merger — announced the previous October, closed now — explicitly to build “the data infrastructure for trusted AI agents,” and shipped a standard for putting agent context in the warehouse. Prukalpa Sankar, who co-founded the catalog vendor Atlan, published a careful field guide to what an enterprise context layer actually is. A handful of smaller efforts — a brownfield dbt auditor, a coordinator-memory project — quietly built the part the big announcements skipped. Read together, they let us check the arc’s central claim against shipping artifacts instead of vocabulary. The claim mostly holds. The part of it that doesn’t is the more interesting half.

1. What actually shipped

Start with the facts, kept separate from the framing. The merger is real and all-stock; the analyst write-up that surfaced it in my reading queue is market interpretation, not the primary record, so the specifics below come from dbt’s and Fivetran’s own pages. dbt Core 2.0 open-sources much of the Fusion engine under Apache 2.0. dbt State adds a metadata-aware caching layer that skips unchanged work. dbt Wizard is an agent for authoring and reviewing models. And the load-bearing one for this arc: Agents Schema, billed as an open standard for agentic context, which designates one schema in the warehouse as the shared context surface for AI agents.

It is worth reading the actual spec rather than the announcement, because the announcement says “context layer” and the spec says something more precise. Agents Schema is a set of plain SQL tables — with primary keys — that hold dbt model, column, and dependency metadata; LookML views, dimensions, and measures; datasets, fields, metrics, and relationships in the Open Semantic Interchange format; and a free-form AGENTS.ROOT block of provider text. It is structured. It is queryable with a SELECT. Any SQL-capable agent can read it. What it is not, by its own spec, is an evaluator: there are no coverage scores, no semantic-conflict checks, no refusal conditions, no “this question is unsafe to answer” policy, no CI gate. It is a very good map of the context. It does not act on the context.

Prukalpa’s field guide is the most complete articulation of the larger idea, and the most honest about its own boundaries. She splits the layer into a substrate — AI-ready data and a knowledge graph, semantics and ontology, and skills — and five capabilities that operate it: mining context out of systems that never wrote it down, a context development lifecycle, compounding learning loops, activation and retrieval across many interfaces, and governance. Her sharpest idea is that a skill is to procedural knowledge what the function was to logic: the unit that lets know-how stop being re-derived every time and start compounding. It is the best vendor taxonomy of the category I have read. It is a taxonomy, though, not the naming of an official category — Gartner has written about context engineering, not a canonical “enterprise context layer” product line — and the difference matters, because a vendor map of a category is exactly the artifact you would expect from the vendor best positioned to sell into it.

2. The correction: structured is no longer the wedge

The companion piece drew a ladder from data to metadata to context-as-prose to governed measurement context, and leaned hard on a contrast between prose you can read and a typed contract you can act on. The adversarial pass on this batch made me give part of that contrast back, and the giving-back is the most useful thing in the essay.

“Typed versus prose” is too clean a line, because a great deal of context is already typed and nobody waited for me to notice. Snowflake’s Semantic Views are first-class schema objects with metrics, entities, and relationships, queryable with a SELECT and consumed by Cortex Analyst. dbt’s Semantic Layer centralizes metric definitions and join paths in MetricFlow. LookML has modeled measures and relationships for a decade. OSI is a portable YAML contract for exactly these objects. Agents Schema is now another. Even Cube’s ai_context, the one free-text entry on the list, is machine-readable enrichment an agent pulls, not a paragraph in someone’s head. An agent can read every one of these mechanically. Structured semantic context is not the frontier. It is becoming the floor.

So the wedge cannot be “make the context structured.” That race is largely run, and the incumbents are winning it. The wedge has to move up one rung, to the thing that is conspicuously absent from every artifact above: not a richer description of the context, but a layer that evaluates a specific question against the context and is allowed to say no. Coverage scoring — how much of what was asked can this metric actually answer. Conflict detection — do two models that both claim “revenue” compute it the same way. Refusal — the conditions under which the honest output is “I can’t answer that from this.” Assertion in CI — a typed claim that fails the build when the context and the data drift apart. Every shipped surface this week gives an agent more to read. None of them gives it the machinery to decline.

3. Two small proofs that the refusal layer is buildable

The right-hand columns are not empty because the capability is impossible. They are empty because the large vendors are racing on the surface, where the integration value is, and the refusal layer is being built — small, and by other people. Two artifacts in this batch are worth more than their star counts.

dbt-agent-readiness, from the team behind Cassis, is a Claude Code skill that audits a dbt project for what an agent will get wrong if you point it at the data today: two models that both claim “revenue” and compute it differently; the same entity named customer_id, cust_id, and user_id across models; a YAML-declared column the SQL never emits; a description that promises totality while the SQL quietly filters rows; a description that says COUNT while the SQL does SUM. It returns a verdict — ready, not ready, or unsafe — with a “safe starting perimeter” of the models an agent can query today and a remediation backlog for the rest. That is the refusal layer, built for brownfield and run at audit time rather than query time. It is also a four-star repository with a single 1.0 release in April; it is the right shape, not evidence the market has solved anything. The shape is the point. Somebody wrote down, mechanically, the failure modes the companion piece described in prose, and shipped a tool that detects them.

Zaxy aims the same instinct at agent memory rather than at the warehouse. Its 0.4 release reframes a memory system as a coordinator: a parent mission plus isolated worker sessions, where findings are promoted into the trusted project state only after a conflict-and-stale-claim review, and a checkout from the parent answers from accepted state while pending claims stay visibly separate. The memory object it hands an agent carries diagnostics — answerability, citation coverage, whether the answer is drawn from current, stale, or insufficient state. That is evaluability applied to memory: the same move as a coverage score on a metric, one layer over. Its benchmark numbers are self-published and its novelty against the established memory projects is unproven, so the honest read is “an interesting accepted-state pattern,” not a winner. But the pattern — promote nothing into shared truth until it survives a check — is the memory-shaped version of refusal, and it is the same discipline this project runs on its own beliefs file.

4. Refusal and governance are the same requirement, seen at two speeds

There is an honest objection to all of this, and Prukalpa is the one who raises it best. Her governance capability — quality, drift, lineage, versioning, approval — is not primarily about a runtime refusal. It is about who owns a definition, who may merge a change that ripples across hundreds of downstream agents, whether a redefinition of the core customer propagates automatically or queues for review. She concludes, rightly, that these are organizational-design questions. A reader could fairly say the real differentiator is this lifecycle governance, not a query-time “no,” and that refusal is one small feature inside a much larger context-management problem.

The objection is right that lifecycle governance is the larger, harder problem. It is wrong that it competes with refusal. They are the same requirement read at two speeds. Refusal is evaluability at query time: can the system, right now, check this question against the context and decline. Lifecycle governance is evaluability at maintenance time: can the system tell when the world moved underneath a definition, when two agents disagree because they are on different versions, when a context asset has drifted out of date. Both depend on the context being typed enough to check. A prose paragraph fails both tests — you can neither refuse against it at query time nor lint it for drift at maintenance time. The shared brain everyone is naming compounds only if it can do both: say no when a question outruns the data, and notice when its own knowledge goes stale. The artifacts that shipped this week build the surface that both depend on. Neither speed of evaluation comes in the box.

5. What we take, and what we build

The concession first, because it sharpens the rest: structured context is no longer a differentiator. The week of June 1 made that explicit. A merger, a field guide, and an open warehouse standard all agree that meaning belongs in machine-readable form close to the data, and the warehouses are shipping it. Anyone whose pitch is “put the context in the model” is now describing the consensus, not a wedge.

What is still missing from every shipped artifact is the layer that acts on the structured context: that scores how much of a question it can answer, detects when two definitions contradict, fails a build when context and data drift apart, and — the test the whole arc keeps returning to — declines when the honest answer is that the metric cannot answer what was asked. That layer is buildable; two small projects are building pieces of it. The obligation it comes with is portability: a typed, evaluable contract that lives only as bespoke dbt meta dies with the repo, so the discipline is to define it as a schema in its own right and map it outward — to MetricFlow, to OSI, to the new Agents Schema tables — so the evaluation rides on the standard transport instead of fighting it. The surface is now a commodity. The refusal is the asset. Most efforts to build a company brain can now describe their context. Very few can let it say no, and that — the two columns on the right of the scorecard, still mostly empty — is the layer worth building all the way.