Forward Deployed Engineering: Prototype the Risk, Not the AI Demo

A polished AI demo can prove that a model is capable of producing an answer. A strong Forward Deployed Engineering prototype proves that the customer’s riskiest assumption is survivable.

Those are very different objectives.

Start with the expensive decision

Before choosing a model or framework, map the customer workflow using eight questions:

1. User: who actually performs the work?
2. Decision: what decision are they trying to make?
3. Evidence: what information supports the decision?
4. Workflow: what happens immediately before and after?
5. Friction: where does time, ambiguity or rework accumulate?
6. Risk: what happens if the system is wrong?
7. System: what should be probabilistic vs. deterministic?
8. Evaluation: what evidence would convince the customer that the deployment is useful?

This discovery sequence prevents a common failure mode: the customer asks for “an agent,” the team prototypes an agent, and weeks later everyone discovers that the real constraint was permission-aware retrieval, data freshness or an approval workflow.

Build a risk register before a feature list

For an enterprise AI deployment, I would explicitly rank uncertainties such as:

• Can we access the real data under production permission boundaries?
• Can retrieval find the evidence required for the actual decision?
• Can the system distinguish insufficient evidence from low-confidence generation?
• Can tool actions be executed safely and recovered after partial failure?
• Can quality be evaluated without leaking future answers into the benchmark?
• Will latency be acceptable at the customer’s real corpus and concurrency?
• Can a user understand why the system made a recommendation?

The first prototype should attack the highest combination of uncertainty and business consequence.

Prototype a vertical slice, not a toy

A useful FDE prototype is deliberately narrow but end-to-end:

real user
→ real identity
→ representative data
→ retrieval / business logic
→ model reasoning
→ actual tool boundary
→ review / action
→ telemetry

The feature set can be tiny. The architecture path should be real enough to expose integration risk.

Example: scientific question answering

Suppose the request is “build a copilot that answers scientific questions from internal reports.” A weak demo optimizes the chat UI. A risk-first prototype might instead focus on three questions:

• Does permission-aware retrieval return the correct evidence?
• Can generated claims be traced to exact source passages and versions?
• Can reviewers identify unsupported synthesis quickly?

If those fail, a prettier interface will not save the project.

Use a 48-hour architecture loop

For a time-boxed engagement, I like a compact loop:

Discover → frame the decision
Map      → data, systems, permissions, actors
Rank     → technical and adoption risks
Slice    → one end-to-end workflow
Measure  → task quality + system behavior
Review   → architecture tradeoffs
Decide   → deepen, pivot or stop

The output is not just a prototype. It is a better model of the problem.

Know when customer-specific work should become product

Forward deployment creates a broader platform question: when is a customer requirement evidence of a reusable platform primitive?

I would look for repeated constraints , not repeated feature requests. If three customers all ask for different interfaces but share the need for permission-aware retrieval and claim-level provenance, the stable primitive may be the evidence service—not a configurable version of each customer’s UI.

Generalize too early and the platform becomes an abstraction tax. Generalize too late and every deployment becomes a fork.

Define stop criteria

A mature field engagement should be willing to conclude that the current approach is wrong. Stop or pivot when a critical assumption fails repeatedly, when the workflow does not create enough value to justify integration cost, or when the requested behavior would require unsafe or unmaintainable architecture.

The fastest prototype is not the one with the fewest lines of code. It is the one that removes the most uncertainty per day.

What the best FDE work leaves behind

A strong engagement produces four assets: a working vertical slice, an evidence-based architecture decision, an evaluation baseline, and a clear boundary between reusable platform capability and customer-specific integration.

That is why I think of Forward Deployed Engineering as systems engineering under customer pressure—not simply implementation at the edge.