Building AI Systems Incrementally

Imagine a team about to build an AI system that will eventually answer customers, check their records, route requests, log results, and handle many kinds of edge cases. The natural instinct is to design every part at once, so that nothing is missing when the system finally goes live. That instinct feels responsible, but it has a cost: it often delays the moment when anyone can see whether the system works at all.

This article answers a different question. Instead of asking what the complete system should look like, it asks: what is the smallest piece of work that can still be called a real demonstration of the whole system? The answer is what the source calls a minimal end-to-end slice, and it is the first slice a team should build.

The definition contains two ideas that pull in opposite directions, and they must be held together. The slice is minimal, so it is as small as possible. It is also end-to-end, so despite being small it must not be a partial fragment. A component that handles a sliver of processing in isolation is not a slice in this sense, because it does not show the system doing its job from beginning to finish.

The word first matters too. A slice is the first thing built, not a throwaway prototype and not the final product. Once a slice works, the team has a working system with a narrow scope, and every later addition is a widening of that same path rather than a leap into the unknown.

The clearest way to see a slice is to follow one request from start to finish. The diagram below shows a single request traveling along one path. Each box stands in for a layer of the eventual production system. Read it from left to right and notice that the request enters at one end and leaves at the other, passing through every stage in between.

The point of the diagram is not the number of boxes. The point is that none of them is skipped. If a layer is left out entirely, the slice no longer demonstrates the full system, and it becomes a demonstration of something smaller. The stages in the diagram are generated for illustration; the source itself only requires that the slice touch every layer the production system will eventually touch.

The second requirement concerns breadth across the architecture. The slice has to touch every layer that the production system will eventually touch. That sounds like it contradicts the idea of minimality, but the source resolves the tension: this requirement is about breadth of layers, not depth within each layer.

Each layer can be touched thinly, meaning it does only the minimum needed for the request to pass through it. A layer that will eventually perform sophisticated validation might, in the slice, simply accept the input and pass it along. What matters is that the request actually crosses that layer on its way from the customer to the response. The layer exists in the path; its full sophistication can wait.

Read the concept map as a vertical cut. The slice is a single narrow path that runs through every layer of the eventual system. Later work deepens each layer and adds more cases, but it extends a path that already works rather than building a broad set of layers that have never been connected.

The third idea is the one that most often surprises people. A slice does not have to handle every case. It has to handle one case completely. Breadth of cases is deliberately sacrificed, while completeness within a single case is required. The result is a narrow path through the system that works from start to finish, rather than a wide set of partial behaviors that never close a loop.

The comparison shows why the thin complete path is the one that produces a working demonstration. A shallow pass across many cases may touch many parts of the system, but no single request ever closes its loop, so nobody can see the system doing its job. A thin complete path takes one case through the whole system, so the customer's round trip actually finishes.

The two ideas combine usefully. Trading away case coverage keeps the slice small, while requiring full treatment of the chosen case keeps it honest. A team that picks one realistic case and carries it all the way through the system learns more about the system's real behavior than a team that half-handles many cases.

When a team proposes a piece of work, it can be checked against the requirements in a fixed order. The flowchart below turns the source's requirements into a sequence of yes-or-no questions. A proposal that fails any check is not a minimal end-to-end slice, though it may still be useful work.

Walk a proposal through the checks in order. If it does not start at a customer input, stop there. If it does not end at a customer output, stop there. Only after both boundaries pass should a team ask whether every layer is crossed and whether one case is completed without gaps. Each check narrows the question, so a proposal that fails early is easy to diagnose.

Work through the following ideas before moving on. Each one restates a requirement from the source in a form you can apply to a real proposal.