From Analytics Engineer to Context Engineer: Preparing Your Data for the AI Agent Era

Analytics engineers have spent years transforming raw data into actionable models for dashboards and analyses. Meticulous work in modeling, documentation, and optimization. But in 2025, the rules are changing. AI agents are arriving in enterprises with a simple promise: analyze data autonomously and answer business questions directly. The catch is that these agents don't consume data the same way a dashboard does.

This evolution doesn't make the work of analytics engineers obsolete. It transforms it profoundly. The role shifts from building models for humans to preparing context for autonomous systems. This is what we call context engineering: a new skill that redefines the role of analytics engineers in the modern data ecosystem.

What AI agents really expect from your data

A dashboard displays aggregated metrics, visual trends, comparisons across multiple dimensions. The user interprets, cross-references information, formulates hypotheses. An AI agent, on the other hand, needs rich context to generate precise and actionable answers. It doesn't just want numbers: it needs to understand what those numbers mean in a business context.

Concretely, this changes everything. Take a classic example: a sales table aggregated by month. For a dashboard, you add a few dimensions (region, product, channel) and key metrics (revenue, margin, volume). That's sufficient to visualize trends. But for an AI agent that needs to answer a question like "Why did our sales drop in January in the Northeast region?", this table lacks critical context.

The agent needs to know what happened in January: a specific marketing campaign, a logistics issue, a competitor launching an aggressive promotion. It needs to understand causal relationships, precise business definitions, calculation rules, exceptions. All this information that analytics engineers know but rarely document in a way machines can use. This approach of AI-ready data modeling is now essential.

Enriching your dbt models for AI agents

The good news is that dbt already provides the tools to make this transition toward context engineering dbt. YAML documentation, tests, meta-properties: it's all there. But you need to use them differently—much more systematically and strategically.

Start with column documentation. In a traditional approach, you document columns so analysts understand the model. In a context engineering approach, each description becomes a precise business definition the agent can leverage. Instead of writing "Sales amount," you document "Revenue excluding taxes calculated on the basis of unit selling price multiplied by quantity sold, after applying commercial discounts and before deducting customer returns."

This precision isn't a luxury. It allows the agent to understand exactly what it's working with and avoid interpretation errors. An agent that doesn't know a metric excludes returns can produce completely flawed analyses. This documentation rigor makes all the difference between analytical hallucinations and reliable insights.

Next, meta-properties become strategic. dbt allows you to add custom metadata to your models. You can store information like data validity periods ("reliable data since January 2023, migration period before"), known limitations ("don't use for margin analysis on bundle products"), or business dependencies ("this metric is linked to the Premium offering launch in March 2024").

A concrete example: you're modeling a customer satisfaction table with an NPS (Net Promoter Score). In your YAML, you document not just the calculation formula, but also the context: the collection methodology changed in June 2024, moving from email surveys to in-app surveys. This information, stored as a meta-property, allows the agent to avoid directly comparing NPS before and after June 2024 without mentioning this methodological change.

Creating rich semantic models for data preparation

Beyond enriched documentation, context engineering involves rethinking the structure of data models itself. Analytics engineers are used to creating models optimized for query performance and ease of use in BI tools. With AI agents, you add a new constraint: semantic richness in data preparation for agents.

This translates into several practical changes. First, model granularity. Rather than aggregating everything at the monthly level, you maintain multiple levels of granularity (daily, weekly, monthly) with clear guidance on when to use each. An agent analyzing a sudden variation needs daily detail. An agent projecting long-term trends can work with monthly data.

Next, calculation traceability. In a dashboard, you display a final result. For an agent, you document the path: which source tables, which intermediate transformations, which business rules applied. dbt excels here with its lineage, but you need to go further by documenting the "why" behind each transformation. This approach aligns with the importance of metadata in a modern data strategy.

Take a real case: a SaaS company calculating its ARR (Annual Recurring Revenue). The final model aggregates multiple sources: active contracts, upgrades, downgrades, churn. Each component has its own business rules (is an upgrade recognized immediately or at renewal? Is churn measured in volume or value?). Documenting these rules in intermediate models, validated with dbt tests, allows an agent to understand not only the final number but also the action levers.

Tests as a source of context

dbt tests take on new significance in a context engineering approach. They're no longer just for validating data quality; they become executable documentation of expected behavior.

A test verifying that total sales never exceed 150% of production capacity isn't just a technical constraint. It's a business rule that says something about the company's business model. An agent aware of this constraint can detect anomalies ("March sales show 180% of capacity, probably a data entry error") or understand limitations ("We can't project linear growth beyond current capacity without investment").

Similarly, relationship tests between tables become context. A test verifying that a customer always has at least one active delivery address implicitly documents a business rule: you can't sell to a customer without an address. This information is useful to an agent analyzing conversion rates or cart abandonment.

The key is documenting the intent behind each test. Not just "verify that customer_id exists in the customers table," but "a sold product must always be associated with a known customer, as our business model prohibits anonymous sales except for promotional products under €10."

Preparing the transition in your teams

This evolution of the analytics engineer role toward context engineering doesn't happen overnight. It requires a change in mindset and organization.

First step: identify priority models. You can't enrich everything immediately. Start with models feeding your most strategic AI use cases. A company deploying an agent to answer questions about sales performance will start by enriching its sales, pipeline, and conversion models. Another focused on operational optimization will prioritize production and logistics models.

Next, create team standards. Define what a "good" column description looks like in your context. Establish templates for common meta-properties (validity period, known limitations, business dependencies). Train your analytics engineers on this new dimension of their work. It's not just documentation for documentation's sake—it's building context that autonomous systems can leverage.

Finally, integrate this logic into your code review processes. When an analytics engineer proposes a new dbt model, review goes beyond SQL quality and performance. It includes context richness: are columns documented with sufficient precision? Are business rules explicit? Are limitations mentioned? These practices align with best practices in analytics management.

Toward new human-machine collaboration in analytics engineer evolution

Context engineering doesn't replace analytics engineering. It extends and enriches it. Analytics engineers remain guardians of data model quality and consistency. But they also become architects of the context that enables AI agents to produce relevant analyses.

This transition is already underway in the most mature organizations. We're seeing data teams restructuring their dbt models to systematically integrate business context. We're seeing analytics engineers spending as much time documenting the "why" as coding the "how." We're seeing architectures where dbt models no longer just feed dashboards but also provide the context necessary for agents that answer in natural language.

The stakes are simple: in a world where AI agents become common analysis interfaces, context quality determines insight quality. Well-structured but poorly documented data will produce approximate or false answers. Data enriched with precise and usable business context will allow agents to deliver real added value.

For analytics engineers, it's an opportunity to evolve their role toward greater strategy and business understanding. Less time debugging complex SQL queries, more time structuring business knowledge in an exploitable way. Fewer static dashboards to maintain, more intelligent data architectures feeding autonomous systems. The role is transforming, but it remains at the heart of creating value from data.