Making room for agents in your data stack

• Data Engineers build pipelines.
• Data Analysts turn questions into answers.
• Data Scientists build models.
• Dashboards distribute insights.
• Applications consume them.

Agents can do this all, but where do they belong?

How should you evolve your data stack to make room for them, or more importantly: where shouldn’t you?

The clearest answer we’ve found is data observability.

A good data observability stack recognizes when your data doesn’t look right without any agents involved. It can discover a stale table, an unexpected change in ingestion volume, a broken schema, or a value that moved outside the normal historical range. It can even figure out who might be affected and let them know.

An alert isn’t a resolution

Imagine that an upstream application changes the values in a field called customer_tier.

The field previously contained enterprise, business, and starter. One deployment later and the application suddenly begins sending growth instead of business.

Nothing necessarily crashes: ingestion completes, the warehouse receives the data, and the dbt transformation pipeline runs fine. From the perspective of traditional infrastructure observability, the system is 100% healthy.

But a downstream model still contains logic based on the previous values. Rows using the new naming scheme fall into an uncategorized group, and the reported revenue in the executive dashboard immediately drops.

A good data observability system will have deterministic data quality checks, monitor and alert on issues, and compute impact from lineage. But that alone won’t answer the immediate next questions:

• Why did the change happen?
• Where did the new values originate?
• Is it safe to revert?
• How do you safely fix it?

Answering those questions requires investigation.

The on-call data engineer might start with the failing monitor, inspect the affected column, run a couple queries to compare recent values, open the lineage graph, check pipeline runs, search recent code changes, contact the upstream owner, and inform the downstream user.

And that’s just to identify the root cause. At this point the on-call engineer still needs to update the transformation, add or modify tests, evaluate the downstream impact, verify the corrected output matches expectations, ensure backwards compatibility, and run backfills. Now imagine that alert landed at 2 am on a Saturday.

The alert may have detected an issue in seconds. Completing the investigation may take multiple painstaking hours or even days.

Investigation is where agents become useful

Data incident investigations are open-ended, evidence-heavy, and distributed across a bunch of different tools in both the software and data stack. They rarely follow one predefined workflow and require real, hard reasoning:

• Did the source stop sending records?
• Did a schema change alter the transformation?
• Did a deployment introduce new business logic?
• Is the anomaly isolated to one model, or is it a symptom of something upstream?

That makes it a natural place for agents. Monitoring can tell us that something changed and what it affects. An agent can determine why it changed, why it matters, what should happen next, and make sure it gets done. This is the goal of agentic data observability: give the agent the evidence produced by the observability stack and let it carry the incident from detection toward concrete resolution.

Agents will tirelessly validate or invalidate each hypothesis in parallel, without complaining about the 2 am PagerDuty alert.

This is also newly possible: models have only recently become trustworthy and good enough to sustain the long multi-step investigations across a suite of tools that have been historically necessary.

In our customer_tier example, a data observability agent takes the same dozens of investigation steps the human would and determines that the source application introduced a new naming scheme, and opens the backwards compatible PR before the on-call engineer has even woken up.

Lineage is especially important here because it represents more than a visual map. Standards such as OpenLineage model datasets, jobs, runs, inputs, outputs, and changes as connected operational evidence. An agent can use those relationships to move from downstream symptoms and impact analysis toward an upstream root cause.

From there, the agent could identify the team that owns the affected transformation, prepare an updated mapping, add tests covering both the old and new values, and evaluate the proposed change against historical data.

We get alerts enriched with investigations that say what changed, when, and where it originated. We know which assets were affected and who owns them, as well as what change would resolve the issue, and how the change is being evaluated.

This is the missing operating layer between detection and resolution.

The agent needs a model of the data system

None of this works if the agent begins with only an alert message and a database connection.

An alert contains a symptom. A schema describes what exists. Neither provides enough context to establish a root cause.

To investigate correctly, the agent needs a historical model of the data system. It needs to understand how assets normally behave, how they depend on one another, how they have changed, and how people and systems interact with them.

The foundational data observability model of metrics, metadata, lineage, and logs provides much of this evidence:

• Historical distributions and expected ranges
• Freshness, volume, and schema behavior
• Table and column-level lineage
• Pipeline and transformation history
• Recent queries and code changes
• Asset ownership
• Downstream dashboards and applications
• Previous incidents and resolutions

The quality of a data observability agent depends less on how confidently it can explain an anomaly and more on how much relevant evidence it can gather and how well it can verify its fix.

This distinction separates agentic data observability from a Claude or Codex pointed at a data lake. The agent is not being asked to produce a plausible explanation. It is being asked to investigate a changing system.

A useful investigation should therefore remain connected to its evidence. If the agent claims that an upstream change caused a downstream failure, it should be able to show the lineage path, the first appearance of the unexpected values, the related transformation logic, and the assets affected by the change.

The explanation matters, but the evidence is what makes the explanation useful.

From detection to proposed resolution

The traditional observability loop is often described as detection, triage, and resolution. In practice, observability products have automated much of the first stage while humans continue to perform most of the second and third. Agents provide a practical way to carry evidence and work between those stages: the signals become inputs to an investigation that can be taken to completion.

Not every incident will move cleanly through every stage. Some anomalies are expected business events. Some root causes are outside the data team’s control. Some incidents reveal genuine ambiguity that requires a conversation rather than a code change. An agent should be able to recognize those outcomes too. “The evidence is insufficient” is sometimes the correct conclusion, and may just inform the data team that the configured alert is too noisy.

Not every anomaly needs to have automated resolution, but we should be reducing the manual work required to reach the appropriate next step.

Humans remain the production boundary

An agent can collect evidence more quickly than a person navigating several tools. It can test multiple hypotheses, trace dependencies, prepare a change, and evaluate the likely result.

The decision to change production should still belong to a person.

This creates a practical division of labor. The agent performs the investigative work and prepares a reviewable and verified resolution. The responsible owner evaluates the evidence and approves (or rejects) the change.

After approval, the agent can apply the change and verify the production outcome against the original incident.

Human approval is what allows the system to automate the expensive parts of incident response without making an unreviewed production decision.

Over time, organizations may choose to automate narrow classes of predictable, reversible incidents. But that should be the result of repeated evidence, not the default behavior of every agent connected to the data.

What agentic data observability is, and what it is not

Agentic data observability does not mean using an agent for every monitor, query, or alert.

Historical models, deterministic checks, anomaly detection, and established tests remain better suited to identifying known and measurable conditions. If a freshness check can reliably determine that a table is late, there is no reason to ask an LLM about it.

The agent becomes useful after the signal exists.

Agents should not replace the parts of the observability stack that already work. They should connect those parts into a more complete incident response.

How we are approaching it at Embrasure

This is the idea behind Embrasure’s approach to agentic data observability.

Embrasure builds a historical model of production data, detects anomalies and deterministic failures, evaluates downstream impact, investigates upstream causes, and identifies the root cause and responsible owner. It can then prepare a fix, verify the proposed result, and present the change for human approval before it reaches production.

There is more to explore within each part of that process: how an agent separates correlation from root cause, how lineage becomes evidence, how ownership should be determined, and what verification should happen before a proposed fix is approved.

But the larger direction is already becoming clear.

Data observability gave data teams the ability to detect problems before their stakeholders did. Agents can help them understand and resolve those problems before the incident expands.

That is where agents can begin to earn their place in the data stack.