Use case · AI Studio
Data analysis & reporting
When gut feeling gets a number: analyses with built-in quality checks, across system boundaries, quantified rather than described.
01 · The brief
Not a data problem, an analysis problem.
Most companies do not have a data problem but an analysis problem. The numbers exist: in the data pipeline, in the data warehouse, at the payment provider, in the ad account, in the ticket system, in the ERP. What is missing is the person who pulls them together as soon as someone asks a question.
And because that person is always busy, the question goes unasked. Decisions are made from experience. Usually that works. Sometimes the experience is a year old. Precisely what lies between the data pools stays invisible.
The brief: an agent team that reads across system boundaries, checks numbers before analysing them, establishes connections and flags anomalies before they end up in a report. In our own operations this team has been working on our own figures since early 2025.
02 · What the team does
What the team does.
Pulls together what sits apart
Analytics database, payment provider, ad accounts, usage data, ticket system. For the agent this is one question, not five systems. The value rarely arises in one pool alone; it arises where two pools contradict each other.
Checks the numbers before analysing them
Are records duplicated? Is the comparison base the same? Is the sample large enough for the statement it is meant to support? A large part of the work is discarding analyses that are better not written.
Reports on its own, but only once the number holds
Runs start on a schedule and unattended. The difference to a dashboard: the agent stays silent while the sample is too small and reports exactly once as soon as it no longer is. One run checked every morning for three weeks and stayed silent. When the cohort was large enough, a single message came and the run switched itself off.
Quantifies instead of describes
Not “conversion has dropped”, but: by how much, for which group, since when, and whether the difference is even large enough to act on.
Writes down what it learned
Every quirk of the data, every special case, every trap in a table is recorded as a rule and applies to every further analysis. That is the part that does not work when an external consultancy leaves after the project.
Explains rather than just shows
Not only the number but the reasoning, with a reference to the underlying data and the query. Every metric stays traceable back to its source.
03 · How it works
How the agents work.
The agents read where the data already sits, no additional data silo is created.
Step 01
Connect
Read access to the relevant systems: analytics database, ERP, CRM, payment providers, ad accounts, file storage.
Step 02
Check
Completeness, duplicates, comparison base and sample size are checked before anything is analysed.
Step 03
Analyse
Metrics and relationships emerge across system boundaries rather than per department.
Step 04
Present
Finding with recommendation, query and an explicit note on what the data cannot support.
Set this process up in your company? Request a conversation →
04 · From practice
Three cases from our own data analysis.
A join error in the data pipeline, and every report was silently wrong.
Two brands on the same platform, separate evaluation of revenue and costs per brand. In the aggregation table, however, costs were attributed not to the customer’s brand but to the brand of the counterparty. Nothing about it looked broken: the totals were correct, only every split by brand was skewed, in dashboards, in reports, in every analysis. The agent found it while recalculating an entirely different question, traced it into the data warehouse’s load procedure and showed that the cause was a deliberate change made with good intentions. It is the class of error that only shows up when someone computes the same number two ways and explains the difference.
One cardholder, dozens of chargebacks, and the in-house rules stayed silent.
The payment provider reported a fraud rate that could have meant losing the payment route. The agent matched the report against the internal database and found that every fraud report and chargeback came from a single card. Without that one customer the rate was in the normal range. It laid out the daily timeline and answered the question that matters: could it have been seen earlier? Yes, a simple velocity rule would have stopped it on day one. It also found that the chargebacks never reached the reporting at all. The damage was quantified in stages, from realised to worst case, rather than asserting a single number.
Paid purchases that never arrived in the analytics.
Over five months there were transactions where the payment provider had collected and paid out, but no matching transaction existed in the internal reporting. Both systems looked plausible on their own. Only the row-by-row reconciliation revealed the gap. No money was lost, but the reporting was silently incomplete, and so was every metric derived from it. The agent named the most likely cause, explicitly rated it as not urgent and formulated two open questions for the business units instead of answering them itself. Once built, such a reconciliation runs with every pass.
05 · The outcome
What changes.
Complaints can be traced back to a production line or a supplier, because ERP, quality management, CRM and mailbox are looked at together. Questions nobody could ask before get a number.
The quality check is part of the analysis rather than a downstream step, faulty figures never reach the report in the first place. In our own operations every analysis since early 2025 is documented with question, query and finding.
- Answers to questions nobody could ask before.
- Anomalies are reported, not discovered while reading.
- Every metric stays traceable back to its source.
- Learned rules stay in the company, even after the project.
06 · Who decides what
Who decides what.
ask the question → check the data → analyse → cross-check → quantify → present finding with recommendation → assess → decide → implement → measure the effect
Assessing and deciding stays with people. The agent delivers the decision paper, not the decision, and explicitly marks what its data cannot support instead of glossing over the gap.
That this split holds is set through the granted permissions: database access is read-only. An analysis agent that can change data is not an analysis agent. Every action is logged with a timestamp, every analysis is stored with its query. That is the audit trail along which any result can be verified or refuted at any time.
07 · Systems and access levels
Systems and access levels.
Our own set-up as an example. In your company, your corresponding system takes each place.
| System | Used for | Access level |
|---|---|---|
| Data warehouse / analytics DB | Metrics, revenue, costs, cohorts | read only |
| Payment providers | Reconciliation of revenue, payouts, chargebacks | read only |
| Ad accounts | Costs and conversion per channel and campaign | read only |
| ERP, CRM, quality management | Orders, customers, complaints | read only |
| Ticket system | Findings as tickets, assigned and linked | read · write tickets and comments |
| Chat / messenger | Reports and alerts | read · send only in approved channels, otherwise draft for approval |
08 · Limits
What you need for this, and what you don’t.
Not needed: a new data warehouse, a change of tools, a data-model project. The agent works read-only on your existing data, whether the pipeline was built with a tool or by hand. Your reporting front end stays where it is. The agent does not replace it; it answers the questions it was not built for.
Needed: read access to the relevant data sources, someone on your side who knows the business logic and can cross-read, and the willingness to examine the first findings seriously instead of waving them through. The effort on your side is small, but it is not zero.
On confidentiality: an analysis needs metrics, cohorts and aggregates, not personal data. A pilot can be set up on fully anonymised data. Where a case does lead to individual records, an internal identifier without personal reference is enough.
Frequently asked
Frequently asked questions about this use case.
Do we need a data warehouse for this?
No. The agent works read-only on what exists: database, exports, payment providers, ad accounts, spreadsheets. A new data-model project is not a prerequisite.
How do you prevent the agent from delivering wrong numbers?
Through checks before the analysis (duplicates, comparison base, sample size), through a separate instance cross-checking every result, and through the audit trail: every analysis is stored with its query and can be recalculated.
Is personal data required?
Usually not. Metrics, cohorts and aggregates are enough. A pilot can run on anonymised data; individual cases use internal identifiers without personal reference.
More use cases
Related use cases.
Customer service
Tickets enriched with context automatically, staff get well-founded draft replies straight away.
Product & engineering
The engineering team that reads along: monitoring, root-cause analysis down to the line of code and hand-over-ready tickets in your ticket system.
Operations & DevOps
The operation that knows where it will break before the peak: monitoring, database check and narrowing down in minutes instead of hours.
Does this sound familiar?
In a first conversation we look at your processes together and sketch out where an agent team would make the biggest difference. Free of charge and without obligation.