AI won’t fix your data problems. Data engineering will

Most enterprise AI investments today focus on models, compute and tooling. The assumption is that intelligence is the binding constraint and that a more capable model will produce better outcomes across every dimension that matters. This is a reasonable starting point, but it is also where most initiatives go wrong.

The models organizations are deploying were trained on public data at scale. None of your internal systems, customer schema, pricing logic or support taxonomy appeared in that training.

When a model encounters your internal data, it processes it as best it can, but without the grounding that comes from having been trained on it. Early AI initiatives are struggling not because the models are weak, but because the context they need to operate reliably inside your organization is something they have never seen before.

Data engineering holds the key to this context.

Why context breaks first

Think about what an AI agent handling a support escalation needs to function well: The customer’s support history across time, not just the most recent ticket. Billing records matter too, because the character of a problem often depends on what the customer is paying for and whether anything has changed recently. Product usage data is equally essential, as what a customer reports is frequently explained by how they have been using the product. None of these things live in a single place, as they are scattered across systems that were each built by different teams, on different timelines, with different definitions of what a customer record is supposed to capture.

Human agents work around these gaps through judgment developed over time. They know which system to trust for a particular type of question, they know the usage data runs six hours behind and they know how to weigh conflicting signals based on context that is never written down anywhere. AI systems do not have that judgment. They process whatever they receive and act on it, which means that when the context is inconsistent or incomplete, the output reflects that, not as a visible error but as a subtly wrong decision. The customer notices before anyone on your team does.

When bad data stops being annoying and starts being operational

In the analytics era, data quality problems surfaced as numbers that looked off in dashboards. Analysts were the error-detection layer, and when something looked wrong, they would investigate, find the issue and get it fixed. The feedback loop was slow, but it existed, and it caught most problems before they reached the business in any consequential way.

AI agents making operational decisions do not have that buffer. They have no way of knowing that a schema migration introduced silent gaps or that a pipeline is running four hours late. Refunds go out incorrectly because the billing context was incomplete at the moment of decision.

What an analytics team could absorb as an occasional anomaly in a report becomes a real problem when an automated system acts on degraded context hundreds of times a day before anyone identifies the pattern. The volume is what makes it dangerous, and by the time it surfaces, the damage is already distributed across thousands of interactions.

The role data engineers play now

For the past decade, data engineering meant building pipelines that fed warehouses so analysts could query data and produce dashboards. The work was foundational but treated as background infrastructure, and its value was measured in pipeline reliability, query performance and reporting freshness.

The agent era changes the purpose of that work entirely. When AI systems make operational decisions, the goal is no longer producing data that is queryable. The goal is producing context that is reliable enough for a system to act on, and those are different problems with different requirements. That starts with entity resolution across systems, providing a consistent and trustworthy answer across every data source that touches them.

This also means handling late-arriving data explicitly, because agents cannot act on a state of the world that no longer holds. Freshness thresholds need to be calibrated to the decision type, since a personalization recommendation can tolerate six-hour-old usage data in ways that a refund workflow cannot. Lineage needs to survive schema changes and reorganizations, so that the provenance of any piece of context can be traced when something goes wrong.

None of that is a model problem, nor does it yield to prompt engineering. This is data engineering work, and organizations that treat it as anything else will spend a long time debugging production failures that look like AI problems but are infrastructure problems.

Context is only half the problem

Getting the right information to an agent is necessary, but it is not sufficient. There is a second challenge that most organizations have not yet confronted: How do you coordinate, govern and operate dozens or hundreds of autonomous agents making real decisions across your business?

Agent frameworks handle reasoning well. What they do not handle is everything around the agent: Scheduling when it runs, controlling what it is allowed to spend, enforcing who can approve its decisions, managing retries when external systems fail and ensuring that when an agent needs human sign-off, it does not tie up compute for hours while it waits. These are not AI problems. They are operational infrastructure problems, and they are the same class of problems that orchestration platforms have been solving for data pipelines for over a decade.

One agent answering questions in a sandbox is a proof of concept. Fifty agents making operational decisions across finance, compliance and customer operations is a fleet management problem, and it requires the same kind of scheduling, governance, cost controls and auditability that enterprises already demand from their data infrastructure.

Orchestration is typically the one layer that already has visibility across platforms, spanning your warehouse, your transformation layer, your external APIs and your operational databases. That cross-platform vantage point is what makes it possible to build a context layer that is comprehensive rather than siloed.

Governance needs to execute at runtime, not live in documentation. Policies about data access, cost limits and human approval requirements need to be enforced in code as agents run, not described in guidelines that agents cannot read and humans forget to follow.

What this means going forward

The organizations that deploy AI agents at scale will have invested in two things before those agents reach production.

First, a context layer that gives agents a reliable, cross-platform understanding of the enterprise’s data. This means not just raw access to tables, but semantic knowledge of what the data means, where it comes from and how much to trust it.

Second, an operational layer that governs how agents act, with the scheduling, cost controls, auditability and human-in-the-loop checkpoints that enterprise deployment demands.

These two investments are not independent. They form a flywheel. Better context makes agents more effective, which drives broader adoption, which generates richer operational metadata, which deepens the context layer further.

Data engineers are becoming the people who determine whether automated decisions are trustworthy, not because they control the models but because they control both the context on which those models operate and the infrastructure through which they act. The organizations that understand this early will keep building on it. The ones that keep treating data engineering and orchestration as background infrastructure will keep rediscovering the same production failures, just with different names on the postmortem each time.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?