90-Day Production Sprint
One process live in production, with evals in CI.
Fixed scope, quoted once from the statement of work
A 90-day production sprint exists to get one process running in production and keep it there. I build it with your engineers rather than beside them, so the team can change it after I leave. You get evals in continuous integration, tracing, a cost per outcome your finance team can read and a rollback path.
Published · Updated
Who this is for
This is for you if
- You have one process with real volume and a measurable outcome
- You have at least one engineer who can own it after handover
- You want it in production, not in a demo environment
This is not for you if
- You want five workflows started at once
- Nobody can name the outcome the process is supposed to move
- Legal has not decided which data may leave the building
What you get
- One agentic workflow live in production, with rollback and a named owner
- Evals in CI, so a prompt or model change cannot ship unnoticed
- Tracing and cost per outcome on a dashboard your finance team can read
- A success number written into the statement of work before the sprint starts
How it runs
Pick the process
One process, chosen on volume and on whether the outcome is measurable without a survey.
Build with your engineers
Pairing, not delivery. Your team writes part of it, so they can change it later.
Evals and tracing
A test set that fails the build when quality drops, plus traces and cost per outcome.
Handover
An internal owner, written decisions, and a runbook for the failure modes the workflow hit.
| Stage | What happens | What you get |
|---|---|---|
| Pick the process | One process, picked on real volume | A success number written into the statement of work. |
| Build with your engineers | Built with your team, not for them | A team that can already change what gets built. |
| Evals and tracing | Nothing ships if the test set breaks | Evals in CI, plus tracing and cost per outcome. |
| Handover | One accountable owner and a written runbook | One workflow live in production, with rollback and an owner. |
In my words
What this is
Ninety days, one process, in production. The measure of success is written into the statement of work before the first day.
What you keep
The workflow, the eval suite, the traces, and an engineer on your team who has built it with me and can change it without me.
Where this maps to a standard
Evals in CI apply the MEASURE function (one of the framework’s four functions) inside the NIST AI Risk Management Framework (AI RMF). The scope is one production workflow, not a whole AI programme. A dashboard with cost per outcome is evidence a customer’s security team can check, not a claim they have to trust.
What people ask
What counts as production?
Real users, real transactions, live monitoring, a rollback path and someone reachable if it breaks. A demo behind a feature flag does not count.
Who owns the code?
You do. It lives in your repositories from the first commit, under your licence and your review rules.
What if the evals say the workflow is not good enough?
Then it does not ship, and the sprint ends with a written account of why. That is a cheaper outcome than shipping it and finding out from a customer.
Sources and neighbours
Sources
- AI Risk Management Framework
NIST · retrieved 2026-09-08
Related terms
Related questions
- How do you charge for the work?
- How is cost per outcome measured?
- What counts as 'in production' for the 90-day Sprint?
- What does the two-week Assessment produce, and is the fee credited if we continue?
- What happens if the evals say a workflow isn't good enough?
- What happens on a fit call, and does it cost anything?
- What's the difference between the Assessment, the Sprint and the Retainer?