Context engineering is the new analytics engineering skill: a practical guide for dbt users

What is context engineering?

When the idea that 2026 is "the year of context" started making the rounds, Joe Reis answered with a send-up of context lakes, context products, and the analyst singularity. Underneath the satire is a real problem: most organizations are bad at giving AI systems the context they need to reason reliably.

Context engineering is the practice of structuring information so that AI models and agents can use it accurately. It works at a different level than prompt engineering, which operates on instructions, and it's broader than retrieval-augmented generation, which is one specific implementation. Context engineering decides what information an AI system gets, in what format, and at what level of specificity, so it can reason about a domain without hallucinating or guessing.

For AI systems working with data, that discipline has a specific shape. The AI needs to know: what does this metric mean? What is the grain of this table? What does a null value in this column represent? What business rules make this metric different from that one?

Those are questions about how knowledge is encoded in the data layer. And analytics engineers have been encoding that knowledge in dbt projects for years.

Why analytics engineers already have the advantage

Here's the insight this piece is built around: analytics engineers are already doing context engineering. They just don't call it that.

When you write a MetricFlow metric definition, you're encoding context. You're making explicit the business logic that turns a column in a table into an answer a stakeholder can trust. When you write a model description that explains why a model exists and what it represents, you're encoding context. When you define a schema contract, you're encoding context about what can and cannot change at this model's interface.

The difference between an AI agent that reasons reliably about your data and one that hallucinates is almost entirely a function of how well-structured that context is. Agents that query raw tables with no semantic definitions make reasonable guesses and are frequently wrong. Agents that query a governed dbt Semantic Layer return answers that are consistent and defensible.

The skill analytics engineers already have, making implicit business knowledge explicit, structured, and machine-readable, is exactly the skill that makes AI systems trustworthy. Context engineering is analytics engineering pointed at a new consumer.

How dbt structures context for AI agents

A well-structured dbt project provides context to AI systems through four mechanisms.

Model descriptions. A description field in a model's YAML does more than document for humans. When an AI agent reads the lineage graph through the dbt MCP server, model descriptions are part of the context it receives. A sparse or absent description means the agent has to guess what the model does. A precise one means it doesn't.

MetricFlow metric definitions. These are the most powerful context mechanism in the dbt stack. A MetricFlow definition encodes not just what to compute, but how: the entity, the measure, the filters, the grain. When an AI agent queries the dbt Semantic Layer, it isn't writing SQL. It's querying against definitions that already encode the business rules. The accuracy gain is large: in an early dbt experiment, LLMs answered natural language questions correctly about 83% of the time when grounded in governed MetricFlow definitions, far above raw text-to-SQL on real-world schemas.

Schema contracts. Contracts define the interface at a model boundary. They're context about what can be relied upon: which columns will always exist, what types they'll be, what constraints hold. For AI agents writing code that depends on downstream models, contracts prevent a class of errors that would otherwise need human debugging.

Column-level lineage. Lineage tells an AI agent where data comes from. When an agent generates documentation or debugs an anomaly, column-level lineage in dbt Explorer is the context that lets it reason about causality rather than just correlation.

Three context engineering patterns to build this week

Three patterns analytics engineers can implement using dbt this week:

Pattern 1: Metric-as-contract documentation

For each of your core business metrics, write a MetricFlow definition that includes the measure plus explicit documentation of what the metric excludes, what the grain means, and what edge cases apply. This is the work that keeps your AI analytics tool from returning a plausible-but-wrong answer to a CFO query. Estimated time: 2-4 hours for 5-10 core metrics.

The test: can a new team member, or an AI agent, read the definition and understand not just how to compute the metric but why it's defined this way? If not, the definition isn't doing its job as context.

Pattern 2: Model-level context headers

Add a structured description block to your 10 most important dbt models. Include what the model is (the grain, the purpose), what it isn't (common misuses or misinterpretations), and what changes downstream if its definition changes. This is the context an AI agent needs to reason about the model correctly without running the data.

Keep the description complete in 3-5 sentences. Shorter is better if it's precise. The goal is to write everything an AI system needs to reason about the model accurately, no more.

Pattern 3: Freshness and quality metadata as context signals

Configure source freshness checks and make the freshness metadata accessible. An AI agent that knows a source was last loaded 4 hours ago can make a better decision about whether to run a downstream pipeline. An agent with no freshness context runs regardless. Freshness metadata is context engineering at the pipeline-operations level: it gives autonomous systems the information they need to decide when to run.

The vocabulary shift that matters

Context engineering is a better name for work analytics engineers have always done: making implicit business knowledge explicit, structured, and reliable. The consumers of that work have changed. The work itself has held steady.

What's changed is the leverage. In 2023, a well-documented dbt project made a human analyst's job easier. In 2026, a well-documented dbt project makes every AI agent that runs against your data stack more accurate. The context an analytics engineer builds is used by a system. That's a meaningful expansion of impact.

The year of context, whatever the analysts mean by it, is really the year analytics engineers discover that the work they've always done is worth more than they realized.