Skip to content
Vibedata

How it works

The harness around your data engineering agent

Your data engineering agent. It builds and maintains data pipelines on the platform you already run.

Get startedSee it workWatch the demo
The gate decides what ships

The unit of work is an Intent

An Intent is what you intend to take to production. It survives chat turns and sessions, and carries its own agent, conversation, branch and workspace. Studio is the primary surface; Slack, Teams and other channels bind to the same Intent.

One unbroken line runs through three separate sessions to production, and three channels feed into the same line.
One Intent outlasts every session, and each channel binds to it.

Two loops, one Intent

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.

Two loops inside one IntentAn inner loop, labelled Build, and an outer loop, labelled Operate, drawn as two circles of equal size. A line runs from Build to Operate through CI, the gate and deploy lock. A return path runs from Operate back to Build, carrying detect-to-resolve work through GitHub Issues. A dashed rectangle encloses all of it and is labelled as one Intent.One Intent, from build into operateINNER LOOPBuildauthor · verify · shipOUTER LOOPOperatewatch · detect · resolveCIgate and deploy lockdetect-to-resolve work returns through GitHub IssuesTwo loops inside one IntentAn inner loop, labelled Build, above an outer loop, labelled Operate, drawn as two circles of equal size. A line runs down from Build to Operate through CI, the gate and deploy lock. A return path runs from Operate back up to Build, carrying detect-to-resolve work through GitHub Issues. A dashed rectangle encloses all of it and is labelled as one Intent.One Intent, from build into operateINNER LOOPBuildauthor · verify · shipCIgate anddeploy lockOUTER LOOPOperatewatch · detect · resolvedetect-to-resolve work returnsthrough GitHub Issues
The two loops are peers, so the circles are equal. The dashed rectangle is one Intent, holding both loops and the passage between them.

Build

The inner loop

Author and iterate. An Intent starts from a Linear ticket, a request as written, or an agreed spec. Vibedata reads the Domain you already run, then takes that input to an approved spec. See how it works →

Operate

The outer loop

Watch production, catch drift and resolve it. The observability that checks the build also watches production for anomalies, freshness and volume.

Architecture

The data team drives Intents into the Vibedata runtime, which coordinates the loop from build to operate and these planes: ingestion & transformation, CI gates as the verification mechanism, automations, observability & cost, compute management, credentials, context & knowledge, and LLM profiles for model-tiered routing. Two blocks connect to the runtime. Integrations holds source connectors, the plugin marketplace, LLM endpoints and MCP. The Domain holds your data platform and your code, and the runtime reads only its metadata, code and execution traces.
From Intents to your data platform: Vibedata architecture
PlaneJob
Ingestion & transformationdlt and dbt as your platform's native objects: standard code you own.
CI gatesChecks a production merge cannot skip, plus a deploy lock.
AutomationsScheduled and event-driven headless runs, with or without an Intent.
Observability & costQuality and spend tracked across every Intent.
Compute managementA per-Intent ephemeral workspace, built natively on each platform.
CredentialsA broker issues short-lived scoped keys; agents hold no standing credential.
Context & knowledgeSkills, docs and memory persist across Intents, in your repository.
LLM ProfilesPer-Intent model-tiered routing, budgets and caps; MCP in both directions.

Isolation

A semantic branch holds code and data. Vibedata works inside isolated code, compute and data, with no write path to production. Each platform does it natively. We build the isolation and the agent inside it.

One Intent branches code and lakehouse together

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.
How work gets triggered: Interactive and Autonomous modes

Who's driving

An Intent can switch modes mid-work.

  • Interactive: a person holds the edit lease and steers live.
  • Autonomous: it runs unattended to completion.

One driver is accountable at a time, and presence shows who's on.

One accountable driver at a time

Cross-platform

Isolation, guardrails and context are three of the four gaps. The fourth is cross-platform: the same loop, skills and gates on DuckDB, Microsoft Fabric and MotherDuck, built natively on each. Each Intent reads and writes on its platform.

Platform support, in three bands

Gates verify by executing against real data

A bad join drops a tenth of the rows and the dashboard still renders green. So every change runs independently against real data: tests, data diffs and reconciliation. CI gates production. The agent cannot pass the deploy lock behind it.

Evidence from real data, then the gate

One loop, from intent to operations

GitHub Issues carry detect-to-resolve work between the loops. CI and GitHub Issues are mechanisms; the work stays in Studio and other channels.

One loop, from intent to operations: Vibedata finds what is broken and ships the fix

Ship the change

Vibedata takes business intent to a pull request through Requirements, Design, Plan, Build, Verify, Ship. A person approves requirements, design and plan, and merges the PR. It also fixes what it finds in production: it explains, investigates or remediates, at the depth the question needs, and asks before changing anything.

Find what's broken

Vibedata watches the platform and raises breakages, quality violations, cost and drift as GitHub Issues.

Re-engineer something you own

Point the agent at a Spark notebook you already run, and it comes back as dbt and dlt on your platform.

Asset by asset, whenever the business next touches it. New work starts at Describe.

Three equal panels joined left to right by arrows. Discover, only if the asset already exists: the notebook’s cells, inputs and outputs are read, not guessed. Describe: the requirement, and the data slice it needs. Build: dbt and dlt, reconciled to zero mismatch, then shipped. A bracket marks Describe and Build as the same process new work follows. New work starts at Describe.
Re-engineer something you own: Discover, then the same process as new work

Model choice is a routing decision

Model-tiered routing by default: each lifecycle stage goes to a model tier. Frontier tiers take specification, design and review; cheaper tiers, generation and checks. Pin a model for any Intent, or let the agent choose. The gate decides what ships.

Agent-routed or pinned: one gate for every model

Every action leaves an audit record

Studio records every agent tool call, every external call and every state-changing action: who drove it, what ran, the outcome and when. Filter by actor, action, outcome or resource, export the records as JSON, and open any record's trace.

The Audit Records view: filters for time range, actor, action, outcome and resource, a table of records, and one record open with its request id, trace id and raw JSON
Each record opens to its trace

Where it runs, and what it reads

Vibedata runs in your own tenant. The harness reads metadata, code and execution traces. It never reads your rows: data-slice profiling is your agent, on your compute. After the merge, your CI/CD deploys; on DuckDB, CI runs static checks only.

Vibedata is deployed from your cloud marketplace into your own subscription, and runs in your own tenant beside your data platform and your agent. From the data platform, Vibedata reads metadata, code and execution traces, and reads no rows. Rows stay inside your tenant and go only to your agent, on your compute, which profiles a data slice through your approved model endpoints. The agent writes dlt and dbt code to your GitHub repositories, and your CI/CD deploys after the merge. On DuckDB, CI runs static checks only. Agents use scoped, short-lived credentials, and the audit log is tamper-evident.
Vibedata runs in your own subscription and reads no rows

Questions

What does Vibedata do from a business request to production?

It runs one loop: Intent, Requirements, Design, Plan, Build, Verify and Ship. Ship is a pull request that a person merges. Each Intent runs on its own branch and workspace.

What do I need before Vibedata can start?

Whatever you have: a Linear ticket, a request as written, or an agreed spec. Vibedata takes it from there to an approved spec.

How does it turn a vague request into a spec?

It explores your existing code and data first, then asks only the contextual questions it cannot settle. It profiles a data slice, then commits the requirements spec to git for you to approve.

Does Vibedata profile the data before it designs?

Yes. It profiles a data slice on your compute: the candidate input, evidence on grain, join and metric columns, a sizing verdict and join expectations, committed to git.

Where do humans stay in control?

A person approves the requirements, the design and the plan, and merges the pull request. Between build and production, CI runs deterministic gates and a deploy lock the agent cannot talk its way around.

How is the agent isolated from production, and can several run at once?

Each Intent has its own branch, conversation and ephemeral workspace, and builds only the models it changes, reading the rest from production. Several Intents run unattended in parallel on separate branches of the Domain repository.

Which models does it use?

Model choice is model-tiered, set per lifecycle stage and per Intent under your own keys. Frontier tiers handle specification, design and review, and cheaper tiers handle generation and mechanical checks; you can pin a model for any Intent. The gate decides what ships, never a model.

Does it remember my Domain and preferences across work?

Yes. It saves memory for you and for the Domain as it works. Terms go into CONTEXT.md, decisions into ADRs and designs into design records in your repository, so the next Intent starts with what the last one learned.

What can the agent access, and what stops it touching production?

An Intent's workspace has no write path to production, and each Intent receives only the credentials it needs. It cannot reuse the deployment's other credentials, and a service principal cannot drive an Intent. Each Intent session runs as the person who currently holds the driver seat.

Does it watch and fix production after the pull request merges?

Yes. Vibedata reads runtime evidence and files triaged issues, and fixes only an allowed failure class with concrete evidence and a sandbox check. A fix that involves data loss, a decision or a wide blast radius goes back to a person.

How do I control what it spends?

You can set a monthly USD cap for the whole deployment and a narrower optional cap per Domain, and a run can be stopped when its run budget is exhausted. With no cap configured, that scope is unlimited. Model usage is recorded against the Intent, Domain and organization that own it; the cost shown is an estimate, not an invoice.

Can my team work on the same task at once?

Several people can watch one Intent, but only one person drives it at a time. Sharing grants access to the Intent without handing over the current driver's authority. Pausing releases the driver seat.

Can it use my other tools, such as MCP servers?

Yes. An administrator makes an MCP deployment available, each user connects their own account, and an Intent session receives only the tools usable by the person driving it. Two users in the same Domain can see different tools.

How do I know my estate is ready for an agent?

Agent Readiness (ADER) measures your estate against thirteen dimensions in two groups: Safety (M1 to M8) asks whether an agent can act without breaking things, and Correctness (S1 to S5) asks whether it can be right. It measures the estate and rates no vendor or platform. Read the model.

How do I see what the agent did and diagnose a failure?

Studio exposes permission-checked diagnostics over logs, metrics, traces and audit records, from a telemetry stack that runs in your own subscription.

Get started, or see it work first.

Get startedSee it work