From workshop to prototype: how a two-week AI sprint runs

An AI sprint is a fixed, short build cycle that takes a single case from idea to a working prototype. Two weeks, one team, a result you can operate at the end. It is not a consulting project with a slide deck, and not an open innovation workshop that produces twenty ideas and no code.

The difference is in the cut. A sprint only works if the case is narrow enough to actually build in two weeks. Not the whole accounting function, but the extraction of one invoice type. Not all of support, but the single most common incoming question. The narrower the cut, the more honest the result.

Most of the time in an AI sprint does not go into building. It goes into the question of which case we build at all, and whether we can reach the data.

Building itself is the fast part today. What makes a sprint slow or worthless are the questions before it: is the case clearly bounded, can we reach the data, is there a person who owns the result at the end. Clear those three before the sprint and half the success is already in hand.

The sprint has five phases. They overlap at the edges, but the order is fixed, because each phase builds on the result of the one before.

Discovery and use-case cut. We sit down and cut the case narrow enough to build in two weeks. That means measuring today's workflow, recording a baseline and setting a success criterion. Without that baseline, you cannot say at the end whether the prototype is any good.

Clearing data access. This often decides whether the sprint flies at all. Which data do we need, may we use it, can we reach it technically, and is it current enough. This phase is unglamorous and still the one most often underestimated.

Building. Now the prototype takes shape on the real case. Not a throwaway mockup with made-up data, but a thing that handles the bounded task on real examples. This phase is shorter than most expect.

Testing with real cases. We deliberately throw the hard, rare and unpleasant cases at the prototype while it is still cheap. What fails here costs almost nothing. What fails only in operation costs real money.

Hand-over. At the end there is not only a working prototype but a decision: does the case support an operation, what would that require, and what is the next sensible increment. This phase is short, but it decides whether the prototype becomes something or disappears into a folder.

A prototype proves feasibility on real data. It shows the case works in principle and whether the further path is worth it. What it is not: a system half the department relies on come Monday morning. Between the two lie permissions, monitoring, error handling and named accountability.

The mistake happens when a successful prototype is confused with a finished product. A prototype may fail in the exception case as long as a human stands beside it. An operation may not. So the honest question at the end of the sprint is not "does it run" but "what is still missing before operation, and is this path worth it".

A sprint is not a task you hand off and collect two weeks later. It lives on what comes from the company. These five things decide whether it holds.

• One narrow, real case, not a topic area. The more concrete the task, the more defensible the result.
• Access to real data, cleared and released, not first requested on day three.
• A business person who knows the case and is reachable for two weeks.
• A success criterion the prototype can be measured against, set before the build.
• The hard cases, the typical exceptions and edge paths, gathered for the test.

Core sentence: an AI sprint is in small part our building and in large part your clarification. What you clear beforehand becomes code in the sprint. What you leave open becomes delay in the sprint.