We’re open sourcing dbt Charts, a declarative language for dashboards, so that even the dashboards you build by chatting with an agent can be governed. AI for data is here, and the long-promised self-serve analytics is finally happening. Anyone with a data connection can chat a report into existence in an afternoon, and the first results are impressive.

The frictions show up fast, though. By default an agent turns one simple report into a pile of files: HTML, CSS, and Java Script, a couple of chart libraries, and a React or Streamlit app once it has to be live. Tracing a result back to its source means following it through several languages and files, which is slow for people to audit and costs the agent time and tokens on every change.

BI tools went the other way and bolted copilots onto their UI-first apps. That keeps the AI on governed rails, but narrow ones: the agent can do only what the UI exposes. So today you choose between the messy freedom of code and the narrow control of a BI tool.

We built a third option: skip ahead, or read on for how BI got here. Unbundling BI As dbt Labs founder Tristan Handy wrote recently in BI’s Second Unbundling: When I started in data, BI tools were full-stack. Everything happened inside one product: data ingestion, transformation, compute, caching, semantics, visualization, identity.

The BI tool was the data stack. Micro Strategy, Cognos, etc: they’re not just visualization tools, they’re integrated data platforms. Then the modern data stack happened.

From ~2015 to 2022, the infrastructure layers of that BI bundle got pulled out and turned into purpose-built infrastructure. Compute went to the Big 5. Ingestion went to Fivetran.

Transformation went to dbt. The BI tool was left with: visualization, interactive analytical interfaces, semantic definitions (sometimes!), identity and access management, and web hosting. Warehousing Big 5 ELT Extract Load Transform BI everything else What that unbundling left behind is the BI tool we know today, and charts are its biggest piece.

They stayed in the UI for good reason: for most people, clicking is quicker than writing YAML. But more and more charts won’t be made by people. As the front end and user of everything becomes increasingly a chat agent, this preference flips.

Agents are fluent in code, SQL, and Git, and clumsy in someone else’s UI. So charts need to move to where agents work: into code. Today we’re taking the next step in unbundling BI: we’re open sourcing dbt Charts, which takes charts out of the BI tool and puts them in code, specifically a new structured YAML language that can declare a full interactive dashboard in one auditable YAML file.

Chat freely with an agent, and what it makes has the freedom of code while staying easy to read. Warehousing Big 5 ELT Extract Load Transform New C Chart BI a few bits In dbt Charts, SQL remains the language for declaring WHAT data you want to see, and we wrap that in YAML to declare HOW you want to see it. We’ve spent a long time distilling the language to a few core, extensible elements: deep in what they can express, easy to organize and read.

The YAML wraps more than SQL. Markdown carries the prose, and Jinja, as in dbt, carries variables and macros. Here’s a small example: one variable (a UI filter), one query and one chart. variables: status: column: main.documents.status queries: doc_growth: | SELECT DATE_TRUNC('month', created_at) AS month, SUM(COUNT(*)) OVER (ORDER BY month) AS num_docs FROM main.documents WHERE {{ filter('status', status) }} GROUP BY 1 charts: growth: title: Documents created, all time type: area query: doc_growth x: month y: num_docs rows: - growth That file is the whole board.

The CLI renders any board file to static SVG, or to HTML, PNG, PDF, and even the terminal, on your laptop or in CI, and serves a folder of them as a site: dct render charts/documents.yml --format svg # or html, png, pdf, terminal dct serve Those few elements go deep: over 1,100 config options today, across sixteen cha...