The Forward-Deployed Engineering Brief: A Template for AI Deployments

What is a forward-deployed engineering brief?#

A forward-deployed engineering brief is the smallest useful agreement between a customer problem and a production deployment. It names the workflow that must change, the evidence that would prove improvement, the system boundary, the risks, the people who own the result, and the next decision. Write it before substantial implementation, then revise it as real evidence replaces assumptions.

For AI work, this brief is especially important. A request such as “add an agent to support” hides decisions about data access, tool authority, acceptable errors, human review, latency, cost, rollout, and adoption. If those decisions remain implicit, the team can build a convincing demonstration while still disagreeing about what production success means.

Current first-party descriptions of forward-deployed engineering converge on this wider accountability. OpenAI's FDE role spans discovery, technical scoping, system design, implementation, production rollout, adoption, workflow impact, and eval-driven feedback. Palantir's FDSE role starts with open-ended customer problems and gives small teams end-to-end responsibility across architecture, data, applications, executives, and strategy.

The operating model is also becoming more explicit at organizational scale. The OpenAI Deployment Company describes engagements that diagnose high-value workflows and connect models to customer data, tools, controls, and business processes. AWS Forward Deployed Engineering emphasizes production outcomes, reusable knowledge, and customer self-sufficiency. Microsoft Frontier Company adds deep industry knowledge, change management, governance, model choice, and ROI.

None of those companies publishes or endorses the template below. It is my synthesis of their public operating boundaries and my own experience shipping software across mobile, web, backend, encrypted systems, and applied AI. I have not held an FDE title at those companies, and I will distinguish a hypothetical example from a customer result.

Why write the brief before writing more code?#

The brief makes ambiguity inspectable. It is not a promise that discovery will uncover no surprises. It is a record of what the team currently believes, which assumptions remain weak, and what evidence will settle the important disagreements.

A useful brief prevents five common substitutions:

• A solution for an outcome. “Build a RAG agent” is an implementation choice. “Reduce escalation preparation time without lowering evidence completeness” is an outcome.
• A demo for production. A selected example does not test permissions, real distributions, failure recovery, cost, or adoption.
• Activity for progress. More integrations and prompts can increase scope while leaving the central workflow unchanged.
• An average for a safety contract. A high aggregate score can hide one unacceptable class of failure.
• deployment for ownership. Software can be live while nobody knows who monitors, supports, or disables it.

The document should stay short enough to use during decisions. Link to an architecture decision record, threat model, data map, eval report, or runbook when depth is required. The brief is the control surface, not the entire aircraft.

Copyable forward-deployed engineering brief#

Copy this Markdown into the working repository or project space. Replace every bracketed prompt. If a section is unknown, write “unknown,” name the person who will resolve it, and set a date. Empty certainty is more dangerous than visible uncertainty.

Open the clean Markdown template if you want a copy without the article around it.

# Forward-Deployed Engineering Brief

Deployment: [short name]
Status: [discovery | build | validation | canary | scale | stopped]
Brief owner: [one editor]
Workflow owner: [person accountable for the current operation]
Technical owner: [person who will operate the deployed system]
Sponsor: [person who can decide scope and accept risk]
Decision date: [YYYY-MM-DD]
Last updated: [YYYY-MM-DD]

## 1. Outcome in one sentence
For [named users], improve [workflow outcome] from [baseline] to [target]
without worsening [quality, safety, cost, or compliance guardrail].

## 2. Current workflow and baseline
- Trigger and desired terminal outcome:
- People, steps, systems, and handoffs:
- Volume, queue time, handling time, error, rework, and cost:
- Known exceptions and recent failures:
- Evidence source and measurement window:

## 3. Users and decision-makers
- Primary operator:
- Person affected by the result:
- Data/security/compliance owners:
- Who approves rollout, rollback, and expansion:

## 4. Production hypothesis
If we [bounded intervention], then [named users] will [changed behavior or
outcome], because [reason], demonstrated by [evidence].

## 5. Scope and non-goals
- Included users, cases, geography, systems, and time window:
- Explicitly excluded:
- Existing workflow retained as fallback:

## 6. Constraints and access
- Data sources, sensitivity, residency, retention, and tenant boundaries:
- Identity, permissions, APIs, infrastructure, and deployment policy:
- Legal, regulatory, procurement, or model-provider constraints:
- Missing access and owner/date to resolve it:

## 7. Narrow production slice
- User-visible path from trigger to terminal action:
- AI/model responsibilities:
- Deterministic software responsibilities:
- Human review and escalation:
- Versioned prompts, models, tools, and retrieval configuration:

## 8. Quality and evaluation contract
- Representative common, edge, known-failure, and adversarial cases:
- Task-specific pass criteria:
- Unacceptable failure classes:
- Human calibration and regression cadence:
- Evaluation owner and evidence location:

## 9. Authority, security, and failure
- System may read:
- System may propose:
- System may change automatically:
- Actions requiring human approval:
- Timeouts, retries, fallback, rate limits, audit trail, and kill switch:
- Threats and residual risks accepted by whom:

## 10. Success measures
- Workflow outcome:
- AI quality:
- Reliability and latency:
- Cost per completed outcome:
- Adoption, override, escalation, and safety:
- Pass, revise, stop, and scale thresholds:

## 11. Rollout and rollback
- Shadow or offline phase:
- Canary users/cases and duration:
- Monitoring and review cadence:
- Stop conditions and rollback owner/procedure:

## 12. Adoption, operations, and handoff
- Training and workflow change:
- Dashboard, alerts, runbook, support, and on-call owner:
- Customer team capability required before handoff:
- Artifacts delivered and handoff rehearsal date:

## 13. Productization and next decision
- Customer-specific work:
- Reusable configuration, tooling, documentation, or product primitive:
- Evidence that would change the roadmap:
- On the decision date, choose: scale | revise | stop.
- Decision log with dates, evidence, and owners:

How to fill it without creating project theater#

Begin with a workflow baseline, not an AI ambition#

Observe the current work before proposing the future work. Ask an operator to process ordinary cases, difficult cases, and a recent failure. Record the trigger, sources of truth, decision points, workarounds, exceptions, and terminal outcome. Measure enough of the current workflow to support a comparison.

The baseline does not need to be perfect. It needs a source, a window, and an honest limitation. “Median handling time was 46 minutes across 83 priority escalations in June; timestamps omit off-platform Slack work” is useful. “Support is slow” is not.

Make the production hypothesis falsifiable#

A good hypothesis specifies the intervention, user, behavior, reason, and evidence. It should be possible for a competent team to reach “stop.” If the wording guarantees success regardless of the result, it is positioning copy rather than an engineering hypothesis.

Choose the narrowest slice that crosses the real production boundary. Use real identity, representative data, actual integrations, logging, a terminal user action, and a safe fallback. Narrow means fewer users and cases, not fake infrastructure around the hard part.

Separate model quality from workflow value#

An AI component can improve while the workflow gets worse. Track task quality and operational effect separately. For example, citation correctness belongs to the eval contract; time to resolve an escalation belongs to the workflow contract. Both matter, but they answer different questions.

Name unacceptable failures rather than hiding them inside an average. Cross-tenant disclosure, an unauthorized action, or a fabricated compliance citation may each be a launch blocker even when the overall pass rate is high. Define who grades difficult cases and how disagreements are resolved.

Write authority as verbs#

“The agent has access to the ticketing system” is too vague. Can it search, read, draft, tag, send, close, refund, or delete? List what it may read, propose, and change. Then name approval requirements, audit evidence, rate limits, fallback, and a kill switch.

This section often removes unnecessary autonomy. If a read-only assistant with human approval can test the workflow hypothesis, granting write authority only increases risk and review cost.

Design the exit while the team still has attention#

AWS's public FDE model explicitly makes customer self-sufficiency an engagement outcome. That principle is useful beyond AWS: a deployment is fragile if it depends indefinitely on the one engineer who built it.

Define the technical owner, dashboard, alerts, runbook, failure rehearsal, access inventory, versioning procedure, and training before rollout. Also decide what field work should become configuration, documentation, tooling, or a core product primitive. Otherwise, the engagement can succeed for one customer while making the product organization less scalable.

Worked example: an AI-assisted escalation packet#

The following example is fictional. The numbers are illustrative, not claimed customer results. It shows how a vague request becomes a bounded deployment decision.

Request: “Build an AI support agent that handles enterprise incidents.”

Outcome: For three senior support leads, reduce median preparation time for priority integration escalations from an observed 46 minutes to 30 minutes, without reducing required-evidence completeness or allowing the system to contact customers or change production.

Current workflow: A lead reads the ticket, searches account configuration, checks recent deployments and service health, asks engineering for logs, and assembles a handoff in Slack. Across 83 June cases, 18% of first handoffs omitted at least one item from the engineering team's required checklist. Some work happens in Slack, so the time baseline is directional.

Hypothesis: If a read-only assistant gathers allowlisted account, deployment, health, and log evidence and drafts a cited escalation packet, support leads will prepare a complete handoff faster because they no longer repeat the same searches across four systems.

Scope: Priority integration incidents for one product and one region; three support leads; 30 days. Exclude general support, customer messaging, incident diagnosis, ticket closure, production changes, and automated escalation.

Production slice: An authenticated lead opens a ticket and requests a packet. Deterministic code resolves tenant and account identifiers. The model selects from read-only tools, structures evidence under the existing checklist, cites every source, labels missing evidence, and drafts a summary. The lead verifies, edits, and manually sends it to engineering.

Evaluation contract: Use 100 de-identified historical tickets: 60 common, 20 edge, 10 known-failure, and 10 adversarial. Require every factual claim to have a valid source reference, at least 95% checklist-field correctness, no cross-tenant retrieval, and no unsupported root-cause assertion. A support lead and an engineer adjudicate ambiguous cases.

Risk and authority: Tickets may contain prompt injection or secrets; logs may be stale; retrieval may cross tenant boundaries; the model may confuse evidence with diagnosis. Controls include tenant-scoped server-side retrieval, allowlisted read-only tools, output validation, source timestamps, explicit “evidence” versus “inference” fields, human approval, audit logs, rate limits, and an independent kill switch.

Success measures: At least a 30% reduction in median preparation time, no increase in engineering-requested rework, 95% citation correctness, zero critical security failures, cost below $1.50 per completed packet, and weekly use by at least two of the three leads. The thresholds are hypotheses to validate, not universal benchmarks.

Rollout: Run offline against historical cases, then shadow live work for five days without showing output. Canary with one lead for three days, then all three if quality and security thresholds hold. A support manager owns rollback; disabling one feature flag returns everyone to the existing workflow.

Handoff and decision: Deliver the eval set, data map, dashboard, runbook, access inventory, prompt/tool versions, and rollback rehearsal. On day 30, choose scale, revise, or stop. If evidence gathering generalizes but the summary does not, productize the retrieval checklist and revise the generative layer rather than declaring the whole deployment successful or failed.

The brief does not guarantee that this system is worth building. It makes the decision legible. The sponsor can see the operational bet, security can see the authority boundary, engineers can see the production slice, operators can see how their work changes, and the day-30 review has evidence to inspect.

Anti-patterns that weaken the brief#

• The outcome is a feature. Replace “launch an agent” with a named workflow change and guardrail.
• The baseline is folklore. Use a bounded sample and document its gaps instead of inventing precision.
• Scope only says what is included. Non-goals prevent adjacent requests from silently becoming commitments.
• Quality is one percentage. Define the dataset, grader, pass criteria, and unacceptable failure classes.
• The model owns an undefined action. Express permissions as read, propose, change, and approve verbs.
• The sponsor is mistaken for the user. Name the operator who performs the workflow and observe their work.
• Production means “deployed.” Include adoption, operations, rollback, cost, and an accountable owner.
• Every field request becomes product. Separate customer-specific work from patterns that genuinely repeat.
• The brief is frozen after kickoff. Update assumptions when evidence changes, but preserve a dated decision log.
• The brief becomes a gatekeeping document. Its purpose is faster, safer decisions. Delete sections that do not affect this deployment; do not fill them with ceremonial prose.

Where the brief fits in forward-deployed work#

The brief sits between discovery and delivery, then remains active through rollout. It gives the forward-deployed engineer a shared contract without pretending the field is predictable. It also creates better product feedback: a recurring need is easier to recognize when deployments describe outcomes, constraints, and reusable artifacts in the same language.

For the full role boundary, read the FDE and FDSE definition. If you are building the team, the FDE hiring scorecard tests whether a candidate can discover, build, evaluate, communicate, and productize this kind of work. Once the brief is aligned, the 30-day prototype-to-production playbook provides a practical execution sequence.

The brief is not a substitute for judgment. It is a way to expose judgment early, while scope is still cheap to change and risk is still possible to bound. That is the kind of work I mean when I describe my forward-deployed engineering approach: get close to the real workflow, ship the narrowest production truth, measure it honestly, and leave the system easier to own.

If you have an AI prototype but the deployment boundary is still unclear, send me the workflow, users, current systems, and the decision you need to reach. We can start with the brief before either of us pretends the answer is more code.