FDE without improvisation: the harness that turns the customer mission into a verifiable product

Forward Deployed Engineering reduces the distance between a real problem and a production system. That proximity, however, does not eliminate architecture. It increases the need for a contract that preserves intent, authority, evidence, and learning as the customer context changes.

Without this contract, the FDE becomes a local hero: they know everything, fix everything, and leave behind a variant no one else can operate. With an explicit harness, the mission becomes a verifiable sequence of decisions and the particular case returns reusable capability to the platform.

Executive summary

The FDE role can be described by a loop:

missão → descoberta → spec → build → evals/controles → produção → adoção
   ↑                                                               ↓
   └──────────── evidência, feedback e padrão reutilizável ─────────┘

The harness is not an interface framework or a collection of prompts. It is the system around the model that connects objective, context, tools, identity, policies, verifiers, receipts, and acceptance authority.

1. The mission must become an executable contract

“Improve service” or “automate analysis” does not define what may be executed. Before the build, record:

• outcome and affected population;
• baseline and acceptance signal;
• authorized data and systems;
• permitted and prohibited actions;
• problem owner and release authority;
• stopping, escalation, and rollback conditions.

This contract separates discovery from authorization. Understanding a pain point does not grant access to all data or permission to change production.

2. Discovery must produce artifacts, not only tacit understanding

The FDE observes the workflow, interviews people, and finds exceptions. If that knowledge remains in conversations or one person's memory, it will not survive the session. Turn discovery into a state map, examples, a glossary, decisions, and evaluation cases.

OpenAI's public descriptions bring discovery, scoping, system design, build, and rollout together in the FDE role. The correct technical reading is not to abolish specialties. It is to preserve continuity between what was observed and what will be built, without losing security and operations gates.

3. The spec controls divergence

The first product of discovery is a short, testable spec:

The spec does not need to predict everything. It must make visible what changed, who decided, and which evidence authorizes the next step.

4. Building with AI is still engineering

A model can generate code, queries, interfaces, and configurations. The harness decides which tools exist, which credentials may be used, in which sandbox the action occurs, and which output may cross the boundary into a real environment.

The FDE must be able to change the product and also reject a shortcut. Local speed does not justify shared identity, secrets in context, unrestricted network access, or deployment without rollback. Customer proximity increases the consequence of a wrong action.

5. Evals and controls must represent the workflow

Generic benchmarks help select candidates. The production gate must use tasks, sanitized data, exceptions, and criteria from the real context. Organize evidence in layers:

1. deterministic contracts for schema, authorization, and invariants;
2. selective integration for tools, identity, and environment;
3. evals by task class, with graders and failure review;
4. abuse, unavailability, and recovery exercises;
5. identified human acceptance for consequential effects.

One pass without a version, case, verifier, and origin, it is not portable evidence. The receipt must allow reconstruction of what was requested, executed, observed, and accepted. [R3-C2]

6. Production is a boundary, not a ceremony

Before rollout, the system must declare identity, environments, cost and time limits, observability, support, interruption, and rollback. “Human in the loop” is not enough: the person must know when they participate, what information they receive, and which decision they can make.

The initial deployment must be limited by population, volume, or case class. Expansion depends on observed quality, adoption, and operation, not only on the absence of a visible incident.

7. Adoption also produces evidence

Usage is not an outcome. Measure whether people incorporated the solution into the workflow, whether quality remained acceptable, and whether cost per correct result improved. Record rejections, overrides, and parallel paths: they reveal where discovery or design was incomplete.

DORA treats AI as an amplifier of the existing sociotechnical system and associates user focus with better organizational performance. This does not prove causality for an implementation. It supports the discipline of not separating engineering from real feedback.

8. The case must improve the platform

Palantir describes forward deployment as a way to keep engineers close to problems and return learning to central engineering. Cohere adds an exit condition: build customer capability, not dependency on the FDE.

At the end of a cycle, classify what was learned:

• specific: a legitimate rule of that domain;
• configurable: variation that should become policy or a parameter;
• reusable: component, tool, or eval for other cases;
• structural: an architecture or roadmap change;
• disposable: experiment that should not survive.

Without this triage, every customer becomes a fork. With it, the next cycle starts with more capability and less improvisation.

The minimum forward-deployment receipt

mission: outcome + owner + baseline
spec: version + scope + acceptance
execution: identity + environment + tools + limits
verification: cases + graders + controls + result
release: approver + artifact + rollback
adoption: population + usage + quality + exceptions
learning: decision + reusable_asset + owner

This document does not need to contain sensitive data. It must contain enough references, hashes, and identifiers for an authorized person to reconstruct the decision.

Signals that the model is failing

• the same FDE must be present for every change;
• exceptions become custom code without a taxonomy;
• evals are demonstrations selected after the result;
• production uses more authority than the pilot;
• feedback arrives through conversations and does not change cases, specs, or the roadmap;
• the customer cannot operate or evaluate without the vendor;
• speed is measured to the demo, not to an accepted outcome.

Direct sources and limitations

1. OpenAI — Forward Deployed Engineer-seattle-seattle/).
2. OpenAI — Forward Deployed Software Engineer.
3. Anthropic and DXC — alliance and FDE training.
4. Palantir — Architecture Center.
5. Cohere — FDEs should build capability, not dependency.
6. DORA — State of AI-assisted Software Development 2025.
7. DORA — User-centric focus.

Corporate sources describe roles and methods declared by their authors; they do not prove universal outcomes or make FDE a standardized job title. The loop, spec, receipt, and failure signals are a FORGE technical synthesis, not a market standard.

Editorial and responsibility note

This article is informational. It does not replace architecture, security, privacy, employment, or hiring assessment. Trustyu and Tech Human operate commercially in AI architecture, governance, and engineering. Research, structure, and drafting had AI assistance; Fernando Parreiras is accountable for the thesis, factual review, and publication authorization. There was no additional independent human review.