Why AI Agents Break Data Pipelines (and What Would Have to Be True for Them Not To)

AI coding agents are good at writing data pipeline code. They read schemas, draft SQL, wire up ingestion, and do it at a speed no human team matches. However, the stories that defined the last year of agentic data engineering are mostly about agents deleting things, corrupting things, and burning enormous amounts of compute discovering their own mistakes.

This post explains why we think that happens. The failures share a common shape, the root cause sits with the surface the agent writes to rather than with the agent itself, and there is a short, testable list of properties a data platform needs before agents stop breaking pipelines. You can use that list to evaluate any platform, including ours.

The generate-run-debug loop

Watch almost any AI agent build a data pipeline today and you will see the same loop. The agent generates code - a SQL file, a transformation script, a pipeline definition. It runs the code, or hands it to a scheduler that runs it later. Then it reads the runtime failure, guesses at a correction, and tries again.

Every step of that loop happens after the mistake was already accepted. The file saved without complaint, the SQL persisted without complaint, and correctness only shows up when the pipeline actually executes - which might be minutes later on a warehouse cluster, hours later on a schedule, or never, if the output is subtly wrong instead of obviously broken.

This is not a hypothetical concern. In July 2025, an AI coding agent at a major cloud coding platform deleted a production database during a live session, and the same month security researchers demonstrated a prompt-injection attack against a database MCP integration that exfiltrated private data through an agent with standing database access. Both incidents point the same way: guardrails have to be built into the system, because telling an agent to be careful is not a control.

The economics matter too. Every trip around the loop burns tokens on re-reading errors and regenerating code, and burns warehouse compute on runs that exist only to reveal a mistake. A failure that would have been cheap to catch at write time instead costs cluster hours, a debugging session, and a little more of the organization’s trust in the whole approach.

Why the surface accepts anything

The frustrating part is that the agent is behaving reasonably. The loop exists because the surfaces agents write to have no opinion about correctness.

A file system will accept any bytes, and a git branch will accept any diff. A SQL endpoint will accept any statement that parses, and the statement’s actual validity - whether the table exists, whether the column types line up, whether the join key is real - is only tested when the statement runs against the engine. None of these surfaces checks a write at the moment of the write, which is the one moment a correction is still cheap.

Human data engineers compensate for this with process: code review, CI, staging environments, and the accumulated caution of people who have been paged at 2 a.m. Those compensations were built for human volume and human speed, however, and an agent produces plausible-looking changes far faster than review can absorb them. Agent errors are also different in kind. Humans mostly make logic errors inside a schema they understand, while an agent will confidently reference a schema that does not exist, because to a language model a plausible column name and a real column name look identical.

So a hallucinated column name is accepted by the file, accepted by the repository, sometimes even accepted by a dry parse, and finally explodes at runtime, where the error message describes the symptom rather than the fix. The agent re-enters the loop with a stack trace written for a human and a context window filling up with its own failures. Agents break pipelines because the surface lets every mistake through and only reports it after the damage is done.

What would have to be true for agents not to break pipelines

If the problem is the surface, the fix is a surface with different properties. We think the list is short and specific, and each item below works as an evaluation criterion for any platform that claims agentic data engineering.

1. Validation at save time, not at runtime

The platform must reject an invalid write at the moment the agent attempts it, before anything persists. The validation also has to go deeper than shape, because checking that a config is well-formed JSON catches almost nothing that matters. The platform needs to parse the SQL expression, resolve the columns it references against schemas it actually knows, and check types and dependencies, all at save.

If invalid logic can still be saved and fail later, the loop has only moved - it has not gone away.

2. Errors written for machines, not just humans

A rejected write only helps if the agent can act on the rejection. A stack trace asks the reader to infer what to do next, which humans do well and agents do expensively. A machine-actionable error states four things:

• what is wrong;
• where it is wrong, down to the line and column;
• what call to make next;
• when to retry.

That turns a failure into one quick correction instead of a debugging session that burns a lot of tokens and risks losing important context.

3. A column-level unit of change

When the unit of change is a whole file or a whole table model, every agent edit carries a blast radius: anything downstream of the file might be affected, so every change demands re-testing, and two agents working in the same area need branches and merges to avoid collisions. Shrink the unit of change to a single column and the blast radius shrinks with it. DataForge already handles downstream validation for each updated column, applying name and data type changes automatically and raising an error when it detects an incompatible output schema change. Agents can build side by side in the same project while they are authoring, with no merge conflicts and no integration re-testing to combine their work, because two writes to two different columns cannot collide. Two agents going after the same column still take turns.

4. Sequencing guards

Data pipelines are full of temporal dependencies, starting with the most basic one: ingestion has to finish before the schema is real. An agent that queries for columns a half-second before ingestion completes gets an empty result, concludes the data does not exist, and confidently builds something wrong on top of that false belief.

The platform should convert “too early” from a silent wrong answer into an explicit structured one: not ready yet, retry in N seconds. Of everything on this list, this is the criterion we see discussed least, and silent sequencing failures are among the hardest agent errors to diagnose after the fact.

5. No bypass path

The last property protects the other four. If there is a raw connection, an escape hatch, or a relaxed mode for AI, the loop reappears exactly there, because an agent under pressure to complete a task will find the path of least resistance. The validation that applies to agents must therefore be the same validation that applies to humans, enforced by the platform, with permissions checked on every call and destructive actions gated. A guardrail with a side door is a suggestion rather than a control.

Where we stand

We built DataForge as a declarative data engineering platform where these five properties are the architecture rather than a feature flag, and the DataForge MCP server, which gives external AI agents access to that architecture, ships in DataForge 10.3. Every agent write passes the same save-time validation as a human edit in the UI: schema checks, SQL expression parsing, and role-based permissions on every call. Invalid changes never persist, and the agent gets back a structured error with the line and column of the problem, the exact next call to make, and when to retry. The unit of change is a single column. All of it is served by Talos, the AI control plane that also powers the assistant inside the product, and you can point your own client at it from the docs quickstart. As of July 2026, based on public vendor documentation, we have not found another data engineering platform MCP server that ships a sequencing guard, the “not ready yet, retry in N seconds” answer described above.

We put the mechanism through a real ERP integration and wrote up what happened.

Building a data solution has always taken three things: knowing the tools, knowing the architecture, and knowing what the data means. When the surface checks every write at the moment it is made, the first two stop being the work, and the third - which was always the valuable part - becomes the whole job. Good data engineers keep their jobs in that world, because reading data better than anyone else in the building goes from part of the work to all of it. A large share of what the market pays for today is tool expertise and architecture expertise, and that share shrinks as platforms absorb the mechanics. We say that as an observation about the market rather than a judgment about anyone in it.

The criteria stand on their own, so if you are evaluating any platform for agentic data engineering, ask the five questions above, and ask to see the rejection: what happens, precisely, in the first few seconds after an agent tries to save something wrong? The answer tells you whether the pipeline breaks in the demo or in production.

We did not cover every agent failure mode here, and we would like to hear about the ones we left out.