Built for the DataHub Agent Hackathon
Three agents read your DataHub catalog — real schemas, real lineage — before a line of SQL exists, then validate every model against it.
THE RELAY
Three agents each run their leg and hand a structured package of context forward. Click any node to see what it does and which tool it calls — the last one hands the baton back to the catalog.
THE TEAM
One prompt asked to find the tables, read the schemas, write the SQL, check it and update the catalog will do all of it at once — and fail at all of it at once. Baton splits the work into three agents that each finish their leg and hand a typed package of context to the next. Not shared variables inside one function: a real hand-off, visible in the trace.
Works out what you are actually talking about.
BatonContext { entities, schemaMap, lineage, dialect }Everything downstream is only as good as this fact sheet, so it is gathered before a single token of SQL is written. Ambiguity surfaces here as a question to you rather than a silent guess buried three steps later — and even the SQL dialect is read from platform metadata instead of assumed.
Writes the model, then tries to prove it wrong.
CodegenResult { sql, modelName, validation, attempts }Writing and checking are deliberately different steps. A validator separate from the author produces a specific, machine-checkable complaint — “Unknown column: CUSTOMER_EMAIL” — which becomes a precise fix. A single mega-prompt can only be re-rolled and hoped over.
Ships the artifact and leaves the knowledge behind.
PublishResult { files, writeBack }This is the only lane that can change anything outside Baton, which keeps the blast radius in one place: write-back is a switch you control, and nothing reaches your catalog until the SQL has passed validation. It is also the step that makes the next run start smarter than this one.
The pay-off is that every hand-off is a checkpoint. When a run goes wrong you can see which leg dropped the baton — a table that resolved to the wrong dataset looks nothing like a column that failed validation — instead of re-reading one long answer and guessing.
WHY IT MATTERS
Ask a general coding assistant for a dbt model and it will confidently reference customer_email on a table that has no such column. It has never seen your warehouse.
Baton resolves every column against the schema DataHub actually reports, using sqlglot's schema-aware qualifier. Failures become a targeted correction, not a shrug.
The run ends by writing provenance back into the catalog. The next engineer — or the next agent — starts from what this one learned instead of rediscovering it.
THE STUDIO
The palette is deliberately narrow: every stage is a DataHub operation or a step that depends on one. This is a catalog-native builder, not a general workflow engine.
Compose the relay on a canvas from a palette of DataHub-native stages: search, schema, lineage, generate, validate, write back.
Prebuilt pipelines for the jobs people actually repeat — dbt model from two tables, documentation backfill, lineage-aware migration.
State the goal in plain language and let Baton lay out the pipeline for you. Then edit any stage before you run it.
IS THIS FOR YOU?
It does one job — generate data code that is grounded in your catalog — and it depends on that catalog completely. Here is where it earns its place, and where it honestly does not.
Analytics engineers on a catalogued warehouse
If your tables already live in DataHub with their schemas ingested, Baton reads what is really there. The better your catalog, the better the model it writes.
Platform teams fielding “can you build me a model?”
Templates plus graph rules turn a recurring request into something a teammate can drive safely, without handing them the warehouse.
Anyone burned by AI-generated SQL
If you have shipped a query that referenced a column which did not exist, the validation loop is the entire point of this project.
Teams whose catalog drifts out of date
Every run writes provenance back, so documentation improves as a side effect of doing the work instead of decaying between audits.
Teams without a DataHub instance
Baton has nothing to read, and no advantage over a plain chat model. The grounding is the product — not a feature you can skip.
Catalogs with names but no schemas
If DataHub only knows a table exists but not its columns, there is nothing to ground against. Ingest schema metadata first.
Targets other than dbt, for now
The artifact is a dbt model plus its schema file. Airflow DAGs, ingestion scripts and migrations are on the roadmap, not in the box.
Anyone needing a scheduler or auto-merge
Baton composes, generates and validates — then stops at a PR-ready file. Running models on a cadence stays with dbt Cloud, Airflow or your CI.
Every node lights up from a real tool call — no decorative animation. Run the demo trace or point it at your own catalog.
Open the Studio