Use cases
Agentic data engineering on the platform you already run
Your data engineering agent covers three use cases, and they run as one process. Data Product Delivery builds a change, Data Quality Assurance proves it, and Data Lineage & Traceability explains what production holds. From intent to trusted data.
Start from what you run
Connect the Git repository, lakehouse and secret store you already use. The agent reads your existing models and marts first. Agent Readiness then points to the work worth doing next.
Your estate points to the next useful work
Onboarding reads your estate and lists findings: the fixes that would unlock the most, and follow-ons from Intents you have completed.
Sample See the evidence, then choose
Each finding shows the evidence behind it, measured on your estate. A person chooses what to address.
Sample
Data Product Delivery
What am I supposed to modify or build? Delivery answers with a candidate change, requirements and tests, built in isolation, ready for assurance. The walkthrough, on your data platform (Microsoft Fabric in this example), splits airport revenue for the board.
The request arrives as it was written
An Intent starts from a Linear ticket, a request as written, or a spec you already agreed. Here the business request is pasted unedited.
Example: Microsoft Fabric Every change gets its own space to be wrong
Each Intent gets its own branch, conversation and workspace. It builds only the models it changes; Fabric reads the rest from production.
Example: Microsoft Fabric It explores first, then asks only what it cannot settle
It reads your code and existing marts before it asks anything. Here it asks which airport zones to include, using the Domain's own zone convention.
Example: Microsoft Fabric The answers become a requirements spec in git
The spec in git holds the objective, source, target, deliverables, acceptance criteria and what is out of scope. You approve it before design begins.
Example: Microsoft Fabric It profiles a data slice before it designs
Your agent, on your compute, profiles a data slice: grain, joins, sizing and reconciliation, committed to git. Terms land in CONTEXT.md, which every agent reads.
Example: Microsoft Fabric One design record per model, in git
The agent decides whether to extend a model or create one. Each record states the grain, every decision with its citations, and the options rejected.
Example: Microsoft Fabric Four human gates
A person approves after requirements, after design and after the plan. The fourth gate is the pull request, which a person reviews and merges.
Example: Microsoft Fabric The build runs on subagents
Model-tiered by stage, or pinned for the Intent. Isolation lets several Intents run unattended in parallel on one repository, each on its own branch.
Every requirement is verified with evidence
The plan in git gains its execution evidence: queries, test results and gate outcomes, checked against each requirement in the original spec.
Example: Microsoft Fabric It ends in a pull request
The output is native to Microsoft Fabric: Lakehouse, ingest pipeline, dbt job and semantic model. CONTEXT.md, ADRs and docs stay aligned with the code.
Example: Microsoft Fabric
Data Quality Assurance
Is this what you asked for? Independent checks on the airport pull request (tests, data diff, reconciliation) give a gate the evidence to promote the change, return it for correction or hold it. A deploy lock sits behind the gate.
Data Lineage & Traceability
What does this number mean? Take airport revenue: Vibedata explains, or investigates further, tracing it through sources, transformations, the spec, design records, ADRs, run history and memory. The result is an accepted explanation, or a new Intent.
What it remembers
Domain memory is shared; User memory is private to you, across projects. Each Intent session opens with both: pinned facts first, then the newest, within a budget, retired facts excluded. CONTEXT.md, ADRs, design records and AGENTS.md in git outrank memory.
The same loop on each platform
Vibedata runs on DuckDB, Microsoft Fabric and MotherDuck in production today. Four things differ by platform: the workspace, how unbuilt models are read, native output and promotion.
Questions
What are Vibedata's main use cases?
Three, run as one process: Data Product Delivery, Data Quality Assurance, and Data Lineage & Traceability. Together they take work from intent to trusted data.
What does Data Product Delivery answer and produce?
It answers 'What am I supposed to modify or build?' with a candidate change that has requirements and tests, built in isolation and ready for assurance.
What does Data Quality Assurance answer and produce?
It answers 'Is this what you asked for?' with independent evidence for a gate that promotes, returns the change for correction, or holds it. Checks run in isolation.
What does Data Lineage & Traceability answer?
It answers 'What does this number mean?' by tracing sources, transformations, definitions and decisions to an evidence-backed explanation, or to new intent when change is needed.
How do the three use cases connect?
Delivery feeds assurance, an independent promotion gate promotes to the production baseline, and lineage reads that baseline. Lineage either closes the question or raises new intent.
Two doors
Start in the hosted sandbox, or deploy from your cloud marketplace into your own subscription. Both run the loop on this page.