Reporting Summariser: An AI Agent That Writes Verified Readouts

An AI reporting agent for marketing is safe when it writes the words and leaves the numbers to queries. The Reporting Summariser works at L1, the read level, for analytics and marketing-operations leads, using aggregates from any customer data platform (CDP). It turns approved metric results into a plain-language summary. It never calculates a figure, states a cause as fact, reads individual records or delivers a report itself.

Rail level: L1 · Risk: low · Function: marketing operations

By Art Kukharenko · Published 2026-11-02 · Updated 2026-11-02

All AI agent rails

The AI agent rails method covers this job, and it does not describe a shipped product.

Rail at a glance

Each limit on the Reporting Summariser has its own enforcer. The query layer decides which numbers exist, a number check decides which ones may appear, and a separate delivery service holds the only route to readers.

Field	Value
Job	Write a plain-language summary from approved metric queries.
Trigger	A schedule, or a request from the report owner.
Data scope	Aggregates above a minimum group size, metric definitions and the campaign calendar. No row-level data.
Tool scope	Read: fixed metric queries, metric catalogue, calendar. Propose: none, because the summary is read-only output for review. Execute: none, because a separate service delivers the report.
Output contract	Summary, locked figures table, query references, hypotheses, and what the report does not show.
Gate	The owner reviews each report at first, then samples.
Limits	Budget per run, a minimum group size, and no export.
Ledger	Query IDs, result hash, model version, report version, reviewer.
Evaluation	Spot checks of figures and claims, plus an automated number check on every run.
Owner and kill switch	Analytics or marketing-operations lead. Stopping the schedule leaves the last reviewed report available.

What it does and who uses it

The Reporting Summariser does the part of reporting people put off: saying in sentences what changed. Analysts maintain the metric catalogue, the report owner reads the draft, and the model sees only results that fixed queries have already returned.

Picture an illustrative Monday run for a retail email programme. The scheduler calls nine fixed queries, and the query layer stores a result hash and builds a locked table. The model writes: "Click rate fell from 2.4% to 2.0% week on week. Two markets had a public holiday on Monday, which is one possible reason." It adds that opens are left out, because Apple Mail Privacy Protection makes them unreliable.

A number check confirms that each numeral appears in the locked table. Had the model written "down 17%", the check would have failed, because no query recorded that value. The owner reads the draft, adds a note on the holiday, and marks it reviewed. Only then does the delivery service send it.

The table shows which layer produces each part of that report.

Report part	Produced by	Checked by
Figures and changes	Fixed queries	Result hash in the ledger
Sentences	Model	Number check and causal-wording rule
Hypotheses	Model, labelled as such	Evidence link to a query or calendar entry
Delivery	Separate service	Review status set by a person

dbt Labs describes a similar split for natural-language analytics. There the model produces a structured metric request and MetricFlow compiles the SQL, because a model asked for SQL can invent tables and columns 1. This rail goes one step further, since the queries are fixed and the model does not choose them.

Why this level

The Reporting Summariser stays at L1 because its worst case is a wrong sentence that a reader can catch before acting on it. That only holds while the model has no route to readers, so delivery lives elsewhere.

Measured against Meta's Agents Rule of Two, this session holds two properties and must not gain the third 3. Calendar entries and campaign names can carry untrusted text. The metrics are sensitive business data, even though aggregates above a minimum group size are not individual records. The session cannot change state or communicate outside, so a manipulated draft cannot email itself to anyone.

The minimum group size is a privacy control, and no universal number exists. As one research example, the UK Longitudinal Linkage Collaboration blocks outputs below 10 data subjects and warns that masked values must not be derivable from the rest of the table 2. A marketing team has to set its own and test for subtraction between a total and its parts.

The level never rises, because a summary needs no write tool. Only the review rate can change.

Three ways it fails, and the control for each

The Reporting Summariser mostly fails by being persuasive, because tidy prose makes a weak figure or a guess sound settled.

Failure	What it looks like	Control
Figure drift	The prose says 2.1% where the table says 2.0%, or the model works out a percentage of its own.	The check compares each numeral with the locked table and blocks delivery on a mismatch. Rates and changes come from queries.
Cause stated as fact	"Clicks fell because of the new subject line" reads as a finding, and the next decision rests on it.	A wording rule moves causal phrases into the hypotheses section, where each needs an evidence link.
Comparison across a changed definition	A metric was redefined last week, so each figure is right and the trend is false.	The catalogue version is logged with each query. A version change between periods removes the comparison and adds a notice.

How to evaluate it

A good Reporting Summariser report is one an analyst would sign: right numbers, honest hypotheses and nothing important left out. Number errors should be rare by construction, so the useful tests look elsewhere.

Numeric errors on spot checks. Trace each figure in a sampled report back to its query result by hash. Any error points to a broken check, not just a careless model.
Tampered drafts. Feed the number check drafts with altered digits and invented percentages. All of them must fail, or the check is decoration.
Evidence coverage. Count the claims linked to a query or calendar entry, and treat the rest as defects.
Omissions. A rule lists every metric that moved past an agreed band, and the summary must mention each one. A number check cannot catch silence.

Where it runs

The Reporting Summariser's use of aggregates means an external model is acceptable where the contract allows. A private model suits regulated teams, and unpublished results can be sensitive in any sector, as the boundary architecture patterns explain. PrivyCDP provides AI-assisted review of reports with review of results, but the rail described here is a method you adopt, not something it ships.

AI marketing reporting on rails: the weekly cycle from query to reader.
AI agents for marketing operations: where recurring reports sit among the function's other jobs.
Rail card template: a card to fill in with your own report's queries and owner.

See the other profiles at AI agent rails, and use the rail card template to specify your own reporting rail.

Browse use cases Function playbooks Agent roster

FAQ

Can AI write marketing reports accurately?

It can write them, provided it does not produce the figures. Queries supply each number, and a person reviews the draft. Explanation is harder, so causes stay labelled as hypotheses.

Why not let the model query the warehouse directly?

A model that writes its own queries can choose the wrong table, join or definition, and the result still looks like an answer. Fixed queries remove that choice and make each number reproducible from the ledger.

Should the summary report on individual staff?

No. Report by rail, campaign and role. The EU AI Act names task allocation by individual behaviour and the monitoring of workers among its high-risk uses (Annex III, point 4(b)), so take advice before adding names 4.

Sources

This article is general information, not legal advice.