Chat with your data — without handing it to another model

Most "chat with your data" products are the same product: your data, piped into an LLM they host, behind a chat box they own. That shape works, but you pay for it twice — your rows cross a trust boundary into someone else's model, and the numbers that come back are things a model said rather than things an engine computed. There's a second architecture that gets you the same conversational surface without either cost: keep the agent you already run (Claude Code) as the chat layer, and put a deterministic SQL engine with shared metric definitions behind it. You still ask in plain English; the difference is that every number is the output of a query you can re-run, and the only model in the loop is your own.

What "chat with your data" products actually are

Strip the landing pages away and the mainstream shape is remarkably consistent: connectors pull your warehouse, spreadsheets or SaaS data into the vendor's context; a hosted model — theirs, running on their infrastructure — translates questions, scans results and phrases answers; a chat UI wraps the whole thing. For the model to be useful it has to see your schema and a meaningful slice of your rows. That's not a bug in any one product; it's the architecture.

And to be fair, the pitch is real: non-technical teammates get self-serve answers without learning SQL or waiting on an analyst. If that's the constraint that matters most in your org, skip to the honest comparison at the end. But if you're an engineer who already lives in a terminal, the architecture deserves a closer look before you wire your data into it.

Two problems: data egress, and numbers you can't recompute

Problem one is the boundary. Feeding a hosted model means your schema, your metrics and a rolling sample of your rows now live in another vendor's inference path — one more processor in the security review, one more place a prompt log can leak, one more subscription priced per seat on top of the inference it burns on your behalf.

Problem two is deeper: verifiability. When an answer is synthesized by a model, "revenue is up 14%" is a sentence, not a computation. Text-to-SQL tools fixed half of this — at least there's a query to inspect — but the definition problem survives: the model improvises what "conversion rate" or "ROAS" means per conversation, and two people asking the same question can get two different numbers, each fluently explained. A number you can't recompute isn't data; it's testimony.

The alternative: your agent is the chat layer

If you work in Claude Code all day, you already own a conversational interface — one you've configured, one that runs under your API key and your data policies. So the move is not to adopt another chat product; it's to give the agent you have a data backend. That's what TableBI is: sources pipe in once via OAuth (Search Console, GA4, Meta Ads, Google Ads — CSV for anything else) and land in two altitudes — facts, one cross-channel table with unified definitions, and per-platform raw tables like ga4_raw or search_console_raw when you need source-faithful rows.

The division of labor is strict, and it's the whole point:

• Your agent is the brain. It hears the question, translates it to SQL, reads the result and does the interpretation. All of that reasoning happens in your session, on your key.
• The backend is the calculator. tablebi ask executes read-only SQL in a deterministic engine. Metric arithmetic is frozen as macros — roas(…), ctr(…), cpa(…) — so "ROAS" means one thing in every conversation, defined in the engine rather than improvised in a prompt.

TableBI hosts no LLM at all — $0 inference on the data side, by architecture rather than by discount — so your rows never transit another model. And the interface is deliberately plain plumbing: a CLI plus a skill that any capable agent can drive (see the BYO-agent docs); it just happens that Claude Code is the agent most engineers already have open.

What the conversation actually looks like

Setup is a one-time five minutes: npm i -g @tablebi/cli, then tablebi login and tablebi install to plant the skill in ~/.claude/skills (the full walkthrough lives in Claude Code for marketing). After that, every session opens with one rehydration call:

# definitions + connected sources + freshness + cheatsheet, one JSON blob
tablebi context --json

Then you talk. Not in SQL — in the register you'd use with an analyst who never misremembers a definition:

# you: "did paid actually drive conversions last month,
#      or is organic search carrying us?"
# your agent's translation:
tablebi ask "SELECT channel, SUM(conversions) AS conv, SUM(cost) AS spend,
             cpa(SUM(cost), SUM(conversions)) AS cpa
             FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28
             GROUP BY channel ORDER BY conv DESC"

One idiom worth copying: windows anchor to (SELECT MAX(date) FROM facts) - 28 — the newest synced day — because the engine precompiles and validates queries and rejects wall-clock functions like current_date. Anchoring to the data means a lagging source can never produce a silently empty week.

What comes back is rows from the engine plus the trust block, and then the model does the one thing models are actually good at with numbers: interpretation. "Paid CPA doubled in week three while search conversions held" is the agent's sentence — but every clause in it traces to a query sitting in your scrollback. If a number looks wrong, you don't argue with a chatbot; you read the SQL and re-run it. Disagreement becomes a diff, not a vibe.

And when a conversation produces something worth keeping, it doesn't die in the transcript: tablebi pin freezes the queries into a live, read-only dashboard URL that refreshes as sources sync — the sharing valve for everyone on the team who doesn't chat with data at all. The full query repertoire behind all this — raw-table forensics, more macros, freshness mechanics — is in Claude Code analytics.

When a hosted chat-BI tool is the better call

An honest comparison, because the two architectures serve different rooms:

• Choose hosted chat-BI when the people asking questions are non-technical, don't live near a terminal, and need a polished web chat box as the primary interface. Self-serve for a whole department is what that shape is built for, and no amount of architectural hygiene compensates if nobody actually asks questions.
• Choose your-agent-plus-backend when the person asking already works in Claude Code, when data boundaries are a real constraint (client data, security-review fatigue), and when you want numbers that are recomputable rather than narrated. The $0 marginal inference is a pleasant side effect rather than the point.

The two also compose. The agent-driven setup serves the non-technical audience through pinned dashboards — they get a URL that's always current; you keep the conversation in your own terminal. In practice that's the usual end state: one person chats with the data, and everyone else watches it.

FAQ

npm i -g @tablebi/cli && tablebi install