A familiar shape. A board signs off on an AI strategy in March. By September there's a 60-page reference architecture, a vendor shortlist, an integration plan, and exactly zero AI running in production. The team is busier than ever, but nothing has shipped. The CEO starts to wonder whether AI is just expensive theatre.
This happens because the standard path treats AI like a 2015 enterprise software rollout. Assess, strategise, architect, procure, integrate, deploy. Six to nine months before anything works. With classical software, that order makes sense because the technology is predictable. With AI, every box in the sequence depends on assumptions that only get tested at the end, in production, with real users. By the time you find out the assumptions were wrong, you've spent a quarter rebuilding the architecture.
The shorter path inverts it. Ship one thin slice into production first. Then architect.
What "one slice" actually means
A slice is a single workflow that runs end-to-end, with real users, on real data. Not a demo. Not a sandbox. A workflow that produces an output someone is willing to use.
A useful slice has four properties:
- You run it every week. Not every quarter. The team has to feel the value within their normal working rhythm, or the slice never becomes habit.
- The output is measurable. A summary you can grade for accuracy. A draft you can score for usefulness. A recommendation you can compare against the human-made one. If you can't measure it, you can't tell whether the model is helping or hurting.
- The blast radius is small. First slice is rarely customer-facing. Internal means you can fix mistakes by talking to the affected user, not by issuing a public apology.
- The shape is obvious. If a senior engineer in the room says "yeah, an LLM is good at that," you're in safe territory. If everyone has to argue about whether the model can do it, pick a different slice.
The temptation is to pick the most strategic-looking workflow — the one the strategy deck called out as "AI's biggest opportunity". Resist it. The first slice is for learning, not value capture. The biggest-opportunity workflow is usually the one you understand the least.
A four-week shape
Week 1 — pick the slice, get access to the data, build a working prototype against historical inputs. The prototype is allowed to be ugly. It runs in a notebook, calls the model directly, and shows the output on a static page. The point is to learn whether the model can do the task at all.
Week 2 — wire the prototype to a real source of inputs and put it behind a thin UI that one or two people on the team can use. Add the simplest possible logging — every input, every output, every human edit. The logging is what makes the next two weeks productive.
Week 3 — three or four people use it for their actual work. Watch how they edit the output. Sit next to them when they do it the first time. The edits are the signal. If they're rewriting the output from scratch, the slice is wrong. If they're tightening a phrase here and there, the slice is right and you're tuning.
Week 4 — write the eval. Take twenty of the real inputs from week 3, with the expected outputs, and freeze them as a regression test. Wire the eval into a script that runs nightly. Decide the bar you'll hold the system to, and check whether you're at it.
At the end of week four, the slice is in production with a small group of real users, you have a regression test that tells you when the model degrades, and you have a clear picture of where the data actually lives, how clean it is, and what "good enough" actually means for this team.
Borrow the harness
A point easy to miss in the four-week plan: the team probably should not be building the UI.
Five years ago, an internal AI prototype meant standing up a Flask app, designing a chat interface, building authentication, and bolting on observability — a week or two of work before the first useful model call. That work is now free. The mature harnesses are there: Microsoft 365 Copilot, Claude Projects, Cowork, ChatGPT Custom GPTs, Cursor, and a half-dozen others. Each comes with a polished chat UI, file uploads, persistent context, user authentication tied to your tenant, audit logs, and an upgrade cadence the team would never match on its own.
For the first slice, the right move is almost always to drop the work into one of these. Build the prompt, the data connector, the eval — the parts that are specific to your business. Borrow the chat surface, the auth, the deployment, the file handling. The team's focus stays on the skills the model actually needs and the data it has to read; the harness comes for free and improves underneath them every month.
A useful side effect: the team doesn't get attached to its UI. When the slice graduates to a production system in month three, it's easy to move the prompt and the data connector to a different surface — embedded in the workflow tool the users already live in, or behind an API. The throwaway harness was always meant to be throwaway. Teams that build their own UI in week two often spend month three defending the UI they built, instead of moving the value to where the users already are.
What the slice teaches that the strategy phase can't
A strategy document can list the data sources. A slice tells you that one of those sources has a five-week refresh lag, another only exists as a PDF export, and the third is locked behind a vendor portal that needs a service account nobody can authorise.
A strategy document can describe the user. A slice tells you that the user actually trusts the model's draft when it cites a specific paragraph from the source document, and abandons it entirely when it summarises without citing.
A strategy document can name "RAG" as the pattern. A slice tells you whether the retrieval layer needs a database, a search index, or just a smarter prompt.
These are not edge cases. They are the things every AI build runs into in week three, and they are the things the architecture phase has to absorb. Architecting before you have them is architecting against an imaginary system.
After the slice: architect for real
Now do the architecture work. You're doing it with answers, not assumptions:
- The shape of the data layer is informed by where data actually lives, not by where the strategy deck said it should live.
- The model selection conversation is informed by which models passed the eval, not by which vendor sponsors your industry conference.
- The security and governance conversation is anchored in a real workflow with real outputs, not an abstract risk register.
- The "scale this across the business" conversation has a working baseline to scale from, not a hypothetical to scale toward.
The architecture phase is now four weeks instead of three months, because half of the decisions have already been made by the slice. The other half are easier because the team has a shared mental model of what working AI looks like in their context.
The hard part
The hard part isn't building the slice. With current tools, a competent engineer can have a working slice running in two or three days. The hard part is picking the right slice, getting data access cleared in time, and resisting the executive instinct to "scale this up" before the slice is properly understood.
That last one is the killer. The slice works. The team is excited. A VP wants it rolled out to four hundred people next month. Say yes, and the slice becomes a brittle system that breaks under load. The team that built it spends the next two quarters fighting fires instead of building the next slice.
The discipline is to slow the scale-up by exactly the time it takes to absorb what week three taught you about this slice. Usually six to eight weeks. Then scale, with confidence.
Two failure modes worth naming
Picking a slice that's secretly research. "We'll have the model triage incoming legal contracts" sounds operational. In practice the team spends six weeks discovering that contract triage requires reasoning the model cannot yet do reliably. The fix is to be honest at the start about whether you're trialling a known capability or hoping for one. The first slice is for the former.
Slicing into a system that fights back. Sometimes the obvious slice — summarising every ticket in the support system — has to integrate with a workflow tool that wasn't designed to be extended. The slice stalls in integration, not in modelling. The fix is to pick a slice that produces a standalone output (a daily digest, a separate dashboard) for the first month, and integrate later once the value is proven.
Where this leaves the strategy document
The strategy document doesn't go to waste. It becomes the prioritised list of slices you'll ship over the next four quarters. Each one starts thin, runs for four to six weeks, and then enters the architecture phase with everything the slice taught you.
The result is a strategy that visibly moves every six weeks instead of one that visibly moves at the next steering committee. Boards notice the difference.
If you're stuck somewhere between a signed-off AI strategy and an empty production environment, we do this for a living. Tell us what you're trying to deliver →