Zero to Demo

⏱ ~9 min read · 🎧 9 min listen · ✎ 3 quizzes · 🧪 ~120 min lab

Everything you've built so far — prompts, agents, retrieval, evals — has lived in scripts and terminals. This lesson is about the move that actually starts an engagement: going from a vague customer problem to a working demo, fast. FDE delivery cycles run days to weeks, not quarters¹, and FDE interview loops test exactly this muscle — OpenAI's loop centers on a roughly five-hour take-home prototype you then walk through and defend.⁵ A quick honesty note: the literature on how to do 0→1 field work is thin, because the role is young. What follows is synthesized from the FDE sources in this course plus standard engineering judgment, and labeled as such — the mechanics are opinionated, the claims about the role are cited.

Thin vertical slices, not horizontal layers

The instinct of a good senior engineer is to build foundations first: data layer, then services, then API, then UI. In an FDE engagement that instinct is a trap — after a week of horizontal work you have excellent plumbing and nothing a customer can react to. The FDE cut is a vertical slice: one narrow user journey, end to end, through every layer — real input, real model call, visible output. Palantir's founding discipline was "consistently identify the most valuable thing to be working on"³; in week one of an engagement, the most valuable thing is almost always the thinnest slice that makes the value visible.

Demo-driven scoping: build what the meeting needs to see

Here's the scoping trick that makes days-not-sprints possible: work backwards from the meeting. There is a date, a room, and a set of stakeholders; the demo exists to change what those specific people believe. So write the demo before you write the code — literally script it: five steps, what you click, what you say, what the skeptic in the room should conclude at each step. That demo script is your scope document. Anything the script doesn't touch, you don't build this week. This is "building under ambiguity" in practice — the competency hiring managers weigh over raw coding⁴: nobody will hand you a spec, so the demo script becomes the spec you hand yourself.

What to fake, what to build for real

A demo built in days is partly faked — that's not a confession, it's the craft. The judgment call is which parts. Build for real the thing the demo is claiming: if the claim is "the model can triage these messages and pick the right tool," the model calls and tool selection must be live — a hard-coded response there isn't a demo, it's a video with extra steps. Fake the things the demo makes no claim about: synthetic records instead of production data (you won't have real data in week one, and in regulated domains you may never get it), a stubbed CRM lookup instead of a six-week integration, no auth, one happy path. The rule of thumb: real mechanism, simulated surroundings. Retire the risk the customer is actually buying answers about; cardboard everything else.

And then — this is the part that separates an FDE from a demo artist — say so out loud. Every demo ships with a "what's real / what's faked" appendix, and you volunteer it before anyone asks. This is the AI-judgment thread again: models are persuasive even when wrong⁴, and demos are persuasive even when faked. A slick demo that lets the room believe the stubbed CRM integration is live, or that the happy path is the typical path, is manufacturing exactly the kind of false confidence that lands in the 95% of pilots showing no measurable impact.⁶ Honest theatre builds trust faster than perfect theatre: "this part is live, this part is cardboard, here's what it takes to make the cardboard real" is a statement only someone who can actually build it would make.

Days, not sprints

The cadence that makes this work: show working software every few days, on the customer's real problem, and let their reactions steer. That's the day-to-day the role is hired for — on-site integrations, debugging against real systems, delivery cycles measured in days to weeks, high autonomy¹ — and it's why Anthropic's posting asks for engineers who ship "technical artifacts for customers" rather than roadmap features.² A two-week sprint with a demo at the end gives you one steering input per fortnight; a daily thin-slice rhythm gives you ten. When the problem is ambiguous — and it always is — the team that steers ten times wins.

A demo people can click beats a notebook

Last piece: the surface. Your triage agent from Lesson 03 works, but it works in a terminal — and a stakeholder watching you narrate JSON is evaluating you, not the system. Put the same agent behind a chat box in a browser and something shifts: they type their own message, it answers, and now they're evaluating it. This is where a minimal TypeScript/web skill earns its place in an FDE toolkit (postings list JS/TS alongside Python⁷) — not to become a frontend engineer, but to give the mechanism a clickable surface. And show the mechanism, not just the answer: a visible trace panel — "the agent chose lookup_order, here's why" — turns a magic trick into an inspectable system, which is what a technical buyer actually needs to trust it.

🧪 Practical steps: the 48-hour-style demo (~120 min)

You're going to do the classic FDE move: take the triage agent you built in Lesson 03 and wrap it in a small web demo a stakeholder could click — chat box, visible tool-call trace panel, scripted demo path, and an honest "what's real / what's faked" appendix. Python backend, minimal HTML/TypeScript front. Full instructions and starter code live in labs/0006-zero-to-demo.md in the course repo; the portfolio artifact lands in D:\Projects\FDE-Portfolio\l06-demo\.

1. Lift the mechanism — copy your Lesson 03 triage agent (tools + agent loop) into l06-demo/agent.py, unchanged. The demo's claim is "the agent picks the right tool" — so that part stays real.
2. Wrap it in a tiny backend — a FastAPI app with one endpoint, POST /api/chat, that runs the agent loop and returns the reply plus the full tool trace: every tool called, its input, its result.
3. Build the one-page UI — a single index.html with a chat pane and a trace pane. Write the logic in app.ts, compile with tsc (starter provided). No framework, no build pipeline — trivially runnable.
4. Make the trace panel the star — each tool call renders as a card: tool name, arguments, result. You are demoing the mechanism, not just the answer.
5. Script the demo — demo-script.md: five steps, each with what you click, what you say, what the skeptic should now believe. Include one deliberate "watch it decline" step — the agent refusing an out-of-scope request is your AI-judgment beat.
6. Write the honesty appendix — whats-real-whats-faked.md: two columns. Real: model calls, tool selection, refusal behavior. Faked: synthetic customer records, stubbed lookups, no auth, single happy path. For each faked item, one line on what making it real would take.
7. Run your own demo script end to end, timed. If it takes more than three minutes or any step needs an apology, cut or fix that step. Then commit the folder to your portfolio repo.

Feedback loop: bring the demo script and the honesty appendix back to me in chat and I'll review them like the skeptical platform lead in the room — is the slice the right one, does the script persuade, does the appendix confess enough? This artifact feeds the Lesson 11 capstone engagement (where you'll demo to a fictional exec team) and is tracked in the course's artifact tracker.

You are a skeptical enterprise platform lead watching a Forward Deployed Engineer demo a prototype built in about two days: a web chat UI over an LLM triage agent with a visible tool-call trace panel. I'm the FDE. Below I'll paste my 5-step demo script and my "what's real / what's faked" appendix.

Grade each criterion as Strong / Adequate / Missing, with one sentence of evidence:
- Slice choice: the demo proves the riskiest claim (the model's mechanism — tool selection, refusals) live, rather than showing polish on things nobody doubted.
- Demo-script persuasiveness: each of the 5 steps names what is clicked, what is said, and what a skeptic should now believe — and the script would survive me interrupting with "is that part real?"
- Honesty of the appendix: every faked element is disclosed with what making it real would take, and nothing in the script implies a capability the appendix admits doesn't exist.

Be adversarial: find the one moment in the script where the room would most likely form a false belief, and quote it. Then ask me the 2 questions you'd ask live to test whether the mechanism is genuinely real. Finish with the single change that would most improve the demo.

My demo script and appendix follow below.

Check yourself — think like an FDE

Scenarios, not recall. Diagnose from the mental model — don't scroll up. Wrong picks stay live.