Client capstone: discovery to a deployed, presented system
The capstone of the AI Forward Deployed Engineer roadmap: one end-to-end client engagement. Pick a real domain, do the discovery, scope it in a SOW, build and deploy the system, and present the result. You hand in four deliverables: a SOW, an architecture, a demo and a results deck.
The problem
Every month on this path built one piece. A real engagement is all of them at once, for someone who is paying: find the problem worth solving, agree how success is measured, build the system, prove it works and is safe, deploy it, and show the client what changed in their own numbers.
Read the NovaSure case study first. It is the shape your capstone should follow: a client with a measurable problem, discovery that ends in one KPI, a staged plan with gates, and outcomes stated in days and money.
Architecture
The engagement as a line from need to ownership. Scope the brief to one KPI, build the system, prove it with evals and guardrails, deliver it deployed, and hand it over with a runbook and an owner. The architecture of the system itself is yours; most capstones combine the RAG of month 2, the agent of month 3, the platform of month 4 and the controls of month 5.
Pick a real domain
Choose a domain where you can get close to the real work: a business you know, a team at your company, or a friend's practice. Good capstones have documents or tickets in volume, a slow manual step, and a number someone already tracks. Claims, invoices, support queues, contract review, onboarding and compliance checks all work.
The four deliverables
| Deliverable | What it contains |
|---|---|
| SOW | The problem in the client's words, the KPI with its current value and target, what is in and out of scope, the data needed, POC, pilot and production stages with gates, and known risks. Six pages at most |
| Architecture | A diagram of the system and the data flow, the models and where they run, how identity and permissions work, and answers to the security questions a client would ask |
| Demo | The system deployed somewhere a reviewer can use it, and a recorded walkthrough of the main flow on realistic data |
| Results deck | The KPI before and after, the eval scores, cost per task, what failed and what you changed, and what you would do next. Ten slides or fewer |
What done looks like
| Requirement | Done when |
|---|---|
| Discovery | You interviewed at least one person who does the work and mapped the process step by step |
| Scope | One KPI, agreed before building, with what is out of scope written down |
| System | Uses retrieval or an agent, with guardrails and human approval where actions matter |
| Evidence | A golden set, eval scores and traces back every claim in the deck |
| Deployment | Runs on a cloud, deployed by CI, with a runbook someone else could follow |
| Presentation | A two-minute version for an executive and a deeper one for an engineer |
What it draws on
- Topic: discovery and scoping
- Topic: the NovaSure case study
- Topic: handover and runbooks
- Your month 2 to 5 projects: Enterprise RAG assistant, Ops workflow agent, Cloud-deployed agent platform and Secure enterprise copilot
Where to start
Do the discovery before you open an editor. Write the SOW and the definition of done first, then build the thinnest end-to-end slice: scoped, evaluated, deployed and documented. Deepen it from there. A narrow system with numbers behind it beats a broad one you cannot measure.
Every expert started right here.