What an AI-agent-native data platform actually needs
Agents now do data engineering. The bar for a platform that can run them safely has a name — ADER: Autonomous Data Engineering Readiness — and it comes down to four things: Context, Control, Choice, and Cost.
Four things, above your platform
Governing agents in data engineering takes more than deciding what they may access — it takes governing what they actually do, plus a fourth axis, Cost, that access framing leaves out. Each axis bites differently when the work is data:
Context (M1–M4): Context that persists and compounds, not a metadata layer served on request — durable specs, accumulating knowledge, observability, one Intent from build into operate. Why data is different: perfect SQL can still be wrong because of what the data contains — grain, semantics, source quirks.
Control (M5–M8): Govern what agents do, not just what they can reach. Access control says who can read a table; Control says whether a wrong change can ever ship — gates verify every change by independent execution, and the gate result decides when work is done. Why data is different: a bad change fails quietly — a bad join drops 10% of rows and the dashboard still renders green.
Choice (M9): Whatever you already have and already pay for, native per platform, any channel — one accountable driver at a time. Endpoint neutrality is the floor; routing is the point — model choice is a decision per lifecycle stage, with gates holding quality on every tier so you ride the price curve down. Cross-platform by construction. Why data is different: code is portable, but data has gravity — lock-in lives in the warehouse dialect, governance, and bill.
Cost (M10): Spend you can see and cap: per-run attribution down to the turn, budgets and caps at the policy point. Why data is different: a runaway loop spends warehouse compute on every scheduled run, not just tokens.
A readiness score, not a maturity vibe
ADER turns the four Cs into a measurable capability set, scored 0.0 to 1.0 on one durable primitive. ADER 1.0 is the complete set — and most platforms land well below it. It breaks into 10 markers and about 30 sub-markers. The contribution is assembling the full list and evaluating platforms against it.
Grounded, not theoretical: poor data quality already costs the average enterprise about $12.9M a year (Gartner), and 40% of enterprise apps will run task-specific AI agents by 2026 (Gartner).
The full set, grouped by the four Cs
Context — durable, compounding grounding:
M1: Durable requirements & spec-first — without a durable spec, an agent executes literally and ships the wrong outcome.
M2: Accumulating, portable knowledge — quirks, house rules, and incident fixes must compound and outlive any session.
M3: Observability, lineage & documentation — an agent must see what it did, what the data did, and what already exists before it changes anything.
M4: Full lifecycle on one primitive — an agent that only builds, or only operates, leaves half the lifecycle uncoordinated.
Control — govern what the agent does:
M5: Three-level isolation — a wrong hypothesis must be disposable; without isolation, one wrong action corrupts shared code, compute, or data.
M6: Verification against real data — silent data failures throw no error; an agent must prove a fix on real data, not tidy unit tests.
M7: In-loop gates with a deploy lock — quality must be enforced as deterministic gates the agent cannot skip, not prompt requests it can ignore.
M8: Governed access with data staying in the perimeter — the agent must act under scoped, short-lived credentials, and raw data must never leave the perimeter.
Choice — reachable anywhere, on your existing stack:
M9: Multi-channel, multi-user coordination — agents must be reachable where the work happens, one accountable driver at a time, surviving a dropped surface.
Cost — spend visible and capped:
M10: Per-run cost attribution and control — agents scale unpredictably; spend must be attributable and capped before the bill surprises the team.
Why no one clears the bar yet
Every marker is already practiced somewhere. What is missing is the priority to assemble all ten into one coordinated lifecycle — spec → CI → deploy → operate — above the platform. Mature platforms are strong on observability and governed access (M3, M8) because those are commoditized; they stall on full lifecycle on one primitive (M4) and in-loop quality gates with a deploy lock (M7), because their agent layers exist to drive consumption of their own platform, not to own the whole requirements → build → deploy → operate lifecycle across platforms. Those two markers are where trust is decided: one primitive spanning build and operate, with gates that verify every change by executing it, is how hallucination is handled structurally. M4 and M7 are cleared by no platform assessed.
The markers also interlock, which is why the list is not a menu. Gates without isolation is a gate with no floor; verification without a durable spec verifies the wrong thing. Give an agent half the list and you do not get half the value — you get silent failure that demos well.
And whoever would assemble the missing pieces is an already overworked data team. Data engineers already lose 53% of their time to maintaining pipelines rather than building new ones (Fivetran, 2026), and spend about 40% of their time troubleshooting data quality — roughly 793 engineering hours a month on the average team (Monte Carlo, 2022). They do not have the time to build and maintain a coordination layer on top of a generic coding agent — and "build it yourself" drifts every time the models change.
Vibedata: the category layer above your platform
Vibedata brings the four Cs above whatever platform you run, on one durable primitive, the Intent — the goal you hand the agent. It covers each C across the lifecycle, while isolated runs keep changes away from production state.