FDE Customer Workshop Playbook: AI Demos That Ship

An FDE customer workshop exists to produce one thing: a decision the customer can act on, ideally a scoped pilot with written success criteria. The demo, the architecture whiteboard and the security Q&A are all means to that end. Forward Deployed Engineers who consistently turn workshops into production work prepare around the customer's real workflow and data, show evaluation, guardrails, cost and latency honestly, handle failures in the room without panic, and send a written recap within a day. This playbook covers the four session types, preparation, running the room, demo design, security teams, follow-up and templates you can reuse.

If you are new to the role, start with what a Forward Deployed Engineer does. Finding and ranking use cases is covered in the AI use case discovery playbook; this article picks up once you have a candidate workflow and a meeting on the calendar.

Why workshops decide whether AI reaches production

Most enterprise AI efforts do not die because the model was weak. They stall because nobody agreed what "working" meant, the security team saw the system for the first time a week before go-live, or the executive sponsor saw a polished demo and assumed the hard part was done. Those are workshop failures, not engineering failures (more in why AI demos fail in enterprise production).

A well-run workshop moves the engagement along Cloudsoft's FDE chain: customer problem → discovery → business requirement → data → AI architecture → security → deployment → evaluation → business outcome. The theme throughout is Cloudsoft's recurring one: from AI demo to enterprise outcome. A demo that does not lead to a decision is entertainment.

The four types of customer sessions

FDEs typically run four kinds of session, each with a different audience and definition of success. Don't show an executive a terminal full of logs, or a security architect a productivity slide.

Session	Who attends	Purpose	Output you leave with
Architecture workshop	Enterprise architects, platform/cloud team, integration owners, data owners	Agree how the AI system fits existing identity, network, data and integration patterns	Agreed reference architecture, list of systems to integrate, open decisions with owners
Hands-on build session	Customer engineers, sometimes power users	Build a thin slice together in the customer's environment so they own part of it	Working code in their repo, a runbook, named people who can run it
Executive demo	Business sponsor, function head, sometimes CIO/CTO	Show one workflow end-to-end and ask for a decision on a pilot	Go/no-go on a scoped pilot, sponsor and budget owner named
Security review session	CISO office, security architects, IT risk, privacy/compliance, sometimes internal audit	Walk through data flows, identity, logging and controls before anything reaches real data at scale	List of required controls, approval conditions, a named security contact

Architecture workshop

This is a whiteboard session, not a slideshow. Draw the current workflow first, then overlay where the AI component sits: which system triggers it, where it retrieves context from, which tools or APIs it calls, where a human approves, and where logs go. Ask about identity early (must calls carry the end user's identity via Microsoft Entra ID, or is a service principal acceptable?), because that decision changes retrieval and tool design. Leave with a diagram the customer's architects edited themselves; they will defend it later.

Hands-on build session

Build sessions work when the scope is small enough to finish in the time available: one retrieval source, one tool call, one evaluation run. Pair-program in their repository and cloud account if allowed. The goal is that a customer engineer can explain and rerun it after you leave; otherwise you have built a dependency on yourself, not a capability.

Executive demo

Short, one workflow, one ask. Executives want to know three things: does it help my people do this task better, what are the risks, and what do you need from me. Prepare the ask before you prepare the demo.

Preparation: what to do before you walk in

1. Stakeholder map

List every person attending and the ones who are not attending but can block the outcome. For each, note what they care about, what they fear, and what decision they own. A simple four-column grid is enough:

Person / role	Cares about	Likely objection	Decision they own
Head of operations (sponsor)	Backlog, turnaround time	"Will my team trust it?"	Pilot go/no-go, which team pilots
Security architect	Data leaving the boundary, audit trail	"Where does the prompt go?"	Approval to use real data
Platform lead	Supportability, on-call load	"Who runs this at 2 a.m.?"	Hosting and deployment path
Team lead (end users)	Fewer manual steps, no extra clicks	"Another tool to log into?"	Whether users actually adopt it

The person who matters most is often the one who says least in the room. Find out who that is before the session, usually by asking your champion directly.

2. Data access

Ask, in writing and early, what data you may use, in which environment, and under which approvals. Typical answers range from "only synthetic data" to "a masked sample in our sandbox" to "read-only access to a test tenant". Each answer shapes the demo. If personal data is involved, check obligations under India's DPDP Act (see the DPDP Act for AI applications) and any sector rules the customer follows. Never copy customer data to your laptop or a personal account to "save time" — that alone can end an engagement.

3. Environment

Decide where the demo runs: your cloud account, the customer's sandbox, or a recording. Check model access in the region the customer requires, API quotas, VPN or proxy rules, and whether the meeting room network blocks the endpoints you need. Do a full dry run on the same network type, and keep a screen recording of the flow as a fallback.

4. Demo with the customer's own data, where allowed

Nothing persuades like the customer's own documents, tickets or forms. A demo on a public dataset invites the reasonable response "our data is messier than that". Where real data is not allowed, build a realistic synthetic set that mirrors their formats, field names and edge cases, and say clearly that it is synthetic. Include a few genuinely awkward cases — a scanned PDF, a document with a table split across pages, a ticket in mixed Hindi and English — so the demo is honest about where the system struggles.

Running the room

Agenda and timeboxing

Send the agenda at least a day ahead and restate it in the first two minutes. State the outcome you want from the session ("by the end, we'd like to agree whether to run a four-week pilot with the claims team"). Timebox each block and protect the last fifteen minutes for decisions and next steps; that block is the first to get eaten by an overrunning Q&A, and it is the one that matters most.

Live coding vs recorded demo

Approach	Use when	Risk
Live, end-to-end	Build sessions; technical audiences who want to see it is real	Network, quota or model variance can break the flow
Live with recorded backup	Most executive and architecture sessions	Low, if you switch quickly and say why
Recorded only	Unreliable network, very large audience, strict environment rules	Audience may suspect it is staged; offer a live follow-up

A useful default: run the core workflow live, and keep the slow or fragile parts (a long batch evaluation, a multi-step agent run) as pre-recorded segments you narrate. Tell the audience which parts are which.

Handling failures live

Models are non-deterministic and integrations fail. How you handle a break often builds more trust than a flawless run. A simple routine:

Name it. "That answer is wrong — it cited last year's policy." Do not pretend it did not happen.
Diagnose briefly. Open the trace (in LangSmith, Langfuse or your own logs) and show what was retrieved. Often the failure is visible: the wrong chunk ranked first.
Connect it to the design. "This is exactly why the pilot includes an evaluation set and a human approval step for policy answers."
Move on. Switch to the backup recording if needed. Note the failure for the recap.

Never spend more than a minute or two debugging in front of executives; with engineers in a build session, debugging together can be the most valuable part of the day.

Saying "I don't know"

You will be asked things you cannot answer: a licence term, a specific regulator's position, how a vendor stores logs in a given region. The professional answer is: "I don't know. I'll find out and include it in the recap by Thursday." Then do it. Guessing in front of a security team or a legal stakeholder is far more damaging than admitting a gap. Keep a running "open questions" list on screen or on the whiteboard; it becomes part of your recap and shows that nothing was lost.

Designing an AI demo for enterprise customers

A good AI demo for enterprise customers looks less impressive than a typical conference demo and is far more convincing. Four principles:

One workflow, end-to-end

Pick one real task and show it from trigger to outcome. For example: a ticket arrives in ServiceNow, the assistant retrieves the relevant runbook, drafts a resolution, a human approves it, and the ticket updates. One workflow shown completely, including the human step and the write-back, shows you understand how work actually happens.

Trigger (ticket / email / form)
        |
  Retrieve context (approved sources)
        |
  Draft / decide (LLM + guardrails)
        |
  Human review  --reject-->  feedback log
        |
  Write back to system of record
        |
  Trace + metrics (cost, latency, quality)

Show evaluation, not just answers

After the live flow, show a small evaluation set (say, a few dozen representative questions agreed with the customer's experts) and the results: which passed, which failed, and why. Show faithfulness or groundedness scores if you ran Ragas, and the failures you have not fixed yet. This changes the conversation from "is it good?" to "is it good enough for this use, and how will we know?". See LLM evaluation for how to build such a set.

Show guardrails

Deliberately trigger a guardrail: ask a question outside scope, try a prompt injection hidden in a document, ask for data the demo user is not entitled to. Show the system refusing or escalating. Risk stakeholders relax when they see you have already tried to break your own system. The AI guardrails guide covers the layers worth showing.

Show cost and latency honestly

Put a small panel on screen with tokens used, estimated cost per request and response time for each run. If a multi-step agent takes several seconds, say so and explain the options (smaller model for routing, caching, streaming, async processing). Hiding latency in a demo creates a problem you will meet in the pilot anyway. For the levers, see LLM latency optimisation. Do not quote a per-month cost figure in the room unless you have modelled it on their volumes; give the per-request number and the method instead.

A useful rule of thumb: if your demo has no failure case, no cost number and no human step, it is a marketing video, not an engineering demo.

Handling sceptical security and IT teams

Security and IT teams are not obstacles; they are the people who will be paged when your system misbehaves. Their scepticism is usually rational and specific. Answer it with architecture, not reassurance.

Prepare a one-page data-flow diagram and a short control sheet before the session. Expect these questions and have direct answers:

Where does data go? Which model endpoint, which region, whether the provider retains prompts, whether traffic stays on private networking.
Who can see what? How retrieval respects document-level permissions; whether the agent acts with the user's identity or a service identity; least-privilege scopes for every tool.
What is logged? Prompts, retrieved chunks, tool calls and outputs, retention period, masking of personal data in logs, who can access traces.
What stops misuse? Input and output guardrails, prompt-injection defences, tool allow-lists, human approval for irreversible actions, rate limits.
What happens when it goes wrong? Kill switch, rollback, incident runbook, named owner.
Vendor questions. Model provider terms, data residency, sub-processors — the checklist in AI vendor due diligence is a useful starting point.

Three habits help. First, invite security to the architecture workshop, not only the formal review — late involvement is the most common reason for late rejection. Second, propose a staged approach: synthetic data first, then masked data in a sandbox, then limited real data with logging, so each step needs a smaller approval. Third, turn every condition they set into a pilot task with an owner; a security team that sees its conditions in your plan starts reviewing the plan instead of doubting you.

Illustrative example: an insurer's claims team

Consider a mid-sized insurer whose IT is run partly from a GCC in Hyderabad. The operations head wants help for claims handlers who read long policy wordings to answer coverage questions. Discovery has already identified this as the candidate use case.

Architecture workshop (half a day). The FDE draws the current flow with the claims and platform teams. Two decisions surface: policy documents live in a document management system with per-product access rules, and the insurer requires all model traffic through its cloud account in an Indian region. Security is in the room and asks for prompt logging with masking of policyholder details.

Build session (two days). Working with two of the insurer's engineers, the FDE builds a thin slice: ingest a few hundred masked policy documents into PostgreSQL with pgvector, a FastAPI retrieval service, and an evaluation set of questions written by senior claims handlers. The customer's engineers own the repo by day two.

Executive demo (forty-five minutes). One claim scenario end-to-end: question in, cited clauses out, handler approves, note written to the claims system. The FDE shows the evaluation results including the failures (clauses referenced from endorsements were missed), a blocked injection attempt in a test document, and per-request cost and latency. The ask: a six-week pilot with one claims team.

Outcome. The sponsor agrees, conditional on security's three controls being in place before real data is used; those become the pilot's first three tasks. Nothing here needed a better model, only a better-run sequence of sessions.

If you want to practise exactly this sequence — architecture whiteboarding, a build slice, an executive demo and a security review — against a simulated enterprise customer, the AI Forward Deployed Engineer course (FDE PRO) dedicates one of its five weekly sessions to a Customer Engagement Lab and ends with the GlobalBank capstone, a simulated customer engagement.

Follow-ups and the written recap

The recap email is where workshops become projects. Send it within one working day, while memories are fresh and before someone else's version of the meeting circulates. It records what was agreed, what was not, the open questions (including every "I don't know"), and next steps with names and dates.

Share the artefacts with it: the edited architecture diagram, the evaluation results, the demo recording, and the code location if a build session happened. Ask the sponsor to reply confirming or correcting the decisions — a written "yes, that's right" is worth more than a verbal agreement in the room.

Then do the follow-ups you promised, on the dates you promised; reliability on small commitments is how an FDE earns production access (see the FDE's first 90 days).

Turning a workshop into a scoped pilot

The step from "that was a great session" to "we have a pilot" is where many engagements drift. Close it with a one-page pilot scope that names:

One workflow, one user group. A single team, a defined set of tasks, a fixed duration.
Baseline. How the task is done today and how long it takes or how often it goes wrong, measured by the customer, not estimated by you.
Success criteria. Quality, adoption, operational and safety measures agreed in advance (template below).
Data and environment. Which data, which approvals, where it runs.
Controls. The security team's conditions, each as a task with an owner.
Exit decision. What happens if criteria are met (production plan), partly met (iterate), or not met (stop, with lessons recorded).

Agreeing the stop condition up front is what makes a pilot credible to senior stakeholders. The full path from pilot to production, with stage gates, is covered in how FDEs take AI from POC to production, and building the business case on the measured baseline in enterprise AI ROI.

Templates you can reuse

Template 1: Workshop agenda (half day)

Goal: agree whether to run a pilot for [workflow]
0:00  Introductions, goal, decisions needed today
0:10  Current workflow walk-through (customer leads)
0:40  Proposed architecture (whiteboard, editable)
1:20  Break
1:30  Live demo: one workflow end-to-end
2:00  Evaluation results, guardrails, cost/latency
2:30  Security and data questions
3:15  Decisions, open questions, owners, dates
3:30  Close

Template 2: Recap email

Subject: [Customer] x [Team] workshop recap, [date]

Thanks for the session. Summary below; please
reply with corrections by [date].

Agreed
- Pilot candidate: [workflow], [team]
- Architecture: [diagram link], hosting in [region]

Not yet agreed
- [item], owner [name], decide by [date]

Open questions (we owe you answers)
- [question], [our owner], by [date]

What we showed
- Demo recording: [link]
- Eval results: [link] (incl. known failures)

Next steps
1. [action], [owner], [date]
2. [action], [owner], [date]

Proposed next meeting: [date], [purpose]

Template 3: Pilot success criteria

Dimension	Measure	Target (agree with customer)	How measured
Quality	Answers judged correct and grounded by domain experts	[threshold on agreed eval set]	Weekly expert review + automated eval
Safety	Responses violating policy or exposing restricted data	[target, usually zero tolerance]	Red-team set, guardrail logs
Efficiency	Time per task vs baseline	[improvement vs measured baseline]	Time sampling by team lead
Adoption	Share of eligible tasks where users chose the tool	[target]	Usage logs
Operations	Latency, error rate, cost per request	[limits]	OpenTelemetry traces, billing
Exit	Decision at end of pilot	Scale / iterate / stop	Sponsor review meeting

Leave targets blank until the customer fills them in; criteria you write alone bind nobody else.

Common mistakes

Demoing features instead of a workflow. The audience is left to imagine the use case.
Using a public dataset when the customer's data was available. It invites doubt you could have avoided.
Hiding failures, cost or latency. They surface in the pilot, and then your credibility goes with them.
Bringing security in at the end. Late reviewers have only one safe answer, and it is no.
Overpromising in the room. "We can integrate that by next week" said to please a sponsor becomes your problem on Monday.
No decision ask. A session without a clear ask ends with "let's reconnect", which often means never.
No written recap, or a late one. Each attendee remembers a different meeting.
Building alone in a build session. If the customer's engineers only watched, they cannot run it after you leave.

How to build these forward deployed engineer customer skills

Customer skills sit on top of engineering skills; they do not replace them. You cannot open a trace to diagnose a failure live unless you built observability in, and you cannot answer a security architect's identity question unless you understand how your agent authenticates. The engineering side — RAG, agents, MCP tool integration, evaluation, cloud deployment — is covered in the FDE skills employers look for.

The customer side improves with deliberate practice: mock workshops with a colleague playing the sceptical security architect, recording and reviewing your own ten-minute demo, and a written recap after every meeting.

If you are earlier in your career and want broad foundations first — Python, ML, GenAI and agents, AWS, DevOps and security across 16 weeks — the APEX AI, ML, Cloud and Security program is the broader starting point, with a capstone demo and presentation in its final phase.

Frequently asked questions

What is an FDE customer workshop?

An FDE customer workshop is a structured working session in which a Forward Deployed Engineer and the customer's team map a real workflow, agree an architecture, review security and data access, or build part of an AI system together. Its purpose is to reach a decision, usually whether to run a scoped pilot.

Should an AI demo for enterprise customers be live or recorded?

Run the core workflow live where the environment is reliable, and keep slow or fragile parts as recordings you narrate. Always have a full recorded backup. Tell the audience which parts are live so the demo stays credible.

What should I do if the AI gives a wrong answer during a demo?

Name the error, open the trace to show briefly why it happened, connect it to the controls in your design such as evaluation sets and human review, and move on. Handled calmly, a live failure often builds more trust than a perfect run.

How do I handle a sceptical security team?

Bring a data-flow diagram and a control sheet covering data location, identity, logging, guardrails and incident response. Involve security early, propose staged data access, and turn each of their conditions into a pilot task with an owner.

What goes into a workshop recap email?

What was agreed, what was not, open questions you owe answers to, links to the diagram, recording and evaluation results, and next steps with owners and dates. Send it within one working day and ask the sponsor to confirm it.

How do you turn a workshop into a pilot?

Write a one-page pilot scope with one workflow and one user group, a customer-measured baseline, agreed success criteria, data and environment approvals, security conditions as tasks, and an exit decision of scale, iterate or stop.

Can freshers learn forward deployed engineer customer skills?

Yes. Practise by presenting your own projects as customer demos with one workflow, evaluation results, a failure case and a cost figure, run mock workshops with peers, and write recaps for every meeting. Pair this with solid engineering skills, since customer skills depend on them.

Workshops and demos are where an FDE's engineering work becomes a customer's decision. If you want to learn both sides together — building production-grade RAG and agent systems and running the customer sessions that get them approved — explore the Cloudsoft FDE PRO program: 12 weeks, 60+ labs, five enterprise projects and the GlobalBank simulated customer engagement, in our Ameerpet classroom beside Ameerpet Metro or live online, with placement support until you're placed. Call +91 96660 19191 for a free demo session.