Data Agents With Write Access: What It Takes To Trust Them

Agentic data engineering is the move from a data platform that detects problems and hands them to a person, to one that closes them. This page follows a paper about the hard part of that move. Its argument is that a governed context layer is necessary and not sufficient. On the most realistic public benchmark for enterprise data work it knows of, roughly eighty-five per cent of wrong answers are attributed to planning and to implementation and extraction errors, not to failing to find the right table.

Key takeaways

• •The failures that dominate are failures of doing: roughly forty per cent planning, forty-five per cent implementation and extraction, fifteen per cent schema finding.
• •Data agents with write access change the stakes: a planning error in read-only analysis is a wrong number, with write access it is an incident.
• •Multi-agent data engineering makes authority definable: twenty narrow specialists, each scoped to the one slice of the estate it is allowed to change.
• •Human-in-the-loop agent governance lives in the path a change travels: consequence, blast radius and a named approver are settled before anything runs.

Why context is not enough for data agents

The industry's answer to agent unreliability has converged on one word: context. The paper agrees that a governed context layer is the correct foundation, and it names six failures that layer closes structurally: semantic mismatch, uncertainty laundering, freshness asymmetry, missing provenance, schema impedance and stale shared state. Then it makes the uncomfortable observation. Every one of those is a failure of knowing, and not one is a failure of doing. On the benchmark, only about fifteen per cent of wrong answers are schema finding. The other eighty-five per cent are agents that found the right data and then did the wrong thing with it.

Is it safe to give an AI agent write access to the warehouse?

The paper's position is that autonomous data agents are not made trustworthy by a better model. They are made trustworthy by the path a write travels, and four properties do that work. Consequence is classified before an action runs, and anything unrecognised is treated as high-consequence rather than harmless. Blast radius is traced along the real dependency graph rather than estimated. No agent promotes its own work into the tier the rest of the fleet reads as true, because a named human signs. And every change leaves a receipt. AI-native data workflows put software in the position of proposing production changes, so the approval path becomes the product.

A fleet of specialised data agents vs one coding agent

The architecture the paper describes is a fleet of twenty specialised agents rather than one generalist. They are MCP data agents: each is a separate server with its own tools, its own scope and its own declared authority over a slice of the estate. The reason is consequence, not capability. An agent holding the union of every capability holds the union of every authority, and the only control left is a request. Coding agent vs purpose-built data agent is a live comparison on the benchmark, where one bar is an off-the-shelf coding agent's own entry. The paper also states the cost, including one run lost to a startup race.

Human-in-the-loop governance, rollback and audit trail

Governance here is not paperwork around the product. In an AI-native data platform, the approval a human sees is one approval spanning pipelines, schema, quality, governance and cost rather than a queue of disconnected tickets, and the design fails closed when a step cannot answer. Autonomy is granted per task class, widest for reversible, blast-capped, high-frequency work and last for net-new pipeline construction. The paper is careful about rollback: verified reversal is listed as an open problem rather than a finished feature, because an undo that emits an event is not an undo. And it asks for a receipt, not an audit trail that records only whether code executed.

How to read a data agent benchmark

A benchmark reading is only legible with its grain, its trial count and its hint condition attached. The paper reports two numbers and never blends them. The exploratory single-run record is 75.9 task-grain micro Pass@1, forty-one of fifty-four, at n equals 1, with a Wilson 95 per cent interval of 63.1 to 85.4. The banked reading is pre-registered and multi-run: 0.6371 stratified and 0.6593 micro at n equals 5, roughly ten points below the flattering one. It claims no lead on the board. At fifty-four tasks the intervals are wide, and repeated trials on the same tasks are correlated, so more trials do not narrow them the way intuition suggests.

Frequently asked questions

What is agentic data engineering?

It is data platform work done by software that proposes and makes changes, rather than tooling that detects a problem and files it for a person. The paper frames it as a change in who the platform's primary reader is. The output becomes a proposed change with evidence attached, governance moves into the path that change travels, and the scarce resource becomes reviewer attention.

Why is context not enough for data agents?

A governed context layer closes the failures of knowing: semantic mismatch, uncertainty laundering, freshness asymmetry, missing provenance, schema impedance and stale shared state. None of those is a failure of doing. On DataAgentBench, the benchmark's own failure analysis attributes roughly forty per cent of wrong answers to planning and forty-five per cent to implementation and extraction errors, leaving about fifteen per cent as schema finding. Only that last slice is retrieval shaped.

Is it safe to give an AI agent write access to the warehouse?

The paper's answer is that safety comes from the write path, not from the model. Consequence is settled before an action runs, and anything unrecognised is treated as high-consequence. Blast radius is traced through the real dependency graph. No agent promotes its own work into the trusted tier, a named human signs, and every change leaves a receipt of what was proposed, what evidence supported it, who approved it and whether it worked.

How is a data-agent swarm different from Cursor or Claude Code on a warehouse?

A general-purpose coding agent pointed at a warehouse holds the union of every capability, and therefore the union of every authority, so the only remaining control is an instruction asking it to behave. The architecture the paper describes splits the work across narrow agents with declared authority over one slice of the estate, which is what makes a boundary enforceable in the path a change travels and makes improvement attributable per agent.

How is it different from the warehouse vendor's built-in data agents?

The paper does not compare named vendors. It compares classes of system, and it draws two distinctions. First, most tooling in this category stops at detection and leaves remediation to a person, while the architecture it describes closes the work through a governed write path. Second, analytics is one of ten categories of data work with public boards, and governance, incidents, security and cost work have almost no serious entrants.

What can the agents actually write?

The paper describes agents that resolve incidents, build pipelines, review transformations, evolve schemas, provision access, clean up cost and monitor quality, each scoped to its own slice of the estate. They write only where a human has opened that class of work. Autonomy opens first for reversible, blast-capped, high-frequency work such as an access request or a freshness miss, and last for net-new pipeline construction.

How do you roll back a bad agent change?

Honestly and incompletely. Reversibility is judged before an action runs, so every change carries a standing view of whether it can be undone, and unrecognised actions are treated as high-consequence. But the paper lists verified reversal as an open problem it has not finished solving. An undo that emits an event is not an undo, and a rigorous account has to measure the same metric, in the same system, after a settling window.

How do you evaluate data agents?

Report the grain, the trial count and the hint condition on every number, and never blend an exploratory single run with a pre-registered multi-run reading. At fifty-four tasks a Wilson interval is wide, and repeated trials on the same tasks are correlated, so most scores a serious system might post are statistically indistinguishable. One board is also not the field: it sits among forty-two public boards across ten categories, and five kinds of central data work have none.

The whitepaper this is drawn from

This article summarises Context Is Not All You Need, a Data Workers Research paper. The full paper carries the figures, the citations and the limitations section, and is free behind a short form.