Point it at Databricks.
Walk away with insights.
DecisionBox connects to your Databricks workspace in a few minutes — no schema migration, no pipeline to build. The agent reads your Unity Catalog tables in place, runs read-only queries on the SQL warehouse you choose, and surfaces validated insights from what is already in your lakehouse.
Three things to know on day one.
Read-only, scoped by Unity Catalog
The agent connects with a Databricks principal you choose — typically a service principal with USE CATALOG, USE SCHEMA, and SELECT on the tables you want it to see. Unity Catalog's permission model is the access boundary; the agent cannot reach anything the principal has not been granted.
Runs on the SQL warehouse you choose
Pick the SQL warehouse in the project config via its HTTP Path. The agent runs all of its queries on that warehouse — the type (Serverless, Pro, or Classic), the size, and the Auto Stop you have already set are the cost control. No new compute, no second cluster to manage.
Reads your schemas in place
No tables to refactor, no data pipeline to stand up, no warehouse-side changes. Point DecisionBox at a catalog and a schema, and the agent picks up your tables on its first run — and re-checks them on every run after. Metadata is read from information_schema, not from full table scans.
You pick the SQL warehouse. You keep the cost controls you already trust.
Databricks bills SQL warehouses by DBU on the rate of whichever warehouse runs the query. Because the DecisionBox agent runs on the warehouse you point it at — Serverless, Pro, or Classic, whichever size, whatever Auto Stop you've set — every guardrail you have already configured for your dashboards and dbt jobs applies to the agent the same way.
Want a separate line item for DecisionBox runs? Create a dedicated SQL warehouse for the agent, set its Auto Stop and size, and put its HTTP Path in the project config. The agent never sees other compute.
Two ways in. Both are Databricks-native.
Pick the one that matches how the rest of your Databricks automation already works. Both options end at the same catalog, schema, and SQL warehouse you configured — what changes is how the agent proves it is who it claims to be.
Personal Access Token
Paste a Databricks personal access token in the project config. Stored encrypted, never written to logs. Good for a first run, a proof of concept, or a developer-only project.
OAuth M2M (Service Principal)
Create a Databricks service principal and an OAuth secret. Paste client_id:client_secret in the project config. DecisionBox uses the OAuth machine-to-machine flow Databricks recommends for any automation that should not depend on a human user's token.
Both options end at the same Unity Catalog grants you configured — USE CATALOG, USE SCHEMA, and SELECT on the tables you opted in, plus CAN USE on the SQL warehouse, and nothing more. If your security team has already approved how the rest of your stack talks to Databricks, they have already approved DecisionBox.
Open source, and not Databricks-only.
Open source, AGPL v3
Every line of the Databricks integration — the PAT and OAuth M2M auth flow, the Unity Catalog metadata reads, the SQL the agent writes — is in the public repo. Anyone can read and audit it before turning it on.
View the Databricks provider on GitHubNot locked to Databricks
The same agent runs against any of them. If your warehouse moves, your DecisionBox install moves with it.
Try it on your Databricks, in two minutes.
Clone the repo, run docker compose up, and point it at a Databricks workspace, SQL warehouse, and read-only service principal. Unity Catalog grants are all the agent ever needs.