The agent, and the world it works in
Vibedata is your data engineering agent, and the harness around it — the isolation, guardrails, context, and cross-platform reach a general coding agent lacks for data work. The harness is the product for defined data engineering workflows; the model is a dependency you route, stage by stage. Vibedata is built for two roles: the AI-Native Data Engineer, who directs agentic work on the build side, and the Data Reliability Engineer, who keeps it running on the operate side.
Vibedata runs two loops. The inner loop is where you author and iterate — write a pipeline, test it, ship it — with gates that verify every change by independent execution — tests run, data diffs computed on real data — and catch a bad change before it merges. The outer loop is production operations — watch what's running, catch what the gates missed or what drifted, and resolve it.
New to the category? Start with what an AI-agent-native data platform needs — the four Cs and the 10 ADER markers.
Build, Detect, Fix — one accountable lifecycle
Vibedata runs the Build, Detect, and Fix agents with a chain of accountability, each of which can use scoped subagents and tools — the skills, connectors, sandboxes, and checks bundled as plugins — so one agent can profile a source, generate and test a dbt model, run it in a sandbox, and open a PR without handing off to a different bot. The plugins are extensible: use Vibedata's, pull from the community, or bring your own.
Build
Ships data products — ingestion (dlt) and transformation (dbt) together, from business intent to a deployed, spec-first pipeline, moving through five gated phases (Frame → Design → Build → Verify → Publish). This is the build-side agent the AI-Native Data Engineer directs.
Detect
Watches the platform and reports what it finds — pipeline breakages, quality violations, and improvement opportunities like cost, drift, and missing checks — opening each as an enriched GitHub Issue for the Build agent or the Fix agent to work. It's read-only: it finds problems and raises issues; it never changes your code or your data.
Fix
Answers, investigates, and resolves a question or issue — one loop, three depths: explain, investigate, remediate. Fast and blast-radius-bounded. It never merges its own fix — it asks before it changes anything, and a human merges the PR. Works with the Data Reliability Engineer to keep production healthy.
How the harness coordinates above the platform
The unit of work is the Intent — a goal that runs. One durable objective the agents plan, execute and verify across many steps, from build into operate; each one carries its own agent, conversation, branch, and isolated workspace. Your data team drives Intents; Vibedata's agent runtime carries each one from goal to production and coordinates the planes that make that safe:
| 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. The clone is the concept; the mechanism is native per platform. Vibedata builds the isolation and is the agent that works inside it. |
| 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. |
Model choice is a routing decision per lifecycle stage — frontier models where judgment carries the load (specification, design, review), cheaper tiers where the work is well-specified — and the gates hold quality regardless of which tier wrote the change, so you ride the model price curve down.
The whole runtime runs inside your perimeter and reads only metadata, code, and execution traces — never row-level data. Row-level access stays with your agents, inside your environment, on your compute, using your approved model endpoints.
One lifecycle, many operating modes
The same Intent can be driven different ways — and move between them mid-flight.
How work gets triggered
Work is invoked three ways:
- Channel — a person directs it through a surface (webapp, Slack, Teams).
- Automation — a schedule or on-demand run.
- Sense — a signal the platform detects and acts on autonomously.
Who's driving
Every Intent runs in one of two operations:
- 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.
Run it before you read any more about it
The sandbox is a hosted, hands-on environment seeded on DuckDB. Run the inner loop — author, iterate, ship — with no install and no tenant setup.
Sign in now — provisioning is live. You get your own demo domain and your own GitHub repository, with three worked examples already in them. The recorded walkthrough is open to everyone in the meantime.
See it against your own stack
Ready to go deeper? Join the next community call or workshop to talk to the team running it.