In the second half of 2024, we started building ChatBI so business teams could query data in natural language without writing SQL. After launch, simple queries went from half an hour to a few minutes, and complex analysis started moving from days to minutes. We later went further, turning data queries, audience segmentation, user profiling, behavioral sequences, and A/B evaluation into Skills that Agents could invoke.

To make those Agents reliable, we had to write down what analysts and data warehouse engineers carried in their heads: which table to use for a metric, when a field’s definition changed, which fluctuations were worth investigating, which conclusions showed only correlation, and when the Agent should refuse to answer. This knowledge used to be scattered across individual practitioners. Now it is becoming Context, Skills, and Evals that an Agent can read.

I call the layer that allows agents to use enterprise data reliably the Data Harness. The deeper we went, the clearer it became: it turns the tacit knowledge of data practitioners into infrastructure that machines can use. That tacit knowledge used to be the moat around many data roles.

Put simply, we are dismantling our own industry’s moat.

That raises a question worth taking seriously: how exposed are the main data roles to AI, and where can people go from here?

By AI exposure, I mean how much of a role’s core work is now in a form that an Agent can perform independently. Exposure does not mean the role disappears immediately. How many people a company ultimately needs will also depend on reliability, accountability, and whether lower costs create more demand. But when the time required to do the same work falls sharply, the old team size is hard to sustain. Whether that takes one year, three years, or longer, I do not know.

The overall view

Data roles look very different, but their old moats were surprisingly similar. People knew both how to get the work done and the rules that were never written down: which table could be trusted, who defined a metric, which plausible-looking result was actually wrong, and who to call when something broke.

Agents are weakening both advantages. Data Agents take on querying, analysis, and presentation. Coding Agents take on SQL, ETL, and platform code. The Data Harness turns knowledge that once depended on particular people into an organizational asset.

I do not know where the boundaries between these roles will eventually settle. What is already clear is that execution work inside each role is being compressed.

My overall view is still that the data function will contract. The pace will differ by role, but I do not expect any traditional data role to expand as a whole because of Agent adoption. Context, Eval, and governance create important new work, but they do not require many people.

Role by role

Analyst (BI)

This role has the highest exposure. There is little doubt about that.

For years, much of an analyst’s job has been translation: turning a business question into SQL, then turning query results into charts and reports. This layer has clear inputs and outputs, and its errors are relatively easy to verify. It is the part Agents can take on most readily.

The role will increasingly take on a dumbbell shape. At one end are analysts who work closely with decision-makers. Their value lies in knowing what to ask next and explaining the business changes behind the numbers. At the other end are people accountable for definitions and conclusions. Audit figures, financial statements, and externally disclosed numbers still need a person to sign off. The middle layer, whose main value is pulling data, preparing reports, and producing routine deep dives, will keep getting squeezed.

The people most at risk may not be junior analysts. Juniors are cheaper and can still handle foundational work. The more obvious cost target is the middle layer, where compensation has risen but the work can still be decomposed and verified. Better SQL and prettier reports will bring diminishing returns.

There is also a longer-term problem. Junior analysts used to build business judgment by spending years pulling data. As those entry-level tasks decline, companies will not automatically get more mature analysts. They will lose the old training ground. Analysts early in their careers should let Agents handle the mechanical work and spend more time asking, “Why does this number look like this?”

Data scientist (DS)

This role splits into two species.

The first is the execution-focused DS. Even before LLMs, machine learning platforms had already turned much of model building into setting parameters and running pipelines. Agents can now take on feature analysis, generate and modify code, compare experiment results, and prepare reports. For tasks such as text classification and information extraction, some problems that once required a specialized model can now be solved by calling a foundation model. The value of simply getting a model to run is falling.

But structured prediction problems such as churn prediction, pricing, and ranking cannot generally be solved with a single foundation model API call. The manual steps in the modeling process are changing faster than specialized models are disappearing.

The second is the DS who can define the problem. When the business presents a goal, they turn it into a testable question: what exactly should be predicted, whether to run an experiment or use historical data, which metrics and methods to choose, and what result would count as valid. An Agent can write code, run models, and produce a statistically polished conclusion. It cannot turn a badly defined question into a valid one, and it does not remove confounding factors.

Positions built mainly around executing models will decline. Statistical training still matters, but more of its value will lie in problem definition, experiment design, causal inference, and model validation. Knowing how to get a model running is no longer enough.

Data engineer

Data engineering is one of the largest functions on many data teams, so it may also see the largest absolute contraction.

At one end are execution-focused data engineers who take requests, write SQL, and set up schedules. They also carry the company’s definitions, lineage, and pitfalls in their heads: which table cannot be trusted, which field changed meaning. That used to be a real moat. But Data Context work makes this knowledge explicit in the semantic layer. The moat is filled in, often by the people who built it.

At the other end are data engineers who do business modeling. The value of a good data engineer was never in writing SQL. It was in turning messy business processes into reusable data models with consistent definitions. Semantic layers and Data Context are the same kind of work on a different technical medium.

The people most likely to remain are those who understand business modeling and metric governance best. For data engineers, getting even better at SQL will bring diminishing returns. Business modeling, metric governance, and ongoing semantic-layer maintenance are better places to invest.

Data platform engineer

This is the safest role in the short term, and the easiest one to misread.

Engineers are still responsible for performance, reliability, permissions, security, and cost. Coding Agents cannot yet take over production accountability. But they are compressing the work of writing services, configuring resources, and troubleshooting. Managed cloud services had already reduced the need for companies to maintain low-level clusters. Agents are continuing the same trend.

A Data Harness is not finished once it is built. Context goes stale, Evals need continuous regression testing, and permission boundaries and correction mechanisms have to evolve with new use cases. But continuous evolution does not mean a large team is always required. Once the core capabilities stabilize, more of the work shifts to Context maintenance, ongoing evaluation, permission governance, and production reliability and cost.

The advantage for platform engineers is that their skills travel well. Distributed systems and production engineering experience transfer to Agent infrastructure, inference platforms, and general backend systems. This may be a good path for an individual, but it is not a path available to the data workforce at large.

Data product manager

This role faces pressure on the product form itself.

I spent several years working on BI tools early in my career, so I feel this directly. Drag-and-drop reports, self-service analytics, and visual configuration all rest on the same premise: users cannot write query languages, so they need a graphical interface. Once conversation becomes the interface, many ad hoc questions no longer require someone to configure a report first.

Fixed dashboards will not disappear. Monitoring, reporting, and building shared understanding still need stable interfaces. But self-service BI is losing its position as the single entry point, and the product boundary will keep narrowing for data PMs who build these tools.

Data PMs now have to design when a question needs clarification, which results can be shown directly, which actions require confirmation, how users report errors, and how permissions are requested. In the past, they mainly designed how people used data products. Now they also have to design how people work with Agents.

That requires better technical judgment. At a minimum, a data PM should be able to run an Eval and understand whether an error came from the model, the Context, a tool, or the underlying data. A PM whose value is limited to gathering requirements and drawing screens is highly exposed as well.

One shared pattern

All five roles perform some kind of translation. Analysts translate business questions, data scientists translate statistical methods, data engineers translate business processes, platform engineers translate system complexity, and data PMs translate competing needs. The Data Harness captures the parts that can be described, repeated, and verified, then makes them available directly to Agents.

Work that once had to be repeated by many people may eventually require only a small number of people to maintain the rules and handle exceptions. That is why I expect the data function as a whole to contract, rather than simply shift headcount from one role to another. Agents create real new work, but Context, Eval, and governance require a limited number of people.

I do not know what the final data team will look like. But it will be smaller, with fewer execution roles and more weight placed on people who can exercise professional judgment and take responsibility for it.

Where to go from here

If someone’s main work is still pulling data, writing SQL, building reports, running models, or maintaining components, the risk is already high. These tasks are becoming easier to describe, decompose, and verify, while their cost continues to fall. Greater execution proficiency will not deliver the same return it once did.

Staying in the same role will still require changing the work. Analysts need to move from delivering numbers to explaining them and take responsibility for conclusions used in decisions. Data scientists need to define problems, design experiments, and validate results. Data engineers need to take on business modeling and metric governance. Platform engineers need to spend more time on architecture, security, and cost. Data PMs need to design how Agents are used and set boundaries on what they may do.

The Data Harness is another direction. Context has to be organized and updated. Evals have to run continuously. Someone has to design permissions and correction mechanisms, and recurring analysis workflows have to become Skills. The methods will gradually standardize, but the concrete problems will remain: which definitions have gone stale, which errors can affect business decisions, and how to contain the impact when a system fails.

Some people will also leave traditional data teams. Platform engineers can move into Agent infrastructure, inference platforms, and general backend systems. The statistical and experimental training of data scientists can be applied to experimentation platforms, model evaluation, and risk decisions. Analysts and data PMs with strong business knowledge can move closer to business and product decisions.