The 80% of FDE work nobody demos

*SSO. Legacy fields. Security review. The parts that decide whether your agent survives week two.*

If you only watch launch videos, Forward Deployed Engineering looks like clever prompts and a clean UI. In the field, roughly **eighty percent of the real work** is not the demo. It is getting production credentials, surviving identity and access rules, cleaning data nobody documented, passing security review, and leaving something operators can run when you are offline. That is the job described on my Forward Deployed Engineer hub — and the reason FDE is not the same as a polished proof of concept or a ticket-only freelance milestone (FDE vs SE vs freelance).

This post is the unglamorous map: what breaks, why demos lie, and what to harden before you call it shipped.

The short version

A Forward Deployed Engineer spends most of the engagement on **environment reality**: authentication and authorization, messy or incomplete data, network and vendor constraints, security and compliance gates, observability, and handoff. The model call is often the easy line in the stack. If you cannot pass SSO, ground answers in the customer's real corpus, and survive a security questionnaire, you do not have a product — you have a laptop demo.

Why demos lie

Demos are optimized for narrative:

FDE work starts when someone says: *"Cool. Now put it on our stack."*

The four buckets that eat the calendar

1. Identity: SSO, roles, and who may see what

**What breaks:** OAuth redirect URIs wrong per environment. Role claims that do not match who should see which docs or tickets. Service accounts that work in staging and die in prod. "Just use a shared password," which security will reject later.

**What good looks like:** an explicit identity provider path. A role map written down — who can admin, who can chat, who can export. Secrets in a vault or platform store, not in a slide deck. A test user that is *not* the founder's god-mode account.

**The AI-specific twist:** if the agent can retrieve customer data, identity is a **data boundary**, not a login screen. Wrong role means wrong documents in context, which is a silent leak.

2. Data: legacy fields, half-true docs, empty retrieval

**What breaks:** field names that mean three things across systems. Help centers with outdated articles ranked high in search. PDFs that are scans with no text layer, sold as "knowledge base." CRM notes that are gold but never in the corpus. "We have an API" that turns out to be CSV exports on Fridays.

**What good looks like:** a corpus inventory with source, owner, refresh rate and trust level. A thin slice on **live** content before any UI polish. Citation or source tracing so operators can audit answers. A plan for stale content — drop it, downrank it, or flag it.

This is why citation-grounded paths matter. DotChat is built around "every claim back to a page," not freeform confidence. SupportPilot only works if the help docs are the real operational source — and escalation exists when they are not.

**The FDE move:** prove retrieval quality on their mess before debating model brands.

3. Security review: the calendar you did not estimate

**What breaks:** questionnaires about retention, subprocessors and log access. "No training on our data" requirements versus default vendor settings. Pen-test or vendor risk that blocks go-live after the demo wow. Audit needs — who asked what, what the model saw, what was blocked.

**What good looks like:** a one-page data flow diagram (user → app → model → tools → logs). A clear retention and redaction story. Policy checks **before** the model when stakes are high. An exportable audit trail for incidents.

Guardrail-shaped work looks like Mindoor, which policy-inspects before the model and exports an audit PDF, and AgentPayOps, which pairs spend policy with a decision log. Security is not a slide; it is product behaviour.

**The FDE move:** start the security conversation in week one, not after UI freeze.

4. Day-2 ops: when you are not in the Slack thread

**What breaks:** no logs when the agent gets weird. No owner for prompt or corpus updates. An escalation path that dumps users into a void. Rate limits and cost spikes with no alert. One engineer's laptop as the bus factor.

**What good looks like:** minimal observability — request id, user and role, retrieval hits, tool calls, errors. A runbook of common failures and who fixes them. A kill switch or feature flag. A handoff session with the people who will operate it.

If the system requires you forever, you did not finish the FDE loop — you rented yourself as production infrastructure. The five-step loop on the hub ends in **handoff** for a reason.

A hardening checklist before you say "shipped"

Use this as an acceptance gate, and steal it for proposals.

**Identity:** SSO or agreed auth works for a non-admin test user. Roles documented and enforced on data access. Secrets not in client-side code or chat history.

**Data:** corpus sources listed with owners. Thin slice evaluated on real content, not fixture PDFs. Empty-retrieval and low-confidence behaviour defined. Citations or source links where claims matter.

**Security shape:** data flow diagram shared with their security contact. Retention, training and subprocessor answers written down. Policy or allowlist gates where required. An audit log path for sensitive actions.

**Ops and handoff:** basic logging and error visibility. Escalation path tested end to end. A runbook, even one page. A named owner on their side after handoff. Cost and rate-limit awareness.

If half of this is red, you have a demo, not a deployment.

How this shows up in my work

Open tools and case studies are how field pain becomes reusable patterns — the feedback half of FDE, not only the embed half.

How to talk about this with clients

Do not lead with fear. Lead with a path. We ship a thin slice on your real stack in week one. In parallel we map SSO, data sources and security questions. Go-live means hardening and a runbook, not only a happy demo. And here is what you will own after handoff.

That framing separates FDE delivery from proof-of-concept theatre and from "ticket done, environment unknown." More on those role lines in FDE vs Solutions Engineer vs freelance.

Why do people say 80% of FDE work is not the demo?

Because production success is gated by identity, data quality, security and operations. The model path is often a small fraction of calendar time once the customer environment is real.

Should security review wait until the product is finished?

No. Start data-flow and vendor questions early. Late security review is how demos die on the calendar.

Is this only an enterprise problem?

No. Startups hit the same issues with Google Workspace SSO, Notion-as-CMS, and auth delayed until later. Scale changes paperwork volume, not the buckets.

What is the fastest way to de-risk an AI pilot?

A thin vertical slice on live data, an explicit auth path, written empty-retrieval and escalation behaviour, and a one-page data flow for security. Polish the UI after those are green.