AI dashboards for BigQuery, built by agents you control

AI dashboards for BigQuery, in dvt, means an agent reads your BigQuery datasets, writes SQL against your tables, and authors a versioned JSON spec: not a chat answer, not a static export, a live dashboard that runs its queries in your warehouse at view time. The spec is the same object whether a human builds it in the editor or an agent builds it from a prompt.

How dvt builds AI dashboards for BigQuery

Connect dvt to BigQuery as a data source, then connect an MCP-capable agent (Claude Code, for instance) to the dvt MCP server. Describe the dashboard you want: “build a revenue dashboard from the orders table, monthly trend, top customers, average order value by region.” The agent reads the table schema, writes the SQL for each panel, constructs the spec, validates it against dvt’s schema, previews the rendered result, and applies it. See the quickstart for the exact prompts, from listing your workspace to shipping a live dashboard.

Each BigQuery source is a named connection, and credentials never travel in a spec. A connection is registered by name, type, and auth method; its settings include the Google Cloud project (and an optional default dataset), and the service-account key is stored envelope-encrypted and never shown again. The connection’s name, such as prod_bigquery, is the sourceId a dashboard’s panels reference, so a spec says exactly which project every chart reads from.

{ "id": "revenue-by-month", "title": "Revenue by month", "type": "chart:bar",
  "data": { "rows": [{ "month": "Jan", "revenue": 120 }, { "month": "Feb", "revenue": 150 },
                     { "month": "Mar", "revenue": 178 }, { "month": "Apr", "revenue": 168 }] },
  "spec": { "series": [{ "type": "bar", "barMaxWidth": 48 }] } }

That’s one panel of the resulting spec: a plain, versioned JSON document, not a screenshot of a query result.

SQL pushdown: your project, your compute

When the dashboard renders, dvt pushes the SQL to BigQuery and only the result rows come back. dvt doesn’t copy your tables into a second database: the query runs as a job in your Google Cloud project, under the service account you configured, and shows up in your own job history. An agent building a dashboard inherits exactly the access that service account’s IAM roles grant. It can query what those roles allow, and nothing else. dvt also connects to Snowflake, Postgres, and Google Sheets, so a BigQuery dashboard can sit in the same workspace as one built from a different source.

Better inputs, better dashboards

An agent writing SQL against BigQuery doesn’t know which of three similar event tables is the one finance trusts, or that “active user” means a session in the last 28 days at your company. It writes what the schema tells it. dvt’s skills layer lets you write those conventions down once, as an org-scoped document (metric definitions, dataset semantics, house rules), and the agent reads it before it builds, so every future dashboard follows the same rules instead of guessing from column names alone.

Review before it ships

Because the spec is a document, not GUI state, a BigQuery dashboard an agent builds goes through the same review loop as any other dvt dashboard. Every write is validated and can be previewed before it’s applied. Every version is attributed to the human, agent, or system that made it. A reviewer can comment on a specific panel, and an agent can read that thread over MCP, fix the panel, and resolve it. That is dashboards as code, applied to the warehouse your team already runs.

See the format rendered in the live demo. Ready to point an agent at your own BigQuery project? Get early access.