Forward-deployed engineering (FDE) is a delivery model in which engineers work directly with the people who own the mission workflow, target environment, security boundary, evaluation process, and ongoing operation. The aim is not merely to install software. It is to reduce the time between discovering a real constraint, changing the system, testing that change, and making the next decision.
That proximity matters inair-gapped agentic AI implementation. An isolated environment removes many assumptions common to public-cloud development. Dependencies, models, observability, identity, updates, and test assets all need deliberate paths inside the boundary. FDE brings those decisions into one working delivery loop without moving protected information into an inappropriate channel.
What does a forward-deployed engineer actually do?
A forward-deployed engineer turns operational context into working, testable changes. The role can include architecture, deployment automation, inference integration, agent and tool development, evaluation harnesses, troubleshooting, technical documentation, and knowledge transfer. The exact work should follow the program's central uncertainty rather than a fixed catalog of features.
The Department of Defense'sSoftware Acquisition Strategy guidanceemphasizes frequent, iterative delivery and early involvement from users, testers, security, developers, and other stakeholders. FDE is one practical way to support that working cadence. It does not replace the acquisition strategy, product owner, test authority, security authority, or operational chain of responsibility.
Why is technical proximity more useful than on-site presence alone?
Being physically present is not the value by itself. The value is a shorter, higher-fidelity feedback loop. An engineer who can observe an approved workflow, reproduce a failure, understand the platform constraint, and speak with the responsible stakeholder can make a more relevant technical change than a remote team working from a generalized requirement.
Proximity may be on site, remote within an approved environment, or a combination. The working arrangement should match the information boundary and task. Sensitive details stay in authorized systems and conversations. Unclassified repositories and support channels should contain only material cleared for those channels.
What should the FDE delivery loop produce?
Each loop should produce evidence and a decision, not only code. The team frames the question, identifies the constraints, makes the smallest useful change, evaluates it, and records what the result does and does not establish. The next loop then follows the highest-value remaining uncertainty.
CDAO's publicAI test and evaluation frameworksdistinguish model, human-systems integration, systems integration, and operational evaluation. That separation is important for FDE. A model result may justify another test, but it does not establish that the integrated capability is usable, supportable, or operationally effective.
| Loop | Core question | Useful outputs |
|---|---|---|
| Frame | What mission or technical decision must this work support? | Decision statement, owner, constraints, assumptions, and measures |
| Observe | What does the real workflow and environment require? | Interface map, dependency findings, information boundaries, and risk notes |
| Implement | What is the smallest change that can reduce the uncertainty? | Configuration, code, deployment automation, and recorded versions |
| Evaluate | What happened under representative and failure cases? | Test cases, results, limitations, defects, and a decision recommendation |
| Transfer | Can the responsible team understand, operate, and change the result? | Runbooks, architecture records, training, backlog, and ownership handoff |
How should FDE work with platform, security, and test teams?
FDE should make responsibilities clearer, not blur them. The platform team owns approved infrastructure and shared services. Security and authorizing stakeholders determine applicable controls and evidence. Test organizations establish or oversee appropriate evaluation. Mission owners decide whether the result is useful. The engineer connects these decisions to the implementation and surfaces conflicts early.
Joint NSA and CISA guidance ondefending continuous integration and continuous delivery environmentstreats the delivery pipeline as part of the software supply chain that requires its own protections. In an air gap, the same principle extends to controlled import, provenance, testing, approval, and rollback. The companion guide on theair-gapped AI model update lifecycledescribes that operating path in more detail.
What deliverables should remain after the engineer leaves?
A successful engagement should leave more than a demonstration. The organization needs a reproducible system, decision evidence, known limitations, and a practical support path. The exact artifacts depend on scope, but several categories are consistently useful.
- Architecture records: components, trust boundaries, interfaces, data flows, dependencies, and deployment assumptions.
- Repeatable delivery: approved configuration, automation, version records, verification steps, and rollback procedures.
- Evaluation evidence: representative cases, results, failure analysis, known limits, and decision gates.
- Operating material: runbooks, monitoring expectations, escalation paths, maintenance backlog, and update procedures.
- Knowledge transfer: working sessions and documentation that let customer personnel diagnose and change the capability.
Those outputs also reveal whether the underlying platform supports customer ownership. The guide toevaluating an open-source agent platform for an air gapprovides criteria for portability, offline operation, permissions, auditability, and maintainability before implementation commits to a foundation.
For teams building on Decision Terrain, thecustomer-led and DT-supported implementation pathsmake that ownership explicit. Your team can use the platform’s documentation and interfaces to develop integrations, with optional forward-deployed engineers for initial consulting or implementation. Scope the documentation and knowledge transfer around the people who will maintain the solution.
Where do responsible AI and continuous monitoring enter the work?
They enter from the first loop. The CDAOResponsible AI programdescribes risk identification and mitigation across the product development lifecycle. Its public testing guidance also calls for continuous monitoring, validation, and verification during integration and operation. An FDE team should therefore connect requirements, evaluation, instrumentation, human oversight, and change control rather than postpone them until a final deployment review.
The program still determines which policies, controls, and authorities apply. An engineer can implement logging, test harnesses, approval gates, and technical safeguards. The engineer cannot self-authorize the system or convert an engineering artifact into official approval.
When is forward-deployed engineering the wrong starting point?
FDE is a poor starting point when the team cannot identify a mission decision, a responsible owner, an approved working boundary, or a credible path to evaluate the result. In that situation, discovery, governance, or readiness work should come first. Starting delivery too early can produce activity without an interpretable outcome.
It is also the wrong model when the organization wants to outsource permanent ownership. FDE should accelerate customer capability and clarify sustainment, not create an undocumented dependency on one engineer. The broaderair-gapped agentic AI architecture guidecan help teams identify the ownership and boundary questions before implementation begins.
How should a first FDE scope be bounded?
Start with one decision, one representative workflow, and the smallest credible technical slice. Define the target environment, approved test information, responsible stakeholders, expected artifacts, measures, failure conditions, and the decision that follows the work. A narrow scope makes technical and organizational assumptions visible while change is still affordable.
If major uncertainties remain, use theAI Prototype Test-Plan Builderto structure the question before implementation. The result should be a learning loop with an exit condition, not an open-ended promise to make an undefined AI capability operational.
Frequently asked questions
Does forward-deployed engineering require full-time on-site work?
No. The delivery arrangement should match the environment, information boundary, and task. Some work may require approved on-site access; other architecture, automation, documentation, or unclassified coordination may be performed remotely through authorized channels.
Is an FDE the system owner or authorizing official?
No. The engineer implements and explains technical work. Program, mission, platform, security, test, and authorizing stakeholders retain their respective decisions and accountability.
Can FDE support a customer-selected inference stack?
Yes, when the selected inference layer can operate within the target boundary and meet the required interfaces and constraints. The work should preserve documented dependencies and avoid quietly introducing a public-cloud requirement.
What is the clearest sign that an FDE engagement worked?
The customer has better evidence, a repeatable implementation, known limitations, and the knowledge and artifacts needed to operate or change the capability without relying on undocumented individual expertise.