A practical plan for a 10-day AI prototype sprint

01

Define the decision before day one

A prototype exists to reduce uncertainty. State the decision it should inform: whether a document can be classified reliably enough for triage, whether retrieval improves answers for a specific knowledge set, or whether reviewers save meaningful time when drafts are prepared automatically.

Write one success statement and one non-goal. For example: “Reviewers can validate extracted fields faster than entering them manually” paired with “The prototype will not update the production system.” The non-goal protects the sprint from becoming an unfinished production launch.

02

Days 1–2: map and baseline

Walk through the existing workflow with the person who performs it. Capture inputs, outputs, decision rules, exceptions, tools, security constraints, and handoffs. Measure a baseline on a representative sample: time spent, common errors, backlog delay, and review effort.

Prepare the evaluation set during this phase. Keep it separate from examples used while tuning prompts or rules. If the same examples guide every change and judge the result, the prototype can appear stronger than it is.

• Named owner for the workflow and the final decision
• Representative sample with sensitive fields handled appropriately
• Written acceptance criteria and explicit non-goals
• Baseline for time, quality, and review effort

03

Days 3–4: build the thinnest complete path

Connect one input to one useful output. Avoid building account systems, elaborate dashboards, broad permissions, and generalized configuration unless the decision truly depends on them. A plain review screen or structured output file may be enough.

Instrument the path early. Record model version, prompt or rule version, latency, errors, and the source item associated with each result. Without traceability, reviewers cannot explain why a result changed or reproduce a failure.

04

Days 5–6: evaluate failure modes

Run the held-out examples and classify the failures. Separate missing context, ambiguous source material, extraction mistakes, unsupported claims, formatting problems, and integration errors. Each category suggests a different response; more prompting is not a universal fix.

Ask the workflow owner to review results in the interface they would actually use. Accuracy alone can hide operational cost. A draft that is mostly correct but difficult to compare with the source may create more review work than it removes.

05

Days 7–8: improve the system, not the demo

Prioritize changes that affect the decision: clearer source references, stricter structured output, deterministic validation, better retrieval filters, and explicit escalation. Resist cosmetic work that makes screenshots look complete while the important uncertainty remains.

Re-run the same evaluation after material changes. Keep the previous result so the team can see whether a change helped one category while harming another. A small comparison table is often more persuasive than a polished presentation.

06

Days 9–10: hand off evidence and a recommendation

Document setup, architecture, assumptions, data handling, known limitations, evaluation results, and operating costs observed during the test. Deliver source code and a demonstration using known examples. The receiving team should be able to inspect the path without depending on a narrated video.

End with a recommendation: stop, run a larger controlled pilot, or prepare a production plan. A production plan should name security, monitoring, ownership, support, and integration work that the prototype intentionally skipped. The sprint succeeds when it makes the next decision clearer.