Capstone: Run an Engagement End to End

After this lesson, you will be able to connect the artifacts from this course into a coherent customer engagement, explain why each decision was made, and identify what remains unknown at handoff. NorthPort Freight is fictional. The details here are a worked exercise, not a real customer engagement or a claim of measured results.

NorthPort asks for help with dispatch exceptions. Dispatchers currently consult approved procedures while moving between the ordering and dispatch systems. The company is interested in an assistant that can find relevant procedure content and show a useful answer with its source. The request sounds like a feature brief, but it leaves important questions open: which exceptions take the most effort, which procedure set is authoritative, what information can be shared with a model, who approves an answer, and what would make the result safe to use?

An FDE engagement makes those questions answerable in stages. It does not assume that a model is the right solution, that the customer can provide every dependency on time, or that a prototype should become production software. Each stage should reduce a specific uncertainty, produce evidence or a decision, and leave an artifact the next owner can use. This capstone follows the same fictional problem through that work.

OpenAI’s public description of its FDE approach includes understanding workflows, agreeing measurable outcomes, building and evaluating with customer context, going live with clear operating responsibilities, and making successful patterns more repeatable. GOV.UK’s discovery and agile guidance similarly emphasizes understanding users and constraints, then using iterative feedback to guide what is built. Those are examples from particular organizations and contexts. Use the customer’s own process, authority, and controls when applying the sequence below.

1. Start with discovery, not a promise

The first meeting is for learning and setting boundaries. Bring the executive sponsor, a dispatcher or supervisor, the owner of dispatch procedures, and the platform or security contacts who can explain access and deployment constraints. Ask a dispatcher to walk through the current task using an approved example. Find out what starts the work, which systems are consulted, what information is trusted, how exceptions are resolved, and how the final decision is recorded.

Separate the problem from the proposed assistant. Write down the goal in the customer’s language, the people affected, current workflow, pain points, existing workarounds, and success measures they might care about. Record who owns each decision and which facts still need confirmation. Use the discovery questions and requirements log in Requirements Gathering with a Customer. If the customer cannot identify an authoritative procedure source or provide an approved test environment, record that as a dependency instead of quietly filling in the gap.

For this exercise, NorthPort’s stated need is to help dispatchers find the approved procedure for an exception and understand where the guidance came from. That is a working problem statement, not proof that an AI assistant is the right intervention. The next discovery step is to learn which cases are suitable, which require supervisor judgment, and what the current handling process already supports.

2. Audit the data and choose a first slice

Before building retrieval or a model integration, inspect the procedure data and any proposed exception records. Confirm who owns them, how recent they are, what formats are available, whether access is permitted, and which fields may identify people or reveal confidential business information. Profile a minimized approved export for missing fields, duplicate identifiers, inconsistent types, and timestamps. Keep customer data inside its approved environment. The Data Audit First lesson includes a small profiler for synthetic CSV and JSON examples; it is not a reason to upload real customer data to an unapproved tool.

Create a scoped data audit report with the source, version, date, method, checks performed, limitations, and owner for each issue. If the sample is synthetic, label it. If the export does not represent the production feed, do not report its quality as the production quality. If access approval is pending, keep the system design at the level the available evidence supports.

Next, define a first slice with the customer. The Discovery, Scoping and Sequencing lesson provides a template. For this exercise, a possible slice is: in a sandbox, a dispatcher enters a supported exception code, sees matching approved procedure passages with identifiers and update timestamps, and drafts a response that the dispatcher must review. Explicit non-goals could include changing a shipment, replacing supervisor approval, writing to the legacy system, or answering from sources outside the approved procedure set.

The scope sheet should name acceptance criteria, dependencies, access roles, the test environment, the user who will review it, and the conditions that stop work. Time-to-value begins with an agreed event and ends only when the customer has a usable result under an agreed definition. A clickable demo with synthetic content can provide design learning, but it should not be reported as a production outcome.

3. Record the approach and build a safe prototype

Make an approach record that compares options in customer terms. Could a search interface and filters solve the need without generative AI? Would retrieval over approved procedures help when questions use different language? Is a multi-step agent necessary, or would it add complexity without improving the task? The lesson on Choosing an AI Approach for a Customer covers that decision. For this capstone, assume the team chooses retrieval with a generated draft only if a test shows it improves the dispatcher’s task over search alone. This is a hypothesis to test, not an outcome claim.

Build the prototype against synthetic procedures or a customer-approved sandbox. Label mocked systems and data in the demo. Use the customer’s approved model and development tools, keep secrets out of source, and avoid connecting prototype code to production actions. The Build a Working Prototype Fast lesson covers demo discipline. For hands-on work, the Vibe Coding lesson on version control with AI and Claude Code’s guide to sandboxing and secrets help protect the development workflow.

The prototype should make its limits visible: it can search only the supplied procedure set, it can show that source identifiers were retrieved, and a dispatcher remains responsible for using the guidance. A model response that sounds confident is not evidence that its source supports every instruction. Do not use live dispatch records in a screen recording or demo deck unless the customer has approved the data handling.

4. Integrate, evaluate, and decide whether it is ready

Before connecting the prototype to a customer system, define the integration boundary. Document the API or export, identity, permissions, network path, expected errors, rate limits, owners, and failure behavior. Start read-only where possible. Use a sandbox and test credentials. The lessons on Integration Engineering and Working with Legacy Systems cover boundary ownership, safe reads, adapters, retries, and idempotency.

Turn the customer’s requirements into criteria that a reviewer can evaluate. For instance, an approved in-scope case should show at least one expected source identifier; an out-of-scope question should not produce a dispatch instruction; an empty retrieval should lead to the agreed fallback. The Evals as Acceptance Criteria lesson includes the acceptance runner and synthetic test fixtures. The runner checks narrow properties and release-gate logic. It cannot establish that a source semantically supports an answer, so a domain reviewer must inspect representative cases.

Include ordinary examples and difficult cases: ambiguous exception codes, missing procedures, conflicting revisions, stale content, and requests for actions outside the assistant’s scope. Keep datasets and criteria versioned. Record failures and unknowns, and have the customer approve what counts as a blocking issue before using the result as a gate. The product cannot pass a requirement by silently changing the test after seeing a failure.

Prepare the deployment plan with environment, artifact version, identity and secrets, monitoring, rollback or recovery path, change approval, support coverage, and named owners. Ask the customer’s security and privacy teams to assess the actual data flows and controls. The Deploying in the Customer’s Cloud and Security, Privacy, and Governance lessons provide checklists. The FDE gathers technical facts; the customer’s authorized owners make security, privacy, and release decisions.

5. Run UAT and hand over operation

User acceptance testing (UAT) checks the customer-approved tasks in a suitable environment with representative users and owners. Prepare a test plan with cases, expected evidence, reviewer, status, and evidence link. Include dispatchers, a supervisor, the procedure owner, and a platform operator where appropriate. A blocked case is not a pass. A manager’s approval does not replace feedback from the people who perform the task.

Use the release gate from UAT, Go-Live, and Day 2 Operations. If required criteria pass and the customer authorizes release, roll out in stages against agreed health signals. Keep rollback authority and the stop conditions clear. If required evidence is missing or an unsafe behavior remains, pause and resolve it with the responsible owner. Do not invent an acceptable error threshold in the capstone; use the customer’s approved criteria.

Before handoff, rehearse an ordinary operation and a failure scenario. A NorthPort operator should be able to locate the index freshness dashboard, follow the refresh runbook, understand an alert, and contact the right owner. Write down model and prompt versions, source and index versions, support coverage, access request paths, known limitations, and how changes are reviewed. The handoff pack template in Technical Writing for Handoff helps capture this information. The customer confirms responsibility through its approved record, not through an informal statement in a slide.

6. Report what changed and feed the product

After the pilot or launch, report the agreed measure against the baseline if one exists. Separate observed results from estimates and projections. Include the method, period, user group, quality guardrails, limitations, costs, and the decision needed. If no baseline is available, say that the outcome cannot yet be compared and name the owner and plan for collecting it. Use the one-page summary in Executive Reporting and Proving ROI; do not turn demo activity or a projected saving into realized ROI.

Finally, record any product Delta: a gap between what the product supports and what the customer workflow needs. Describe the user task, current behavior, workaround, evidence, scope, and options. Route a product feedback note to the right product, platform, or research owner. The Product Feedback Loop lesson helps assess what might be reusable and what should remain customer-specific. Tell the customer when the request is under review, but do not promise a roadmap date without an explicit product commitment.

GOV.UK’s guidance on discovery supports learning about users, constraints, and assumptions before committing to a solution. Its agile principles describe iterative delivery with frequent feedback and adjustment. These public-service references are used here as adaptable working practices. OpenAI’s account of FDE similarly connects deployment learning with improvements to product and research, but its organization-specific model is not universal.

Capstone artifact checklist

Use this final checklist to see whether another person could follow the engagement decisions and continue the work. Every artifact needs an owner and a location. A blank item means the team should either complete it or state why it does not apply.

Keep learning in the supporting courses

The FDE course focuses on delivery where customer workflows and systems meet engineering. Use the related courses for deeper technical practice instead of re-teaching every topic here:

• AI Agents: deciding between workflows and agents, RAG and vector databases, and evaluating AI agents.
• Prompt Engineering: writing success criteria and test cases and versioning prompts.
• Claude Code: sandboxing, secrets, and development containers.
• Vibe Coding: version control with AI and security for vibe coders.
• AI Product Builders: define the problem, scope the first version, and work with an AI coding tool.

Mistakes beginners make

Treating the customer’s first request as the final scope. The proposed tool may not solve the underlying workflow problem, or may include actions the customer did not intend to automate.

Fix: Observe the workflow, state the user need, define non-goals, and agree what evidence will support the approach.

Skipping data, access, or ownership checks to protect a demo date. A prototype may look complete while using unapproved data or depending on an identity and support path that will not exist in production.

Fix: Track dependencies with owners. Demonstrate with synthetic or approved sandbox data until access and handling are confirmed.

Treating a passing eval or UAT as proof of universal quality. A finite set of tests covers only the cases and criteria it contains.

Fix: Report scope and limitations, inspect failures, add reviewed cases over time, and pair automated checks with customer review where judgment is required.

Leaving without a real operator handoff. A folder of runbooks does not show that the customer has access, has practiced the process, or has agreed to own updates.

Fix: Rehearse a routine task and a failure path with the operating team. Record accepted responsibilities and open items in the customer’s approved system.

Recap and try it yourself

Carry one customer problem from discovery through operations and product learning. Observe the workflow, audit approved data, select a bounded slice, record why the approach fits, and build only in a safe environment. Define customer-approved acceptance evidence, integrate through owned boundaries, and make the release decision with the authorized customer owners. Report the result against a baseline without overstating causality or ROI. Hand over operating knowledge, then turn field evidence into a product note that does not promise a roadmap outcome.

Try it yourself: take the fictional NorthPort assistant through the artifact checklist. For each stage, write one decision, one evidence source, one owner, and one unresolved question. Mark which details are fictional assumptions and which would require customer confirmation. Finish with a short executive status that says whether the service is ready for UAT, go-live, or neither, and explain the evidence behind your choice. No production result is supplied in this exercise, so do not invent one.

Sources

Checked on 5 November 2026. OpenAI’s Forward Deployed Engineering overview describes its own engagement approach, including workflow discovery, defining success, production validation, deployment, and customer ownership. Its FDE explanation describes how field deployments can reveal product or model gaps and inform product and research improvements; this is a company-specific account. GOV.UK’s discovery phase guidance supports exploring user needs, constraints, and assumptions before committing to a solution. Its core agile principles supports iterative delivery, user feedback, and adapting plans to evidence. The UK public-service setting is noted as context; these are used as adaptable delivery practices. NorthPort and all engagement details are fictional.