Every analysis is
built like software.
And it shows.
Your question and your data go through a pipeline of specialist agents, each with one job: design the right statistical method, write it as real code, execute it in a sandboxed container against your data, and put the result through an independent verification gate before anything ships. Every number traces to executed, validated code — not a model improvising in chat. The same standard holds at every depth: a deeper analysis adds more specialists inside each stage, never a different standard.
Eight roles. One standard.
Every pipeline we run — whatever the depth, whatever the engine — realizes the same eight roles in sequence. What changes with depth is how much work happens inside a role: a deeper analysis may fan a stage out across many specialist agents and add refinement passes, but it cannot skip a role, and it faces the same verification gate.
Intake
Your question and dataset are normalized into a strict input contract. Anything malformed is rejected up front, with a reason — not discovered three stages later.
Design
A specialist reads the question and the shape of your data, chooses the right statistical method, and writes the executable specification — the what to compute, card by card.
Build
The spec is implemented as deterministic R or Python — documented, edge-case-handled, statistically safeguarded. This is the exact code every future re-run executes.
Run
The code executes in an isolated container against your real data and produces concrete numbers, tables, and charts. Fixed seeds, pinned dependencies — nothing depends on the day it ran.
Verify
A separate verifier judges the result: does it answer the question honestly? Does the data support the claim? Is it re-runnable? The verdict is pass or fail with a written rationale — and a failure routes to the fixer, not to you.
Package
What verification approved is frozen into an immutable artifact — the spec and the source code, exactly as they passed. That artifact, not a fresh improvisation, is what runs when you re-run on new data.
Deploy
The artifact is registered as a callable tool in your account — re-runnable from the web app, the API, or straight from your AI agent over MCP.
Production test
Before we call it done, the deployed analysis is invoked once for real, through the same runtime you will use. If that first real run doesn’t work, the deploy is rolled back and the build is not delivered — or billed.
What comes back
Every analysis returns one structured envelope with the same layers, whatever its depth. That contract is why the result works equally well for a person reading a report and for an AI agent consuming an answer mid-workflow.
The answer
A minimal JSON payload that directly answers your question — the numbers, the method, the sample size. Built for AI agents: your agent gets the answer inline, in-context, without scraping a report. It’s also served as pure JSON at the report URL, so anything programmatic can consume it.
The evidence
The complete result data the analysis produced — the tables, distributions, and series behind every chart. This is what the interactive report renders, and what makes the answer inspectable rather than take-our-word-for-it.
The report
A live HTML document — from a single-card read to a full sectional study, depending on the depth you chose. Plain-English narrative, methodology per card, exportable to PDF, citable in APA, MLA, Chicago, or BibTeX.
The source
The exact R or Python that produced the numbers, available with the result. A skeptical reader can run it independently and get the same answer — that’s the point.
Two things ride along with every run: a tracking id you can follow live while the build is in flight, and an explicit status — a result is ok or it is error, never a silent guess. Depths differ in report shape — a quick answer returns a lean single card, a commissioned study returns a full sectioned report — but the envelope, and the standard behind it, is the same.
Self-healing builds
When the verifier finds a problem, a repair specialist diagnoses, patches, and retries — and anything that doesn’t clear verification never ships. You only ever see analyses that passed the gate.
Verifier flags the issue
The verifier inspects the output — including reading the rendered charts — and writes a report with the exact failure and a recommended fix.
Fixer patches the code
A repair-specialist agent reads the verification report and applies a minimal, targeted change. No refactoring, no scope creep.
Re-run and re-verify
The patched analysis runs end-to-end again and faces the same gate. Passing means moving on to packaging — there is no side door.
Honest exhaustion
Retries are bounded. A build that can’t clear verification is surfaced as a failure, not delivered with caveats — and failed builds are never billed.
Why this matters
Most analytics options ask you to either trust generated code that changes every run, or wait days for a human to write the analysis. This pipeline does neither.
| Capability | Manual analyst | LLM code generation | MCP Analytics pipeline |
|---|---|---|---|
| Time from question to answer | 2–5 days | Minutes (per chat session) | Minutes to about an hour, by depth |
| Same answer on re-run | ✓ If documented | ✗ Different code each run | ✓ Deterministic, frozen code |
| Source code with the result | ✗ Separate file | ✗ Lost in the chat session | ✓ Attached to every analysis |
| Verification before delivery | Whatever the analyst remembers | ✗ No verification step | ✓ An independent gate on every build |
| Machine-readable answer for agents | ✗ | ✗ Prose in a chat | ✓ json_output on every result |
| Self-heals when something breaks | ✗ Manual debugging | ✗ Re-prompt and hope | ✓ Fixer cycles, bounded and honest |
| Re-runs on fresh data | ✗ Re-hire the analyst | ✗ Start over | ✓ Your deployed analysis, one call |
Put the pipeline to work
Bring a CSV and one question. Pick your depth, watch the build live, and get back an answer you can cite, share, and re-run — charged only if the build succeeds.
Create your analysis →