Isolation
Being wrong is survivable, because a wrong attempt is disposable.
Agentic Data Engineering
Your data engineering agent
Build and maintain data pipelines on DuckDB, Microsoft Fabric and MotherDuck. Vibedata agents work inside your environment, with verification gates controlling what ships. You keep your platform, code and keys.
The model is a commodity dependency. What we build is the world it works in.
AI needs data faster than your team can supply it
Every agent and AI feature demands its own trusted data products, and the number a team must ship is exploding. At the neck of the funnel, one data engineer still has to turn each request into a working pipeline. The backlog stacks up while only a trickle of finished data products reaches the teams waiting for it.
Building a pipeline is still measured in weeks, and 53% of a data engineer’s time goes to maintaining the pipelines that already exist (Fivetran, 2026), rather than to shipping the next one.
Most data infrastructure was built for humans running dashboards and ad-hoc queries, at human pace, with a human reading the result. Agents act on whatever they are given, at machine speed, and throw no error when they are wrong.
Most teams do have guardrails for this. They are written as instructions: review before merging, never touch production, always test first. An agent that can read an instruction can also reason its way around it, and a data change that breaks nothing loudly gives no one a reason to look. The agent-incident postmortems we have read converge on the same missing piece: somewhere the agent can be wrong on real data without production seeing it.
An agent working off broken data does not wait for someone to notice.
The world the agent works in
Vibedata is your data engineering agent, and the world around it. The agent carries context across Intents and runs skills and tools — Vibedata's own plus those you add as plugins — through scoped subagents.
Guardrails
Scoped to the data platform: schema changes, warehouse writes, and the deploy path.
Context
Data engineering context: grain, freshness, and which mart the business reads.
Cross-platform
Reach across the platforms your team already runs.
Every change is verified by independent execution against real data — that execution happens on your compute, inside your own environment, and what Vibedata reads back is metadata, code, and execution traces, never your rows. The gates decide when work is done.
Our vision: every data team will be able to ship with the production discipline that used to take deep engineering expertise — specs, tests, isolation, and CI on every change — at vibe-coding speed.
Build, Detect, and Fix, with a chain of accountability
The Build agent
Ships and modifies data products — ingestion and transformation together, from intent to a deployed pipeline.
The Detect agent
Watches the platform and reports problems and improvements, opening GitHub Issues for the Build or Fix agent to act on. It is read-only: it never touches your code or your data.
The Fix agent
Answers, investigates, and resolves, in a fast blast-radius-bounded loop with three depths: explain, investigate, remediate. It asks before it changes anything, and a person merges the PR.
It is built for two roles: the AI-native data engineer, who directs the Build agent on the build side, and the data reliability engineer, who works with the Detect and Fix agents on the operate side.
What's yours, and what's ours
Yours, and standard
- Your platform, your perimeter, your keys. Vibedata runs inside your own environment — Kubernetes or local Docker — and reads only metadata, code, and execution traces. It never reads your rows.
- dlt for ingestion, dbt for transformation. Standard code you own and can walk away with, the same on every platform: dbt models, dlt pipelines, and plain SQL that run anywhere. No proprietary formats.
- Your models, model-tiered and routed per lifecycle stage under your own keys. Model choice is a routing decision: 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. Your keys and your endpoints, with MCP both ways into the systems you already run. The gate decides what ships, never a model, so you ride the model price curve down.
- Your platform, with support built for it. The two lists below say what runs in production today and what is in the pipeline.
Ours, and native per platform
- A zero-copy clone of the lakehouse, wired into the agent that runs inside it. A wrong attempt is disposable, because the same agent that isolates the work is the one doing it. That is what makes it safe to hand the agent real work.
- Gates that verify every change by executing it on real data, and a deploy lock the agent cannot talk its way past.
- Intent — a goal that runs. One durable objective the agents plan, execute and verify across many steps, from build into operate.
In production today
- DuckDB (local)
- Microsoft Fabric
- MotherDuck
In the pipeline
- BigQuery
- Databricks
- Postgres
- Snowflake
See it run
The sandbox is a hosted environment seeded on DuckDB: author a pipeline, watch it fail a gate, ship it when it passes. Sign in with GitHub — provisioning is live.
If you would rather run it on your own stack from the start, the self-host starter pack has what your operators need before day one.