Every analysis is
autonomously built.
And it shows.
Every analysis in our library is built by a pipeline of specialized agents — they research the method, write it as validated R, run it on the data, and independently verify the result before it ships. The numbers come from deterministic R, not a model improvising code: the same analysis runs the same way for every customer, every time. The same standard holds at every depth — but the pipeline scales with it, from a Snapshot in minutes to a full Atlas that builds your analysis rigorously, cross-verifies the results, and deploys a durable module you own.
Five stages. One daemon.
This is the rigorous R build behind an Atlas. Each module goes through five specialized stages, each handled by an agent with a single job, orchestrated by a daemon that runs continuously and builds in parallel. A fast Snapshot runs a shorter version of this same flow, back in minutes. See how Snapshot & Atlas compare below ↓
Research the question
Reads the question, looks at the dataset shape, picks the right statistical method, and designs the report card by card. The output is a structured spec.
Write the R code
Implements the spec as deterministic R code with literate documentation, edge-case handling, and statistical safeguards. Same code runs every future report.
Run the analysis
Executes the R script in a sandboxed Docker container against the test data. Produces metrics, datasets, charts, and the structured report payload.
10 quality checks
Inspects every output: file completeness, metric validity, chart rendering, statistical soundness, code style. Reads each chart screenshot visually.
Push to production
Builds a Docker image, registers the module in the API, runs a smoke test, activates it. The library grows. Available to every customer instantly.
The same standard. The depth you choose.
The five-stage flow above is the heart of it — but the pipeline scales with the depth you pick. A Snapshot answers in minutes with a fast automated read; an Atlas writes and independently verifies reproducible R and deploys a durable module you own. Same verification standard either way.
Depth is the dividing line. A Snapshot is built for speed — a fast descriptive read: a chart, an overview, back in minutes. An Atlas unlocks the full statistical method catalog — real hypothesis tests, regression and survival models, diagnostics — and runs more kinds of analysis, so its pipeline is longer: more to build, and more to verify. You can see that below — the deeper build grows with what it can do.
Snapshot
One focused question, answered fast. An instant automated read with a plain-English narrative — no waiting.
- Read your question
- Pick the query & chart
- Verify the narrative fits the data
- Live for every customer
Atlas
The full build. Reproducible R, executed in a sandbox, put through ten quality checks, cross-verified, and self-healed before it ever ships — deployed as a module you own and re-run.
- Research the method
- Write reproducible R
- Run it in a sandbox
- 10 quality checks
- Self-heal on any failure
- Deploy the module you own
Pick the depth your question deserves — the answer comes back independently verified either way. Compare Snapshot & Atlas →
The numbers behind the pipeline
These are real, live numbers — pulled from our pipeline database. Every module, every build, every quality check is logged.
All numbers from devgen.agent_execution and devgen.module_pipeline, last 7 days. Verifiable on request.
Where the time goes
Average wall time for each stage across recent builds. The longest stage is the builder writing R code; the shortest is rendering the analysis itself.
Add ~3 minutes when the fixer needs to recover. Add another ~3 if it needs a second cycle. Maximum recorded build with two fixer cycles: 36 minutes.
Self-healing builds
When the verifier finds a problem, the fixer diagnoses, patches, and retries automatically — and anything that doesn't clear verification never ships. You only ever see analyses that passed the checks.
Verifier flags the issue
The verifier reads every chart screenshot and runs 10 structural checks. It writes a detailed report with the exact failure and a recommended fix.
Fixer patches the code
A repair-specialist agent reads the verification report, identifies the file to edit, and applies a minimal, targeted change. No refactoring, no scope creep.
Re-render and re-verify
The patched module re-runs end-to-end. If the verifier passes, the build moves to deployment. If it fails again, the fixer cycles up to 3 times.
Backoff on persistent failures
If a module fails 3 times, the daemon abandons it with exponential backoff (5, 10, 20 min) and surfaces the failure — but keeps processing other modules.
Why this matters
Most analytics platforms ask you to either trust generated code that changes every run, or wait days for a human data scientist to write the analysis. This pipeline does neither.
| Capability | Manual analyst | LLM code generation | MCP Analytics pipeline |
|---|---|---|---|
| Time from question to deployed analysis | 2-5 days | Minutes (per chat session) | ~16 minutes |
| Same answer on re-run | ✓ If documented | ✗ Different code each run | ✓ Deterministic R code |
| Source code in the report | ✗ Separate file | ✗ Lost in chat session | ✓ Code appendix in every report |
| Quality checks before deploy | Whatever the analyst remembers | ✗ No verification step | ✓ 10 automated checks per build |
| Self-heals when something breaks | ✗ Manual debugging | ✗ Re-prompt the LLM | ✓ Fixer cycles automatically |
| Builds new modules continuously | ✗ Bottleneck | ✗ One-off only | ✓ Daemon picks up new submissions |
Run analyses from the library
Every module in our library was built by this pipeline. Upload a CSV and the system picks the right one for your data — analysis runs in seconds, the report has the source code attached.
Run a free analysis →