Analytics Engineer Future With AI Agents: The Semantic Layer

The weekly revenue review is five minutes in when someone notices the problem.

Sales has one number on the screen. Finance has another. Both came from the same warehouse.

An agent generated the query behind the Sales number. The SQL runs cleanly, the joins are correct, and there is nothing obviously wrong with the transformation. But Sales is looking at booked revenue, while Finance is reporting recognized revenue after adjustments.

The agent did exactly what it was asked to do. The problem is that nobody told it which version of “revenue” the meeting was actually talking about.

That is where the analytics engineer future with AI agents starts to look different. As agents become better at generating SQL, building transformation logic, documenting models, and answering questions directly from enterprise data, the harder problem moves away from writing every transformation manually. It moves toward defining the business meaning those transformations are supposed to preserve.

For the Analytics Engineer, that may become the bigger job.

The Analytics Engineer Is Moving Closer to Business Meaning

Analytics Engineering brought software-engineering discipline into analytical data. Instead of leaving business logic scattered across dashboards and one-off queries, teams moved it into reusable models where SQL could be tested, documented, and maintained more consistently.

That foundation is not disappearing, but more of the implementation work is becoming easier to automate. In a 2026 Snowflake-sponsored Omdia survey of 2,050 business and technology leaders, 59% of data analytics teams reported that they were already using generative AI or agents. That means AI is no longer sitting outside the analytics workflow; it is already becoming part of how teams prepare, query, and interpret data.

As that happens, the scarce skill starts moving. An agent may be able to generate a transformation that calculates revenue, but it still needs to know whether revenue means booked revenue, recognized revenue, gross revenue, or net revenue after returns. It also needs to understand whether that definition changes by business unit, market, or reporting purpose.

Those are not SQL questions. They are business decisions expressed through SQL.

The Analytics Engineer increasingly becomes the person who makes those decisions explicit enough that an agent does not have to guess.

dbt AI Automation Makes the First Draft Faster

The shift is already visible in the tools Analytics Engineers use. AI can assist with SQL generation, transformation logic, tests, documentation, and parts of the modelling workflow, which means the first version of a model can be produced much faster than before.

The interesting question is what happens after that first version is generated.

dbt Labs revisited its Semantic Layer versus text-to-SQL benchmark in 2026. After additional modelling was introduced, Claude Sonnet 4.6 reached 90% accuracy using text-to-SQL and 98.2% through the Semantic Layer, while GPT-5.3 Codex reached 84.1% with text-to-SQL and 100% through the Semantic Layer.

The important part is not simply that newer models have become better at writing SQL. Their answers improved when the business relationships and definitions were modelled more clearly. Better generation helped, but better context helped more.

That matters because a query that fails is easy to notice. A query that runs successfully and applies the wrong definition of revenue, margin, or inventory is much harder to catch.

The database does not know whether the CFO means recognized revenue while the Sales team means bookings. The model does not know either unless someone has made that distinction explicit.

The Number Can Be Right and Still Lose the Meeting

Go back to that revenue review.

Each number may be valid in the context where it is used. The problem starts when an agent selects one definition without understanding who is asking, what the number will be used for, and which reporting rule applies.

That becomes more important as conversational analytics hides more of the technical work from the person asking the question. A business leader may never see the SQL or the transformation model behind an answer. They simply ask for revenue for the quarter and receive a precise number within seconds.

Precision makes the answer look trustworthy, even when the definition underneath it is unclear.

Recent research shows why that matters. In a 2026 MIT Technology Review Insights survey of 400 senior data and technology executives, 55% said lack of business context was the primary reason agent-generated insights fell short.

The problem is not always that the agent lacks access to data. Sometimes it has the right data, writes valid SQL, and still does not understand the business context well enough to return the right answer for the situation.

The Semantic Layer Becomes the Shared Vocabulary

A semantic layer gives analytical systems a shared way to understand metrics, entities, relationships, and business definitions. Instead of every dashboard, analyst, or AI agent independently interpreting raw tables, those systems can work from definitions that have already been made explicit.

For AI agents, that makes the semantic layer much more than a BI convenience. An agent should not have to rediscover what revenue means every time someone asks a question, nor should it infer whether “customer” means an account, household, subscriber, or individual simply from table names.

Those definitions need to exist before the question arrives. The Analytics Engineer therefore starts owning more of the vocabulary behind the data: which metric is authoritative, which dimensions apply to it, how entities relate to one another, and where the same term legitimately has more than one definition.

This is also why the semantic layer becomes more important as the number of AI interfaces grows. Without a shared layer, every new analytics agent, copilot, dashboard, or application creates another opportunity for business logic to drift.

With one, the same definition can travel with the data.

The Same Word Can Mean Something Different by Industry

Business meaning also changes by industry, even when the technical structures look similar. Consider a word as simple as “available.” In retail, available inventory may depend on store stock, e-commerce allocation, reserved units, replenishment timing, promotions, and warehouse availability.

In manufacturing, availability may instead depend on raw-material stock, work-in-progress, production schedules, machine downtime, and supplier constraints. The data may still be represented as quantities, timestamps, and status fields, but the operational meaning behind those fields is different.

That is also why vertical context matters in observability. At Qualdo, the same idea shows up in how monitoring is shaped around industry-specific signals rather than generic technical checks. In retail, for example, that can mean looking at inventory, pricing, promotions, e-commerce, and supply-chain signals together.

For the Analytics Engineer, the implication is similar. A semantic model cannot stop at defining a column such as inventory_quantity; it needs to represent what inventory availability actually means in the business process using it. 

Semantic Modelling Is Also an Agreement Problem

There is another reason this part of the role is difficult: metric definitions affect people. Changing when revenue is recognized can change how a quarter appears. Changing what counts as a qualified lead can change a Sales target, while changing an inventory definition can affect replenishment and availability reporting.

These are not purely technical decisions. They affect how teams measure themselves, which means defining a shared metric often requires understanding why different teams use different versions in the first place.

Sometimes the right answer will be one standardized metric. In other cases, two definitions may both be valid, but they need clear names, owners, and usage boundaries so that an agent knows which one applies.

The important point is that the distinction should be intentional. An agent should not quietly decide it because one field or model looked more relevant than another.

That puts the Analytics Engineer closer to the conversation between business teams and the data model. The work becomes not only encoding a definition, but making sure the organization actually agrees on what that definition represents.

What the Analytics Engineer Role Looks Like in 2027

The role is not moving away from SQL or data modelling. Those skills remain the technical foundation, just as model knowledge still matters to the ML Engineer even when more of the surrounding work changes.

What shifts is where responsibility ends.

The Analytics Engineer increasingly owns the meaning underneath the transformation layer: what a metric means, where it applies, which business rules shape it, and what context an AI system needs before using it.

That requires SQL and modelling skills, but it also requires domain understanding, metric design, stakeholder alignment, and an understanding of how BI tools and AI agents consume shared definitions.

The engineer who can generate a clean transformation is useful. The engineer who can make sure every dashboard, analyst, and agent interprets that transformation the same way becomes much harder to replace.

FAQs

Will AI agents replace Analytics Engineers?

AI agents can automate more SQL generation, transformation work, documentation, and repetitive testing, but that increases the need for reliable metric definitions and semantic models. The role shifts toward defining and maintaining the business context that analytics tools and AI systems use when they interpret data.

What is a semantic layer, and why do AI agents need one?

A semantic layer is a shared set of business definitions, metrics, entities, and relationships placed above raw data. AI agents need it because technically correct SQL does not guarantee the correct business interpretation. A semantic layer gives different tools and agents a consistent vocabulary to work from.

Can AI write dbt models?

AI can already assist with SQL, transformation models, documentation, and tests. The harder problem is determining whether the generated model reflects the right metric definition, grain, relationships, and business rules, which is why automated model generation does not remove the need for Analytics Engineering judgment.

Why is AI-generated SQL sometimes wrong even when it runs?

A query can execute successfully while using the wrong definition, join, grain, or business rule. These failures are harder to spot because the result often looks plausible. Clear semantic models and business context reduce the chance of a technically valid query returning the wrong interpretation.

What skills will Analytics Engineers need in 2027?

SQL and data modelling remain important, but semantic modelling, metric design, domain understanding, and business vocabulary become more valuable. Analytics Engineers will also need to understand how AI agents and analytical applications consume those definitions so that business logic remains consistent across different systems.

Key Takeaway

The old Analytics Engineering problem was largely about turning raw data into reusable analytical models. The next problem is making sure every human and agent using those models understands the business in the same way.

AI will make more of the transformation work faster, but that does not reduce the need for Analytics Engineers. It moves the role closer to the definitions, context, and business meaning that determine whether an answer can actually be trusted.

The SQL may increasingly be generated.

The meaning still has to be engineered.

Coming next in The Data Role Rewrite

The Data Architect designing for systems that now rewrite their own structure overnight.