Build
The inner loop
Author and iterate: write a pipeline, test it, ship it. The Build agent works against a durable spec on a stack of dlt for ingestion and dbt for transformation; every attempt runs isolated from production.
How it works
The harness around your data engineering agent
A model writes SQL. It cannot give you somewhere safe to be wrong, a gate it is unable to skip, the context that tells a revenue mart from an application table, or the same loop on the next platform your team runs. The harness is the part that does, and it is the part we build.
The unit of work is an Intent
An Intent is a goal that runs: one durable objective the agents plan, execute and verify across many steps, from build into operate. It persists across chat turns and session closes. Each Intent carries its own agent, its own conversation, its own branch, and its own isolated workspace.
Work reaches an Intent through Studio and other channels. Studio is the primary surface; Slack, Teams and the rest bind to the same Intent, so a question asked in one place and a change made in another are the same piece of work.
Two loops, one Intent
Operate
The outer loop
Production operations: watch what is running, catch what drifted after the fact, and resolve it. The same observability that checks the build watches production for anomalies, freshness and volume.
One Intent carries from build into operate, which is why a fix arrives with the spec and the run history that produced the thing it is fixing.
Architecture
Vibedata's agent runtime carries each Intent from goal to production.
| Plane | What it does |
|---|---|
| Ingestion & transformation | dlt for ingestion, dbt for transformation — authored, tested, and reviewed inside the loop, as standard code you own and can walk away with. |
| CI gates & quality enforcement | The checks a production merge cannot skip, plus a deploy lock. |
| Automations | Scheduled and event-driven work that runs headless, with or without an Intent behind it. |
| Observability & cost | Quality and spend tracked across every Intent, so drift and overrun show up before they compound. |
| Compute management | Container clone, sandbox, and ephemeral workspace — three-level isolation, down to a zero-copy clone of the lakehouse, so a wrong attempt is disposable. |
| Credentials | A secret store and credential broker issuing short-lived, scoped keys, so an agent never holds a standing credential. |
| Context & knowledge | Runtime context assembled per session from skills, docs, and domain memory that compounds from every incident. |
| LLM Profiles | Per-Intent profiles set model-tiered routing, budgets, and caps — the gate decides what ships, never a model. MCP reaches the systems you already run in both directions: consuming external MCP servers and exposing the agent's own tools as one. |
Isolation
Code is easy to isolate: that is what a branch is. A semantic branch cuts both code and lakehouse, so the agent works inside the branch and has no view outside it. The harness isolates all three layers — code, compute, and data — so a wrong hypothesis is disposable.
The data layer is a zero-copy clone of the lakehouse. Reads pass through to live data; the write path onto production is absent. The clone is the concept; the mechanism is native to each platform, and we never claim one mechanism across all of them. We build the isolation, and we are the agent that works inside it.
Operating modes
How work gets triggered
- Channel: a person directs work through Studio and other channels, including Slack and Teams.
- Automation: a schedule or on-demand run.
- Sense: a signal the platform detects and acts on autonomously.
Who's driving
The same Intent can move between operating modes while work is in progress.
- Interactive: a person holds the edit lease and steers live.
- Autonomous: it runs unattended to completion.
There is one accountable driver at a time, and presence shows who's on, so unattended automation and hands-on work share the same lifecycle without stepping on each other.
Cross-platform
Isolation, guardrails and context are three of the four things a general coding agent lacks for data work. The fourth is cross-platform reach: the same Intent, the same gates and the same isolation, whichever platform the work lands on. In production today that is DuckDB (local), Microsoft Fabric, and MotherDuck.
Reach is the part that resists a shortcut. A clone, a data diff and a deploy lock are each native operations, and each platform names, permissions and bills them differently. The harness builds them per platform and presents one loop above them, so a team running more than one estate learns the loop once.
Gates verify by executing against real data
A silent data failure throws no error. A bad join drops a tenth of the rows and the dashboard still renders green, so an agent that proves its work with tidy unit tests has proved nothing about the thing that actually breaks.
Every change is verified by independent execution against real data: tests run, data diffs computed, reconciliation reported. CI is the gate on the handoff to production, and a deploy lock sits behind it that the agent cannot talk its way past. The gates decide when work is done.
Build, Detect and Fix
Build
Ships and modifies data products, from business intent to a deployed pipeline, through gated phases: frame, design, build, verify, publish.
Detect
Watches the platform and raises what it finds — breakages, quality violations, cost and drift — as enriched GitHub Issues. Read-only, always: it changes no code and no data.
Fix
Explains, investigates, or remediates, at the depth the question needs. It never merges its own fix: it asks before changing anything, and a person merges the PR.
GitHub Issues carry detect-to-resolve work between the loops. CI and GitHub Issues are mechanisms the harness uses, and the work stays in Studio and the other channels.
Model choice is a routing decision
Vibedata is model-tiered. Each lifecycle stage routes to the tier that fits it: frontier tiers where judgment carries the load — specification, design, review — and cheaper tiers where the work is well-specified, such as generation and mechanical checks. Routing is set per Intent, under your own keys.
The gates hold quality whichever tier wrote the change. The gate decides what ships, never a model, which is what lets you ride the model price curve down instead of re-qualifying the system every time the frontier moves.
Where it runs, and what it reads
Vibedata deploys in your own tenant — Kubernetes, or local Docker on one machine. There is no multi-tenant assumption anywhere in the deployment story. Agents act under scoped, short-lived credentials, and audit logging is tamper-evident.
The harness reads metadata, code, and execution traces. It never reads your rows. Row-level access stays with your agents, on your compute, through your approved model endpoints.
What the agents produce is standard dlt and dbt code in your own GitHub repositories. Remove Vibedata and the pipelines it wrote keep running.
The scored readiness framework for agentic data platforms — ADER — lives on the Accelerate Data site.