Case study · AI-native reporting
From a three-week report queue
to a conversation.
How 159 Networks used Claude to document a 2,498-asset ERP database, rebuild an industry-leading reporting platform’s entire dashboard suite in days, and ship a governed reporting engine with one non-negotiable rule: the model never touches the data, and the server never ships data to a model.
database assets auto-documented before a line of report code
calculated fields reverse-engineered from the incumbent platform
dashboards rebuilt as live HTML — in about three days
of 1,005 engine commits co-authored with Claude Code
Claude agents in one metered build workflow — $33.02 at API rates
guard scripts enforcing the security contract on every build
Every figure above is drawn from commit history, build telemetry, or migration ledgers in the project repositories. Nothing is projected or estimated.
The problem
The bottleneck was never the database.
Mid-market companies already own their data. It sits in an ERP, in SQL Server, in the warehouse they operate today. What they don’t own is the loop that turns a question into a report: a new question lands, a ticket opens, a consultant queues it, an extract is rebuilt and republished — and two to three weeks later the answer arrives, frozen, already slightly wrong.
We evaluated an industry-leading reporting platform in exactly this position: capable, widely deployed, and structurally dependent on a publish-an-extract cycle. Its published data sources actually stripped fields that existed in the customer’s own database — users were getting less analytical surface than their own ERP contained, not because the data wasn’t there, but because the publishing step omitted the joins.
The engagement question: could an AI-native engine read the same sources directly — governed, audited, read-only — and replace the authoring loop itself?
Act one · the rebuild
Every dashboard, rebuilt live, in days.
Before writing a single report, Claude agents documented the estate: 2,498 assets across the ERP database — tables, views, triggers, relationships — compiled into a navigable atlas an agent can traverse without ever guessing a column name. The incumbent platform’s report suite was reverse-engineered the same way: 716 calculated fields, 27 dashboards, 127 component views, mapped to their true SQL equivalents.
Then the rebuild: 24 of 24 production dashboards re-implemented as live, self-contained HTML surfaces in roughly three days — running on direct, read-only SQL against the source database. No extracts, no republish cycle, no copy of the data to keep in sync. Parity was checked against the incumbent platform’s own published numbers.
The rebuild surfaced findings the incumbent’s dashboards had never shown: eight figures of revenue accumulating under a placeholder salesperson record, a budget line frozen at the same value for twelve consecutive years, and dozens of deals marked closed-won after their expected close date — a “deals we save” pattern invisible in the extract layer.
Act two · the architecture
The inversion: Claude above the line, never below it.
The product of the engagement is GRT — our reporting engine, a plugin-hosting MCP server — and it is built as two tiers with a hard line between them.
The data plane is LLM-free. Every query is validated to a single read-only statement before it reaches the database; writes and DDL throw before execution. Connections run under least-privilege logins, scope-gated, tenant-isolated, fully audited. 282 guard scripts enforce this contract on every build.
Claude sits above it. The engine publishes MCP tools, prompts, and a progressive schema resource, so the caller’s own Claude — in Claude Code, Claude Desktop, or our web client — discovers real tables and joins before composing a query. It never guesses a column name, and the server never ships row data to a model it doesn’t control. Ask for a report split by branch instead of region, and it’s rewritten from plain English in seconds — inside the same governed rails.
In production topology, GRT registers as a plugin behind Cerberus, our orchestration platform: signed artifact closures, behavioral contract fingerprints, and an upstream identity assertion model, so the orchestrator can verify what a plugin is before trusting what it says.
Act three · the method
Two Claude agents, two codebases, one contract.
GRT and Cerberus are owned by separate Claude Code agents, each with its own repository. The integration between them was negotiated the way senior engineers do it: versioned design memos, committed on both sides.
The correspondence reads like a good engineering org. The Cerberus agent cross-checked the GRT agent’s handoff against GRT’s source and recorded that the contract resource was “live and described faithfully — not aspirational.” The agents disagreed about where shared types should live, and one conceded on the merits, citing the architecture decision record that forbade the coupling. A reciprocal clean-room audit caught a latent cryptographic bug — a signature-verification path that would have fail-closed rejected valid artifacts after a future dependency upgrade — which was fixed and pinned with a regression guard. And where a decision belonged to the business, the agents stopped and flagged it for a human.
The build itself is measured, not vibes: 755 of the engine’s 1,005 commits carry a Claude co-author trailer, and a single metered multi-agent workflow — 33 agents, 950 model calls across Claude’s model family — cost $33.02 at published API rates, with prompt caching serving 40.5 million cached tokens against 2.7 million written.
Where Claude sits
Anthropic across the stack.
- Claude Code as the build method — multi-agent workflows with metered telemetry; agent-to-agent design review across repository boundaries.
- MCP as the product surface — GRT is an MCP server; it ships a Claude Code plugin (20 commands, 2 skills) and a Claude Desktop bundle.
- Claude in the runtime — an Anthropic-first LLM gateway with incremental prompt caching, per-turn cost governance, and redacted telemetry — never prompt or response text.
- Client-model orchestration by default — published MCP prompts steer the caller’s own Claude to chain governed tools — no server-side key required.
Your data already answers these questions.
If your reporting still moves at the speed of a ticket queue, the thirty-minute call is step one. We’ll tell you straight whether we can help.
Book a call