Claude BI: business intelligence where the agent is the interface

There is no product called Claude BI. There is a pattern, and enough people are building it independently that the phrase has started showing up in search. The pattern is simple to state: stop treating business intelligence as an application you log into, and treat it as a conversation with an agent that can actually reach your data. Claude does the asking and the reasoning. Something else holds the connections, the metric definitions, and the query engine. Nobody opens a chart builder.

This piece is about what that setup looks like when it's real — what it replaces, where it genuinely beats a traditional BI tool, and where it doesn't.

Why the classic BI stack feels so heavy

Almost every BI tool in wide use was designed around one assumption: a human will browse. That assumption produces a predictable shape — a connector layer, a modelling layer, a drag-and-drop chart builder, a permissions system, and per-seat pricing to pay for all of it.

If your actual need is "tell me which campaign is burning budget with nothing to show for it," that shape is mostly overhead. You don't want to browse. You want one number, correctly derived, and you want to know whether it's fresh. The chart builder is a detour, and the seat you're paying for is a license to walk it.

The heaviness compounds in three specific ways:

• Definitions drift. ROAS in the Meta report isn't ROAS in the Google Ads report isn't ROAS in the board deck, because each was computed by a different person in a different tool on a different day.
• Every question becomes a build. A one-off question gets a permanent dashboard tile, because that's the only place the tool lets an answer live. Six months later nobody knows which of forty tiles is still trustworthy.
• The export ritual. When the tool can't answer something, someone exports a CSV, and from that moment on the number is a snapshot with a decaying half-life.

What changes when the interface is an agent

Swap the browsing human for a coding agent and the whole middle of the stack becomes optional. Claude doesn't need a chart builder — it writes SQL. It doesn't need a drag-and-drop modelling UI — it reads a schema. It doesn't need a browsing surface at all, because it isn't browsing; it's answering a specific question you just asked in plain English.

What it does need is unglamorous and non-negotiable:

1. A standing connection to the data. Not a file you paste, not an export from last Tuesday. A live connection that keeps syncing whether or not anyone is in a session.
2. Shared definitions. If the agent re-derives ROAS from raw columns every time it's asked, it will eventually get it wrong in a way nobody catches — and confident arithmetic is the worst failure mode an analyst can have.
3. Honesty about freshness. An agent that doesn't know GSC runs a few days behind will cheerfully report a dip that is only reporting latency.
4. Somewhere for answers to live. Terminal output vanishes. If a result matters, it needs a URL other people can open.

That list is the entire job description of the backend half of a Claude BI setup. It is also exactly what TableBI is built to be — a data backend designed to be driven by an agent from a CLI rather than clicked by a human in a browser.

The three moves: pipe, ask, pin

In practice the whole workflow reduces to three verbs.

Pipe — connect each source once

Search Console, GA4, Meta Ads and Google Ads connect live through a browser OAuth round-trip. Anything without an API you care to wrangle — a TikTok Ads export, email platform stats — arrives as CSV and is normalized into the same definitions as everything else:

# install, log in, and teach Claude Code the tool exists
npm i -g @tablebi/cli
tablebi login
tablebi install

# live sources — browser opens for OAuth, then data syncs
tablebi connect gsc --site sc-domain:example.com
tablebi connect ga4
tablebi connect google_ads

# everything else, normalized into the same shape
tablebi connect csv --file tiktok-export.csv --platform tiktok_ads

Data lands at two altitudes, and the distinction is the point. Facts is one cross-channel table where cost is cost and clicks are clicks no matter which platform reported them. Underneath sit the raw per-platform tables — search_console_raw and friends — lossless, exactly as each source described its own world.

Ask — read-only SQL at whichever altitude fits

Cross-channel questions hit the unified layer, where metric definitions live as macros: roas, cpa, ctr, cpc, cpm, cvr, aov. The agent composes them; it does not reinvent the arithmetic:

# where is the money going, and what is it returning?
tablebi ask "SELECT platform,
             SUM(cost) AS spend,
             roas(SUM(conversion_value), SUM(cost)) AS roas
             FROM facts
             WHERE date >= (SELECT MAX(date) FROM facts) - 27
             GROUP BY platform ORDER BY spend DESC"

Forensic questions drop to the raw altitude, where nothing has been averaged away on your behalf:

# which queries are gaining impressions but no clicks?
tablebi ask "SELECT query, SUM(impressions) AS imp, SUM(clicks) AS clicks
             FROM search_console_raw
             WHERE date >= (SELECT MAX(date) FROM search_console_raw) - 27
             GROUP BY query HAVING SUM(clicks) = 0
             ORDER BY imp DESC LIMIT 20"

Note the date filter idiom: anchor on MAX(date) rather than today. Sources report on their own delay, and a query written against the calendar quietly reads a window that is partly empty.

Every answer comes back with a trust block — per-source freshness plus the caveats that keep an agent honest. One of the built-in ones says outright that GSC clicks and GA4 sessions are different populations and shouldn't be expected to match. Claude reads that and stops drawing conclusions from the gap.

There are lighter-weight readers too, for when you don't need full SQL: tablebi context --json rehydrates a session with definitions, connected sources, freshness and dashboards in one blob; tablebi metrics --metric roas --group-by campaign gives a quick ranked read; tablebi schema, tablebi sources and tablebi pending answer "what do I have, and what's gone stale?"

Pin — give the answer a URL

This is the move that turns a conversation into something a team can use. When an analysis is worth keeping, freeze it:

tablebi pin --title "Channel overview" \
  --widget "Daily clicks (28d)::line=SELECT date, SUM(clicks) AS clicks FROM facts …" \
  --widget "Spend by platform=SELECT platform, SUM(cost) AS spend FROM facts …"
✓ published → https://dk.tablebi.com/d/dsh_…  (public, read-only, self-refreshing)

The output is a live dashboard at a public read-only URL that keeps refreshing as sources sync. Nobody who opens it needs a Claude subscription, a BI seat, or an account. Here is a real one — Search Console data across a portfolio of sites, pinned exactly this way: