What was the problem?
A UK business had a well-audited reporting warehouse and a familiar bottleneck: every business question still needed someone who writes SQL. The obvious fix — point an LLM at the database — fails in predictable ways: agent queries hammering production, plausible-but-wrong SQL nobody checks, answers that cannot be reproduced a week later, and an agent that makes the same mistake every session because it remembers nothing.
Revenant Systems built an agent-driven reporting system that keeps the convenience and removes those failure modes. The team asks questions in Slack; an agent answers with queries, charts, and cited reports, and every figure traces back to the SQL that produced it.
How does the system work?
The system is three purpose-built parts around an agent. The agent sits in the company’s Slack, built on the open-source OpenClaw framework [1], and carries a data-analysis skill: the business definitions, analysis conventions, and house chart styling it needs, plus a pointer to the reporting warehouse’s data dictionary. A sync service gives it a local, read-only copy of the reporting data to work against. A query-log service records everything it does, hands it a memory of every past analysis, and answers its questions about how the data is laid out.
| Component | Role |
|---|---|
| Agent in Slack | The interface — plain-English questions in, analysis out |
| Data-analysis skill | Business definitions, derived-metric formulas, chart theming, workflow rules |
| Sync service | A local, read-only, high-performance mirror of the existing reporting database |
| Query-log service | Logs and audits every query, and serves similar past work back to the agent |
How is production kept safe from an agent?
The agent never queries production. A sync service maintains a separate, read-only copy of the reporting data — refreshed in full or incrementally, with crash recovery, drift detection, and a logged row count for every run — and the agent works only against that copy. So an agent free to explore, join, and get things wrong can do so at full speed, and the production database never feels it.
The write path is closed twice over: the copy is read-only, and every statement the agent writes is parsed and checked before it runs, with anything destructive refused outright rather than trusting the agent’s intentions.
What makes an agent’s analysis auditable and repeatable?
Every piece of work happens inside a named analysis with a human-readable ID, and every query the agent runs is logged to it — SQL, commentary, outcome, and the result set itself, stored under a name so the exact numbers can be retrieved later rather than re-derived differently. Finished work becomes a report with inline citations, and each citation resolves back to the query and data slice behind it. Every action along the way is audit-logged.
That turns “the agent said revenue dipped in March” from an assertion into a traceable claim: the report, the citation, the query, the rows.
How does it self-correct over time?
Every logged query is indexed for similarity search, so when a new analysis starts the agent is handed the most similar past queries and notes before it writes a line of SQL. Failures are first-class: a query that errored or gave a wrong answer is recorded as such and linked to the query that fixed it, so mistakes and their corrections travel together into future retrievals.
Notes can be attached at four levels — analysis, query, global concept, datasource — and voted up or down, so human judgement steers what the agent is shown next time. The system’s accuracy is not a frozen property of a prompt; it accumulates.
Where is the LLM deliberately kept out?
Scheduled reporting stays deterministic. The platform’s daily and weekly bulletins — departmental and executive summaries published on a fixed schedule through the same agent runtime — are generated from validated configuration by ordinary code, with no model anywhere in the arithmetic. The agent is for questions that need judgement and exploration; recurring numbers the business relies on are computed the same way every time. Knowing where not to use an LLM is part of the design.
Limitations
The system was assembled across spring 2026 and is in production use, but this account offers no usage statistics or accuracy percentage — answer quality is enforced by the retrieval loop, the audit trail, and human review, not measured against a labelled benchmark. Freshness is bounded by how often the mirror syncs, and the query-log service handles one request at a time: a deliberate simplicity that suits an internal team, and one of the first things that would change at larger scale.
Sources
- OpenClaw — the open-source agent framework the Slack agent runs on: openclaw.ai