What you'll learn: the five stages of a customer AI engagement, the written gate that ends each one, who owns each decision when a solution architect and a Forward Deployed Engineer (FDE) share the work, and what a handover pack holds, all shown on the Lumen Order and Policy Assistant.
At a glance
Figure 1. The five stages and their gates
How to read this: each arrow is a written decision, and "stop with a report" is a normal, successful ending.
- Every stage ends with one written gate that a named customer person signs or declines.
- The architect owns the shape of the answer; the FDE owns whether it works in the customer's systems.
- A proof of concept (POC) may miss its criteria, and a clean stop is worth what it cost.
Scenario
Composite scenario, not a real company. Lumen Industrial Supply, a fictional distributor of industrial equipment, wants an internal assistant for its 24 customer-operations agents that answers order and policy questions and cites the policy (illustrative: 9,600 contacts a month, 9-minute median). The sponsor is the Head of Customer Operations. The IT security lead, the platform team, the policy owner in Commercial and Finance all have a say. Nobody has written down who decides what.
What you will be able to do
- Write the gate for each of five stages as one signable sentence.
- Assign each decision to the architect, the FDE, the sponsor or a control owner.
- List what a handover pack contains.
Prerequisites
- What a Forward Deployed Engineer does.
- Rollout, adoption and the solution proposal.
- AI Architect mindset for ADRs (architecture decision records).
Core ideas
Five stages, each with one question and one gate
| Stage | Question | Design-pack output | Gate (a sentence the sponsor can sign) |
|---|---|---|---|
| 1 Discover | What problem, for whom? | Discovery notes, outcome sheet | Head of Customer Operations signs the outcome sheet: median 9 minutes down to 6 or less, zero high-severity wrong policy answers |
| 2 Propose | What will we build, at what cost? | Minimum viable product (MVP) scope, estimate, proposal | Sponsor accepts a read-only MVP at 68 person-days and a three-year total cost of ownership (TCO) of 93,357.50 (illustrative; estimation and TCO) |
| 3 Prove | Does the riskiest part work on their documents? | POC report | Criteria met: go. Missed: stop, or one agreed change |
| 4 Deliver | Does the MVP meet its acceptance criteria? | Working service, tests | AC-1 to AC-6 pass, including the superseded return policy and a credit hold |
| 5 Hand over | Can Lumen run it without us? | Handover pack | Operations and the platform team accept the pack |
A gate that says "the team is happy" cannot be tested. Stages may overlap, but gates close in order.
Who owns what
| Decision or deliverable | Solution architect | FDE | Head of Customer Operations | Security, platform, policy owner |
|---|---|---|---|---|
| Outcome sheet | Drafts | Adds baseline timings | Owns, signs | Consulted |
| Architecture and estimate | Owns | Tests feasibility, gives effort evidence | Decides | Security and platform review |
| POC build and measurements | Reviews | Owns | Provides six agents | Policy owner supplies correct answers; security approves access |
| Which policy text is current | Raises the gap | Indexes current versions only | Informed | Policy owner decides |
| Security and platform approvals | Prepares evidence | Answers technical questions | Sponsors | Owns the decision |
| Acceptance tests | Writes criteria | Implements, runs | Signs | Reviews |
| Handover pack | Reviews | Owns | Receives | Receive runbooks |
On a small team one person wears two hats; the table says which when you decide.
Figure 2. How a gate is closed
How to read this: evidence travels from the FDE to the sponsor, and only the sponsor's reply changes the stage.
At the customer: expect "who do we call when it breaks?" in the first meeting. The answer is the owner named in the handover pack.
What goes in the handover pack
- Context and container diagrams and the ADRs behind them (C4 model levels).
- A runbook: deploy, roll back, rotate keys, what each alert means.
- The test set, its scoring script and the latest results, so Lumen can tell whether the next prompt or model change made answers worse (evaluation).
- The process for loading a new policy version and retiring the old one. This is where the superseded return policy would otherwise return.
- Log design (answers recorded without customer personal data) and a cost report of real usage against the estimate.
Worked example
The Head of Customer Operations has seen a vendor demo and says: "Skip the POC and give all 24 agents the tool." Lengths are illustrative, except that Deliver and Hand over together are the 8 weeks (40 working days) behind the 68 person-days (estimate); MVP scope counts handover and pilot support in them. The POC is not in the 68, so price it separately.
| Stage | Length | Gate |
|---|---|---|
| Discover | 1 week | Outcome sheet signed |
| Propose | 1 week | Proposal with TCO table and exclusions |
| Prove | 3 weeks | Six agents; the written POC criteria met (POC design) |
| Deliver | 7 weeks | Acceptance tests AC-1 to AC-6 pass |
| Hand over | 1 week | Pack signed |
Decision exercise. Choose one: (A) start the build for all 24 agents; (B) insist on a six-week POC; (C) propose a three-week POC with six agents and written pass and stop criteria.
Model answer
Option C. A demo shows the happy path; it does not show whether an agent is told the superseded 14-day return window, how a held order is handled, or what a month costs. A pays for the riskiest part last. B delays the sponsor for no reason they can accept.
Practice task
Add the cycle plan to your design pack. For each of the five stages write the question, the output, the gate as one signable sentence, its owner and a duration. Mark the stage you would shorten if the sponsor lost patience, and the risk that creates.
Decide first, then reveal.
Exercise
Explain it back. In three sentences, explain to the Head of Customer Operations why the project needs five gates. A good answer names a risk per gate, gives one example gate sentence and says what happens when a gate is missed.
Done when a colleague who has not seen your plan can say which stage you are in from the last signed gate.
Hint 1: how to write a testable gate
Start from the failure you want to avoid and write the evidence, with a number, that it did not happen.
Hint 2: where plans go wrong
Check Prove and Hand over for the stop outcome and the named owner.
Common mistakes
- Treating the demo as the POC.
- Gates without owners: a signature from "the team" means nobody signed.
- No exit option, so the sponsor funds "one more week" repeatedly.
- Mixing roles silently: the architect promises a date the FDE has not seen.
Knowledge check
1. Why does each stage end with a written gate instead of a meeting?
A meeting produces opinions; a gate produces a record that one named person accepted a specific claim. It lets you stop cleanly when evidence is missing.
2. Who owns the decision that the POC met its criteria?
The Head of Customer Operations decides, because the criteria were agreed with them. Neither the FDE nor the architect can sign for the customer without turning the gate into self-assessment.
3. A sponsor asks to skip the POC because a demo went well. What is the strongest response?
Offer a short, bounded POC with written pass and stop criteria. A demo shows the best case on chosen inputs, so it says nothing about superseded policies or cost. A short POC answers the worry, which is time.
4. Name three handover items that are not source code, and why each matters.
The runbook, the test set with its scoring script, and the process for loading a new policy version. Lumen's team must operate, test and update the service without the builders.
5. When is a missed POC a success?
When the criteria were agreed in advance and the report shows the idea misses them on Lumen's own data. Lumen avoids paying for a build that would not work.
You can now
- Add the cycle plan to your design pack.
- Write a testable gate for each stage.
- Say who owns each decision.
- Argue for a bounded POC.
Further reading
- The C4 model: the diagram levels for handover packs.
- NIST AI Risk Management Framework: intended for voluntary use. Its Core has four functions: govern, map, measure and manage.
Last verified: 2026-11-03