A client reporting tool your AI agent drives

A client reporting tool has one job: put numbers your client trusts in front of them, without eating a day of your month per client. Most tools in the category do it with connectors, drag-and-drop templates, and a PDF at the end. This guide walks through a different shape: TableBI, a data backend driven by an AI agent, where the deliverable is one live, self-refreshing dashboard URL per client — the agent writes the queries, the link never goes stale, and the monthly rebuild simply stops existing. If you're a freelancer or a small shop and "reporting week" is a real thing on your calendar, this is written for you.

The monthly reporting grind, itemized

Here's what hand-built client reporting actually costs, per client, per month:

• Four exports — Search Console, GA4, Meta Ads Manager, Google Ads. Each with its own date-picker ritual, its own CSV dialect, its own idea of what a "conversion" is.
• The master spreadsheet — paste, fix the columns that shifted since last month, re-point the pivot tables, pray nothing silently broke.
• The deck — screenshot charts, align boxes, write "what happened" bullets at 11pm the night before the call.
• The definitions fight — the client opens GA4 themselves, sees a different number than your slide, and now the meeting is about your credibility instead of their marketing.

Multiply by every client on the roster. The insidious part is that none of this is analysis. The judgment about what to do next — the thing clients actually pay for — gets squeezed into whatever minutes are left after the plumbing.

A client reporting tool that ends in a link, not a PDF

The fix isn't a faster PDF factory. It's changing what the deliverable is. One client = one live dashboard URL:

• Connect the client's sources once, via OAuth. No more exports.
• The dashboard refreshes itself — it re-pulls from sources when someone opens it and on a schedule — so the link you sent in March is still correct in July.
• Delivery becomes: send the link once. "Monthly reporting" collapses into "monthly analysis" — you add judgment, not screenshots.

TableBI's particular twist is who does the work. It describes itself as "the data backend for your Claude Code" — Claude Code being Anthropic's terminal-based coding agent. The division of labor: your agent is the brain (it writes the SQL, reads the results, drafts the narrative), and TableBI supplies the data and freezes the output into something a client can open. The whole workflow is three verbs: Pipe data in, Ask questions, Pin the answer to a URL. TableBI hosts no LLM of its own — inference cost is $0, and every number comes from a deterministic SQL engine, so what the client sees is traceable, not generated.

Set it up: one workspace per client

Install the CLI and teach your agent to drive it:

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

Then connect each client's sources into that client's own workspace, using the -w flag. Workspaces are hard walls: sources, queries and dashboard URLs in one client's workspace can never surface another client's data.

# each client gets their own workspace — OAuth opens in the browser
tablebi connect gsc --site sc-domain:example.com -w acme
tablebi connect ga4 -w acme
tablebi connect meta_ads -w acme
tablebi connect google_ads -w acme

# anything without a live connector comes in as CSV
tablebi connect csv --file tiktok-export.csv --platform tiktok_ads -w acme

Data lands in two altitudes. The facts layer is cross-channel and definition-consistent — spend is spend and a conversion is a conversion whether it came from Meta or Google. The raw layer (search_console_raw, meta_ads_raw, and so on) keeps each platform's native rows lossless, for when you need to drill into exactly what the platform reported. If you're running this at agency scale — dozens of clients, a Monday deadline — the agency reporting tool guide covers the multi-workspace economics in detail.

Ask: the client's numbers, in consistent definitions

From here, reporting questions are one command away. Your agent writes read-only SQL against the client's workspace, with definition macros (roas, ctr, cpc, cpa…) so arithmetic never gets re-derived wrong:

# the client's whole paid + organic picture, last 28 days
tablebi ask -w acme "SELECT platform, SUM(clicks) AS clicks, SUM(cost) AS spend,
             roas(SUM(conversion_value), SUM(cost)) AS roas
             FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28
             GROUP BY platform ORDER BY spend DESC"

The facts table carries the dimensions client conversations actually run on — date, platform, account, campaign, ad group, ad, channel, country — so "which campaign is burning budget" or "how does this month compare" are single queries, not spreadsheet sessions. Every answer also ships with a trust block: how fresh each source is, the caveats that apply, and the lineage of every derived metric. That block is what turns an agent's answer into a number you're willing to put in front of a client.

Pin: the deliverable is a URL

When the monthly view is right, pin it. One command turns queries into a dashboard with a public, read-only, self-refreshing URL:

tablebi pin -w acme --title "Acme Co — marketing performance" \
  --widget "Clicks by day (28d)::line=SELECT date, SUM(clicks) AS clicks FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28 GROUP BY date ORDER BY date" \
  --widget "Spend & ROAS by platform=SELECT platform, SUM(cost) AS spend, roas(SUM(conversion_value), SUM(cost)) AS roas FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28 GROUP BY platform ORDER BY spend DESC"
✓ published → https://acme.tablebi.com/d/dsh_…  (public, read-only, self-refreshing)

That URL is the report. Send it once; it stays current because the dashboard re-pulls from the connected sources on access and on schedule. Here's a real pinned dashboard — live Search Console data, not a mockup — so you can see exactly what a client opens: