Schema Drift Reaches the Tool Definition
Context layer series Everyone who sells a context layer talks about freshness. Fresh rows, streaming…
Every tool with a connector catalog now sells a context layer. This post is a buyer’s framework for telling them apart before you sign: the five capabilities that sit on top of ingestion, a scoring rubric you can run against any vendor or internal build, and the cost model that actually predicts your three-year number.
The stakes are documented. MIT’s State of AI in Business report found 95 percent of enterprise GenAI pilots delivered no measurable P&L impact, and buried in the findings was the reason that matters here: when stakes were high, users kept a human in the loop because the AI could not adapt to their specific context. The agents did not fail for lack of data. They failed for lack of context: what the data means, which number to trust, what policy allows, and whether the answer reflects the world as it is right now. If the term itself is new to you, start with our primer on what a context layer actually is; this post assumes that baseline and goes straight at the buying decision.
By mid-2026 the category had a name and a chorus. At Snowflake Summit, analyst Sanjeev Mohan put it plainly: you can leave data where it is, “but now the moat has moved to a layer above it, which is the context layer or the metadata layer, because you can apply security there.” Andreessen Horowitz opened its March 2026 thesis with a sentence vendors should have framed: “Data and analytics agents are essentially useless without the right context.”
And the moment a category forms, every adjacent product repositions into it. Data-movement platforms that spent a decade selling connectors now sell context. Some of that repositioning is real engineering. Some of it is a landing page. The rest of this post is how to tell which one you are looking at.
Here is the claim the whole framework rests on: ingestion is table stakes, and table stakes is not a context layer. Connecting Salesforce, Postgres, Snowflake, and a dozen SaaS APIs is real work, and nothing runs without it. But a connector delivers a row, and a row on its own answers nothing.
The a16z piece captures the failure mode precisely: an agent handed raw consolidated data hits two tables named fct_revenue
and mv_revenue_monthly
, has no way to know which is canonical, and either guesses or produces a confident wrong answer. The connector did its job perfectly. The agent still failed.
This is also why the strongest technical writing has moved from “retrieval” to context engineering, and its most useful finding for a buyer is blunt: agents perform worse with a 100K-token summary than with a 5K-token targeted retrieval on the same task. More context is not better context. Right context is better context. Piling documents, embeddings, and metadata into one searchable store is inventory with better search. The test is never whether you have context. The test is what the agent can now do that it could not do before.
So assume every serious tool connects to your sources. The buying question is what it does in the gap between the row and the answer. There are exactly five things worth paying for in that gap. Run your cursor down the stack: the highlighted rows are where real context layers separate from relabeled ETL.
×1
×3
×3
×3
×3
×2
The agent needs the row plus its meaning: canonical definitions (which “revenue”), identity resolution across systems (this acct_id
in Salesforce is that customer_id
in Postgres), lineage, and quality signals. For most organizations that knowledge is scattered across YAML files, wikis, spreadsheets, and someone’s head. A tool has real semantic grounding if it drafts these definitions automatically from query history, dbt models, and existing semantic layers, and then lets a human encode the tribal rules the machine cannot infer, like “exclude internal test accounts before Q3 2024.” A tool that stores column descriptions you typed by hand has given you a glossary, not grounding.
This is the capability most repositioned ETL tools quietly fail, because their whole architecture moves data on a schedule into a store, and a store is a snapshot, and a snapshot is stale the instant a record changes at the source. An inventory agent quoting stock that sold out twenty minutes ago and a support agent citing a subscription cancelled this morning are the confident-and-wrong failures that put the human back in the loop. The standard to hold vendors to is one Airbyte itself states in its context-layer docs: refresh cadence should match the agent’s decision frequency, sub-minute for inventory, daily for planning. The buyer’s question is whether the tool can actually meet sub-minute freshness on the sources that need it.
A context layer that serves every agent the same giant blob has optimized for the wrong thing. The strong pattern is per-task assembly: retrieve broadly, re-rank to a precise top-N, and hand each task exactly the context and tools its one job requires, nothing else. This is the reasoning behind task-specific MCP servers, and it is measurable: our own benchmarks show the tool-call and error-rate gap between a task-specific server and a general-purpose one directly.
There are two places to enforce access policy, and the difference is a security decision, not a feature checkbox. The weak pattern: the agent asks a catalog for guidance, then queries your data itself, which makes policy advice and enforcement optional. The strong pattern: every request and every result passes through a gateway that propagates source permissions, enforces policy on the call itself, and logs every access for audit. The test is concrete. If the layer is a repository the agent reads and then queries the warehouse on its own, your governance story has a hole. If it is a gateway the calls pass through, the hole closes.
The context has to reach the agent as a single call returning typed, structured, permission-aware results, ideally over MCP so any framework can consume it, and increasingly with the ability to write back, not just read. A tool that makes the agent orchestrate five calls, join the results, and guess at types has pushed the hard part back onto you.
A sixth, cross-cutting property keeps the other five from rotting: self-updating. Semantics drift, schemas change, embeddings go stale. A context layer you hand-maintain is wrong within a quarter. It is not a sixth thing to buy so much as the thing that decides whether the first five stay true.
Freshness deserves its own section, because it is where architectures actually diverge and where change data capture earns its place. The naive approach is letting agents query production directly. Do not: Streamkap’s numbers show a Postgres pool built for application traffic collapsing under bursty agent load, with 5-millisecond app queries stretching to 500 while they wait for connections. The other naive approach is batch-syncing everything, which is safe for production and stale for agents.
Log-based CDC threads the needle. It reads the transaction log the database is already writing, so the impact on the source is negligible, and it keeps a downstream store synchronized within a second or two. The clean way to hold the two protocols in your head: MCP defines how the agent asks for data, CDC defines how the data stays true.
Decide freshness per source. CDC where minutes-old data means wrong answers, batch where daily is genuinely fine. “CDC everything” burns money; “batch everything” ships stale answers.
One nuance, to be fair to the vendors doing this well: the most capable platforms offer both a pre-materialized store and a live path and let you choose per source. That is the right shape. The evaluation question is which path is the default, how live the live path really is, and whether task-specific assembly and in-line governance apply to both, or only to the cache.
This is the most common category confusion in the buying process, and it costs teams a quarter when they discover it late. The two products overlap on connectors and diverge on everything above them.
| Dimension | No-code ETL / data integration | Context layer |
|---|---|---|
| Primary job | Move data from A to B reliably | Serve agents the meaning of data at decision time |
| Unit of output | A synced table, a pipeline run | An answer an agent can act on |
| Semantics | Column mapping, light transforms | Definitions, identity resolution, lineage, quality |
| Freshness | Scheduled batch, some CDC | Matched to decision frequency, per source |
| Assembly | Same table for every consumer | Just-enough context, per task |
| Governance | Pipeline-level access | Enforced in-line on every call, audited |
| Delivery | Rows in a destination | One typed call over MCP or API, write-capable |
| Consumer | Dashboards, warehouses, BI | Agents, and the humans reviewing them |
A no-code ETL tool is necessary. It is capability zero, and plenty of context layers are built on exactly that foundation. The mistake is assuming the foundation is the building. If a tool’s docs and demo are all about getting data into a place and go quiet about meaning, freshness at decision time, per-task assembly, and in-line policy, you are looking at ETL with a context-layer label. Useful, just not the thing that closes the 95 percent gap.
Rate each capability from 0 (absent) to 3 (best in class). The weights are fixed, and the four core capabilities count triple, because they are where real context layers separate from repositioned ingestion. Score the tool you are evaluating — or your internal build — and the calculator starts comparing it against our own self-score from your very first pick.
Pick a score on all eight capabilities — 0 of 8 scored.
Weighted maximum is 57 — and yes, 57 is our self-score, because this rubric is the shape of what Helix and MCP Studio were built to be. Do not take our word for it: the benchmarks are public, and scoring us yourself takes one demo.
Sticker price is the least interesting number. The real cost is what it takes to onboard each source and keep it correct as the business drifts, multiplied across every source and every quarter.
connector setup + semantic modeling + governance mapping + validation + freshness infrastructure (CDC or batch) + allocated platform fees
schema-drift maintenance + definition upkeep + re-validation + freshness run-rate + allocated platform fees
Three line items get underestimated on every deal we see. Semantic modeling is the tall pole and it recurs: drafting definitions is a one-time cost, keeping them true is forever, and the gap between auto-updating and hand-maintained semantics is the difference between an X and a 3X three-year number that never shows up on the sticker. Freshness has a run-rate: CDC for a source is real infrastructure with a monthly bill, justified only where staleness produces wrong answers. And build-versus-buy carries a documented penalty: MIT found externally built tools succeed roughly twice as often as internal builds, which belongs in your model as risk-adjusted cost, not just engineering salary.
The practical move: run the model on your three hardest sources, the ones with the most tribal semantics, the tightest freshness need, and the strictest policy. The easy sources flatter every tool. The hard ones reveal the three-year number.
Read it bottom to top. Whatever you buy or build should collapse to this shape.
Three rules make or break it. The gateway is the only path to data; if agents can reach sources around it, governance is theater. Freshness is a per-source decision made at the freshness plane, never a global one. And assembly happens at delivery, per task; you keep the engine rich and compose just-enough context at call time instead of pre-baking one blob.
For one concrete instantiation: Helix maps onto this shape directly, with 1,000+ connectors at ingestion, Nexsets fetching live data, an open engine that grounds and updates itself, MCP Studio doing task-specific assembly, and policy enforced on every call at the gateway. It is one implementation of the pattern. The pattern is what you should be buying, from whomever you buy it. Between the row and the answer, what does this do — and can the agent get to the data without it?
If the answer is “we deliver the row, fast, from many sources,” you have found an excellent ingestion tool. Pair it with a real context layer; do not mistake it for one. If the answer covers meaning, freshness at decision time, per-task assembly, and policy on every call, and the agent genuinely cannot go around it, you have found the thing that closes the gap MIT measured. The moat moved up a layer. Buy for the layer the moat actually moved to. Helix grounds and governs every call your agents make, and MCP Studio builds task-specific MCP servers on the same engine, each carrying exactly the context its one job needs. Score us on the rubric above; that is what it is for.
Read next: How to evaluate a context layer beyond token counts and Schema drift reaches the tool definition.
Context layer series Everyone who sells a context layer talks about freshness. Fresh rows, streaming…
Context layer series MCP tool schema design is the practice of writing a tool’s name,…
Context layer series Two MCP servers sit in front of the same warehouse. You ask…