Context engineering for AI analytics: Best practices and where to start

Most conversations about AI and analytics get stuck on prompts. Write a better prompt, the thinking goes, and you'll get better answers. And, sure, clarity helps. But for data teams running AI on production warehouses, prompt quality is often the smallest variable in the equation.

What actually determines whether an AI agent answers "what drove churn last quarter?" correctly is what the agent knows about your data before the question is asked: which tables are trustworthy, how "churn" is defined in your organization, which joins are valid, and what business rules matter. That's context engineering: the practice of building the structured environment that makes AI answers accurate and reproducible, not just occasionally lucky.

According to Hex's State of Data Teams 2026 report, trust is the number one concern around AI adoption, cited by 31% of data leaders, nearly twice as much as any other concern. That's a context problem, not a prompt problem. And it's one data teams can actually solve.

What context engineering is (and what it isn't)

Prompt engineering is about how you ask. Context engineering is about what the AI already knows when you ask.

A prompt tells the agent what to do. Context tells the agent what's true: which data model to use, which business rules apply, which definitions to follow. Without it, agents make assumptions. They pick whichever "revenue" column seems right. They join tables in ways that look plausible but contradict your data model. They produce answers that are coherent and confidently wrong.

Context engineering is the work of replacing those assumptions with structured knowledge. That work looks different at different stages, and the good news is you don't have to build everything at once.

The four layers of context

Think of context as a maturity spectrum rather than a checklist. You can start at the first layer today without any upfront modeling work, then deepen your investment as your team's AI usage grows and your priorities become clearer.

Layer 1: Endorsed tables and warehouse descriptions

The lightest form of context engineering is also the most immediately impactful: tell your AI which tables to trust and what they contain.

In any reasonably sized warehouse, you'll have tables that represent the truth and tables that represent intermediate steps, experiments, or deprecated approaches. An agent with no guidance will treat them equally. Endorsing specific tables and adding plain-language descriptions to columns and schemas gives agents the signal they need to start from a reliable foundation.

This takes hours, not weeks. It doesn't need modeling expertise. And it immediately narrows the space of plausible-but-wrong joins an agent can make. For most teams, this is the right starting point.

Layer 2: Workspace rules

Once you've established which data is trustworthy, workspace rules let you encode the how of your analysis practices: the institutional knowledge your most experienced analysts carry in their heads.

Rules might specify that MRR calculations should always exclude trial accounts. That when a stakeholder asks about "active users," the definition scopes to users with at least one session in 30 days. That comparisons against prior periods should use the same fiscal calendar your finance team uses.

These aren't things an agent can infer from a schema. They're organizational decisions that live in the minds of the people who made them, until you write them down. Workspace rules put that knowledge in a form AI can actually act on.

The payoff is significant. Questions that would have produced subtly wrong answers, because the agent didn't know your organization's conventions, start producing answers your team can share with stakeholders.

Layer 3: Semantic models

Semantic models formalize your metric definitions in a structured, reusable way. They encode measures, dimensions, and relationships, so when an analyst asks for "retention rate by cohort," the agent knows exactly what formula to use and which tables to join, because it's been explicitly defined.

This layer takes more effort, but it also delivers more return. A well-built semantic model means that every analyst, every Threads question, and every data app built on top of your warehouse pulls from the same metric definitions. The consistency compounds across every analysis your team produces.

You don't need a complete semantic model to start. Many teams build their highest-stakes metrics first, the ones stakeholders ask about constantly and where inconsistency causes confusion, and expand from there. Hex's Modeling Agent can draft model definitions from your existing schema, which makes the first iteration faster than writing from scratch. If you're already using dbt MetricFlow, Cube, or Snowflake Semantic Views, Hex's Semantic Model Sync can pull those definitions directly, so you're not rebuilding work you've already done.

The key principle: semantic models are a deepening mechanism, not a prerequisite. Teams that wait until they have a "complete" semantic model before using AI agents tend to wait indefinitely, risking their team turning to unsanctioned AI tools for faster answers. Start with endorsed tables and rules, then add semantic models where they deliver the most return.

Layer 4: Observability and the feedback loop

Building context is iterative, not one-time. The questions your team asks will change. New data sources will be added. Analysts will find edge cases your workspace rules don't cover. Stakeholders will ask questions that reveal gaps in your semantic models.

This is where observability closes the loop. Knowing which questions are being asked, how often agents produce quality issues, and which topics are generating escalations tells you where to invest your context-building effort next. Without that visibility, context engineering becomes guesswork: you're improving things, but you don't know which improvements moved the needle.

Hex's Context Studio surfaces exactly this: question patterns, quality issues by topic area, and the gaps in your current context layer that are generating the most noise. It gives data teams a prioritized view of where the next context investment will have the most impact.

What poor context looks like in production

You'll recognize these patterns once you know what to look for.

Metric inconsistency. Two analysts ask slightly different versions of the same question and get different numbers. Neither answer is technically wrong given the SQL generated, but they're using different definitions of the same concept. This is almost always a context problem, not a query problem.

Join proliferation. An agent writes a query that produces a result, but the result is inflated because it joined two tables that create fan-out. The join is technically valid SQL, just not the join your data model intends. Endorsed tables and schema descriptions significantly reduce this failure mode.

Confidently wrong answers. This is the dangerous one. An AI agent doesn't signal uncertainty the way a junior analyst does. When context is thin, agents will pick a reasonable-sounding interpretation of ambiguous data and return a confident answer. The answer can be wrong in ways that take weeks to catch, especially if stakeholders start making decisions from it. Better context doesn't just improve accuracy; it narrows the space in which an agent can be confidently wrong.

Re-answering the same question differently. When a question has been answered correctly once but there's no encoded definition, the next person who asks may get a different answer. Context — especially semantic models — is what makes correct answers reproducible rather than one-time artifacts of a lucky prompt.

How to know if your context is working

A few signals worth tracking:

Quality escalations should decrease over time as you add context. If analysts are regularly editing or rejecting agent-generated SQL before sharing results, context is thin in that domain. Track where escalations cluster and treat them as a prioritization signal.

Stakeholder trust is a lagging indicator, but a real one. When business stakeholders start asking agents follow-up questions rather than asking "are you sure?" first, something has shifted. That shift usually corresponds to a period of improved consistency, which usually corresponds to semantic model coverage over the metrics they care about most.

Coverage of your highest-traffic questions matters more than breadth. A team with deep semantic context for the top 20 questions their stakeholders ask will outperform a team with shallow context spread across 200 topics. Start narrow and high-stakes, then expand.

And monitor quality actively, not reactively. Waiting for someone to flag a bad answer means bad answers are already circulating. Proactive observability, surfacing patterns before they become incidents, is the difference between context engineering as a practice and context engineering as a fire drill.

Where to start

If you're early in this work: endorse your most-used tables this week. Add descriptions to the columns that are most frequently misunderstood. That alone will measurably improve the starting point for every question your team asks.

If you've already done the basics: audit the questions that generate the most escalations or rewrites. Those are your highest-priority candidates for workspace rules or semantic model coverage. Build rules for the top five failure patterns and measure whether escalations in those areas drop.

If you're running a more mature AI workflow: invest in observability. You probably have more context gaps than you can see without it, and you're almost certainly spending context-building effort on lower-priority areas because you don't have visibility into what's actually breaking.

The teams getting the best results from AI analytics aren't the ones with the most sophisticated prompts. They're the ones who've done the quieter work of making their data legible to an agent: endorsed, described, defined, and monitored. That work compounds. Every table you endorse, every rule you encode, every metric you formalize makes every question asked against your data more likely to produce an answer your team can trust.

If your team is ready to put that foundation in place, request a demo and we'll show you what it looks like in practice.

Frequently Asked Questions

How is context engineering different from prompt engineering?

Prompt engineering focuses on how you phrase a question to get a better answer. Context engineering focuses on what the AI draws upon and understands before answering any question. For data teams, that means endorsed tables, metric definitions, business rules, and observability. A well-engineered prompt to a poorly-contexted agent will still produce wrong answers, because the agent doesn't know which "revenue" column to use or how your organization defines "active customer." Context engineering solves the upstream problem that no amount of prompt refinement can fix.

Do I need a complete semantic model before I can use AI on my data?

No, and waiting for one is one of the most common reasons teams stall. Start with Layer 1: endorse your most-used tables and add column descriptions. That alone measurably improves answer quality. Add workspace rules for the business conventions your experienced analysts know by heart. Semantic models are the strongest layer, but they're a destination on the maturity spectrum, not a gate you need to pass through before you start. Build semantic coverage for your highest-stakes metrics first and expand from there.

How do I prioritize which context to build first?

Start with the questions that generate the most confusion or rework. If your team keeps debugging the same metric inconsistency, or stakeholders keep asking "which number is right?", those are your highest-return targets. Track where analysts edit or reject agent-generated SQL most often, and treat those clusters as your prioritization signal. Context Studio helps surface these patterns proactively, so you can invest in the areas that will move quality metrics the most rather than guessing.