Case Study Skeleton: Reporting Agent for a Boutique E-Commerce Brand
Status: SKELETON. Sections marked [PILOT DATA] are populated only with measured results from an actual engagement — never estimated.
Dry-run evidence (simulated). Our deterministic pilot simulator already exercises this exact agent stack end-to-end: over a 4-week simulated dry run it generated 4 weekly reports, flagged 2 anomalies same-day (a revenue dip of −23% week-over-week and a cost spike), surfaced 1 missing metric explicitly instead of silently omitting it, and required zero human prep hours. All figures are from a simulated dry-run against synthetic data (see the live demo scenario). No real customers were involved.
The client
Boutique direct-to-consumer e-commerce brand (fictional persona used for this skeleton), one owner-operator handling marketing, fulfillment oversight, and books. Weekly numbers live in three places — a spreadsheet export, a payment-processor dashboard, and ad-platform reports. [CLIENT NAME PENDING CONTRACT]
The problem
- The weekly owner report gets assembled by hand on Sundays and often doesn't happen at all during busy weeks
- Week-over-week swings are noticed days later — a bad revenue week or cost spike is discovered after the window to act has closed
- Silent data gaps: when a source fails to export, the number is simply absent from the spreadsheet and nobody notices
What we deployed
A Reporting Agent running our standard loop, wired through:
- a metrics data-source adapter — swappable without core agent changes (warehouse/Stripe/GA adapter in prod)
- a deterministic report compiler, not freeform LLM prose: per-metric current vs prior values, WoW delta %, computed in code
- anomaly thresholds in code, not in the prompt: any metric moving ±20% or more week-over-week is flagged with an explicit anomaly marker the owner sees same-day
- missing-metric surfacing: every expected-but-absent metric is listed in the report as a data gap instead of being silently omitted
- an auditable report artifact per period, written to the project's reports directory with a timestamp
Results framework (fill during/after pilot)
| Metric | Before | After | Source |
|---|---|---|---|
| Owner prep hours per weekly report | [PILOT DATA] | [PILOT DATA] | client timesheets |
| Anomalies flagged same-day | — | [PILOT DATA] | report artifacts |
| Data gaps surfaced (not silent) | — | [PILOT DATA] | missing_metrics list per report |
| Reports delivered on schedule | [PILOT DATA] | [PILOT DATA] | report timestamps |
| Cost per compiled report | [PILOT DATA] | [PILOT DATA] | token ledger |
Pricing fit
Reporting runs on our platform-fee-plus-usage model: $500/mo platform fee + $50 per compiled weekly report. Because compilation is deterministic code with a small token footprint, the worked internal example clears our enforced 30%-margin floor easily — at ~93% contribution margin per report in the simulated dry-run estimate (see pricing).
Why the deterministic compiler matters
In reporting, a confident wrong number is worse than no number. Metric aggregation, deltas, and anomaly flags live in deterministic code the language model cannot override — the LLM never invents a figure; it drafts around figures the compiler produced. Every report is attributable to its input records, its threshold rules, and a loop cycle. And a missing feed produces a visible "data gap" row, not a quietly wrong trend line.
Lessons learned section
[POST-PILOT: list top 3 lessons from data/loops/<project>/ — real ones, verbatim.]