The problem
Teams ran their recurring analysis in spreadsheets. Every new kind of report meant another manual pass and another one-off file, so the work could not scale past the people doing it.
What I built
They cover recurring reporting, research, and outbound. The AI calls run through a workflow engine, and one tool answers plain-English questions against analytics over MCP, so an analyst can ask instead of assembling a query.
Long-running jobs are treated as production systems rather than scripts: chunked processing queues, automatic retry, circuit breakers, and pause and resume backed by IndexedDB, so a job that dies partway through does not start over.
Data is processed in the browser and stays there, except on an explicit AI call. The aggregation engines are deterministic and check themselves against a known-good reference at startup, so a number that drifts gets caught by the tool and not by whoever receives the report.
All seven share one design system: WCAG AA contrast, managed focus, reduced-motion support, and print and PDF report views.
What changed
Recurring analysis moved off spreadsheets and onto tools that produce the same answer every time, and the reports they generate go to real enterprise customers.
The part I care about is the part that removed me. Adding a new report type stopped being a request routed through the person who built the thing and became a JSON file an analyst writes and imports. That was the design goal from the start.
The pattern
Two decisions did most of the work here, and neither is an AI decision.
Report types are defined in JSON that analysts import and export, so adding one needs no code and no deploy. And each tool is a single HTML file with no build step and no backend dependency for its core features, which makes deploying one trivial and trying one free. That is most of why they got used at all.