No, Context Engineering is not the next big thing for data teams

Everyone in data is suddenly talking about "context." Context layers, context engineering, context products, context repos. It's the word of the year, and like most words of the year, it's being used to mean five different things depending on who's saying it.

I want to try to say precisely what I think context is, why most of the industry is optimizing for the wrong slice of it, and why I don't think "context engineering" should become a new job.

What context actually is

Strip away the buzzwords and context comes from three places:

• The data platform itself: schemas, lineage, query logs, freshness, usage patterns. Facts a data system can observe about itself.
• The tools where people already talk: Slack threads, Notion docs, ticketing systems, PR descriptions. This context can be highly relevant to data teams, but it is scattered and unstructured.
• Undocumented tribal knowledge: the stuff that never got written down anywhere, because it didn't need to be, until the person who knows it is out sick, or leaves, or the AI needs it and nobody thought to ask.

A catalog, a glossary, an "enriched metadata" layer - these aren't a fourth category. They're the output of doing something with the first three. Which is the part most people skip past too quickly - a lot of meaning and fact can be derived from what exists, even in just the first two.

So what is a context layer? The part of your AI system responsible for the extraction, synthesis, storage, and intelligent retrieval of this information.

But what makes a good context layer?

The job is synthesis, not storage

Think about what a good analytics engineer actually does for a business. They take a messy pile of source tables, a Slack thread where someone half-defined "active user" eight months ago, a dashboard that's sorta wrong, and they turn it into a model the business can trust. There's a clear definition, clear ownership, and a clear story for why it's built the way it is.

A context layer needs to resolve the contradiction between what the warehouse says and what the Slack thread says and what the dashboard shows, and produce one governed answer. If your context layer is just a bigger pile of documents, you haven't built a context layer - you've just increased the denominator of your signal / noise ratio.

(For those who aren't familiar, you want to optimize for this ratio to reduce risk that LLMs hallucinate. Most if not all of the context you deliver for a given task should actually be useful - otherwise you waste tokens and time just for an incorrect answer.)

Context engineering should not be a new chore

Here's where I'll disagree with a lot of the current enthusiasm: I don't think "context engineering" is the future of the data profession, and I think anyone selling that framing is selling the wrong thing.

Nobody wants their job to become "writing documentation so an AI can do my job." If context engineering means data teams are spending their days hand-authoring markdown files describing every table, every column, every quirk of the business, we've only invented a new, more tedious form of the same maintenance work that was already the least-loved part of the job.

The promise of AI is that we should get time back. If context engineering costs a data team more hours than it saves, we've built the wrong thing.

So the real question isn't "how do we get humans to write more context." It's: what actually requires a human, and what can the system figure out on its own?

The rule: judgment call, or derivable fact?

This is the distinction I think the industry is missing, and it's the one I'd ask any team building or buying a context layer to apply:

If it's a judgment call, govern it. If it's a derivable fact, automate it.

A judgment call is something only a human can decide, and something the business needs to hold someone accountable for.

• What counts as an "active user?"
• Which join is the correct join when three tables could plausibly answer the same question?
• Did this metric change because the business changed or because someone quietly patched a bug?

These need ownership, review, and version history - the same discipline you'd apply to production code. If your semantic layer or your top metric definitions can change with no review trail, then that's a problem.

A derivable fact is something the system already knows, or can figure out by watching itself. What columns exist. Which tables are actually being queried and which have been dead for eight months. What changed in a dbt model last Tuesday? Whether a pipeline's freshness SLA just slipped. None of this should ever require a human to type it into a doc.

Most "context engineering" content right now treats all of this as one big authoring task. It isn't. Half of it is governance. Half of it is plumbing. Confusing the two is exactly how you end up asking a data team to write documentation as a second job.

Context isn't one-size-fits-all. It's task-shaped.

Almost everyone building in this space right now is solving the same use case: a stakeholder types a question in plain English, and an agent turns it into SQL. That's a real and valuable problem. It's also a narrow slice of what a context layer is actually good for.

The context a text-to-SQL agent needs is not the context a data-operations agent needs, even when they're both drawing from the exact same underlying layer.

A stakeholder-facing agent answering "what was revenue last quarter" needs: the approved metric definition, the correct grain, the right join path, and enough business understanding to know that "revenue" means net-of-refunds, not gross. Feed it your full lineage graph and your query log history and you've made it slower and more likely to talk itself into the wrong answer.

An agent doing model optimization or refactoring needs almost the opposite slice: it needs query cost and frequency data, which models are actually load-bearing versus dead weight, how tables relate structurally, and what's safe to change without breaking five downstream dashboards. It has very little use for the business definition of "active user" - it needs the operational shape of the warehouse, not the semantics of the metrics living in it.

Same underlying context layer, but completely different retrieval shape, because the task is different.

The industry's current framing is too narrow. Everyone's building for the moment a business user asks a question. Almost nobody is building for the moment a data team needs to move faster on the operational work they actually spend most of their week doing: modeling, testing, cost control, catching breakages before a stakeholder does. That's a bigger, harder, and more valuable problem than chat-with-your-data, and it needs its own shape of context, not a repurposed version of the Q&A layer.

Context has to stay alive

One more thing worth being honest about: a context layer that's accurate on day one and stale by day thirty is dangerous. The whole point of separating "governed judgment calls" from "derivable facts" is that the derivable half should be re-synthesizing itself continuously - a new column shows up and it's documented without anyone asking (gray area here, because we may need governance), a query pattern shifts and the layer notices, a dbt model changes and lineage updates itself same-day. If your context needs a person to remember to refresh it, you've rebuilt the documentation problem you were trying to solve, just with an AI reading the stale version instead of a person.

Where this leaves us

A great context layer:

• Automates derived facts, and keeps humans in the loop only for judgment calls
• Comprehensively (as possible) extracts, synthesizes, and derives existing digital information
• Captures undocumented institutional knowledge
• Intelligently delivers the right subset of context for the task at hand, optimizing signal-to-noise ratio
• Doesn't make data teams do more work

Context is a synthesis problem with a clear governance line running through the middle of it - some of it needs a human's judgment and a review trail, most of it should never touch a human's time at all - and it has to be shaped differently depending on what you're asking an agent to actually do.

Most of the current wave of tooling is solving the easy, visible 20% of this: let a business user ask a question in plain English. That's worth doing. But the bigger opportunity is the 80% underneath it - giving data teams themselves the context to move faster on the operational work that actually consumes their week.

That's the problem we've been building Sidecar to solve: a context layer that governs the judgment calls, automates the rest, and reshapes itself depending on whether the agent on the other end is answering a stakeholder's question or fixing your warehouse before it breaks.