The solution belongs to the organization.
It is handed over to the business owner in the fourth week of the Proof stage; the handover happens whatever the organization decides next.
EAT OfficeThe engineer who ships outcomes, not demos
A Forward Deployed Engineer learns the real business problem and working environment, and brings the AI solution into operation by combining it with the organization’s data, systems, security limits and how users actually work.
Success is judged not by the code written, but by whether the system runs reliably, gets adopted and produces a measured business outcome.
DiscoveryEngineeringDeploymentMeasured impact
Business Technologist knows the work and owns the solution.
Explore the role →
Forward Deployed Engineer embeds the solution in the organization’s real-world environment and hands it over.
Why now?
AI has made prototypes easy. It has not made running them in the real world easy.
An impressive demo can be built on a model API in a few hours. Enterprise value appears only when the solution is connected to real data, existing systems, user behavior, security rules and a business outcome. The hard questions in that transition go beyond a list of components:
- Has the real problem been defined correctly?
- Which context and sources will the model work with?
- Which systems will it access, and with what permissions?
- When will it act on its own, and when will it hand off to a person?
- How will its success be evaluated on real cases?
- When something goes wrong, how will it be traced and rolled back?
- Will users actually use the system in their daily work?
- Which business indicator will the technical output change?
The engineering approach that answers these questions in the real working environment is Forward Deployed Engineering.
From independent research
- 95%Share of generative AI pilots that produce no measurable profit-and-loss impact
- 10×Growth in Forward Deployed Engineer job postings in one year, 2025
MIT NANDA, The GenAI Divide · 2025. The successful minority work with teams that adapt the solution deeply to the workflow.
Financial Times / Live Data Technologies · 2025.
A working demo shows technical possibility. A system in use shows organizational capacity.
Origin and meaning
Going to where the work is, instead of waiting for requirements
The role was born in a gap: the organization could not fully say what it needed, the consultant could not write code, and the product engineer did not go into the field. The name comes from the military idea of forward deployment: the engineer is not at headquarters but where the work is done. The AI era brought the role back into focus, because while the model works well, the organization's data is scattered, its systems are old and its workflows are unwritten. Solutions rarely fail outright; they stall in the last mile.
Forward deployment means the solution team moves toward the problem, the user and the working environment instead of waiting for requirements from a distance. The aim is not to force a generic product onto the organization, but to learn the real context and run the solution within the organization's data, processes, security limits and user behavior. What is learned in the field flows back into the architecture, the evaluation model and reusable engineering knowledge.
- Receiving requirementsDiscovering the problem together
- Implementing a technical scopeShaping scope around the business outcome
- A working featureA reliable workflow
- A delivery dateReal use
- HandoverTransfer of responsibility and operations
- Project closeA cycle of measurement, learning and improvement
The EnterpriseAIX view
Not a product being deployed, but the organization’s own Lighthouse Application
In the industry, this role usually deploys a software company’s product at a customer. At EnterpriseAIX, what is deployed is not a product but the organization’s own Lighthouse Application. That changes three things.
Learning flows into the method, not a product.
Patterns that repeat in the field accumulate not in a product but in the organization’s working model, in the Embed stage.
The role multiplies inside the organization.
At first the capability sits with the EnterpriseAIX team; working side by side, it passes to the organization’s technical team. The aim is to hand over, not to stay.
A Forward Deployed Engineer does not code the requirement they are handed.They learn the business context, shape the technical decision and stay with the system until a real outcome emerges.
Who they are, and are not
Not the old delivery model repackaged under a new title
A Forward Deployed Engineer is an engineer who understands an ambiguous business problem together with real users and domain teams, integrates the solution with the organization's data and systems, builds the evaluation and security layers, rolls it out in a controlled way and owns the system's technical outcome.
| Role | What it does | How the Forward Deployed Engineer differs |
|---|---|---|
| Solutions architect / sales engineer | Builds demos and examples before the sale. | Works after the sale, in real use, on the organization’s infrastructure. |
| Traditional consultant | Gives recommendations, measured on deliverables. | Builds, is measured on outcomes and has the authority to change the solution. |
| Support engineer | Keeps the existing system running. | Builds the solution that does not yet exist, and hands it over. |
| Integrator / outsourcer | Integrates from outside; bills hours. | Embedded in the work, alongside the business owner and users. |
| Prototype engineer | Prepares a demo. | Starts the real work where the prototype ends. |
What they are
Seven facets of the role
- An engineer who gives structure to an ambiguous problem
- A partner who carries domain and user context into technical decisions
- A decision-maker who makes deliberate trade-offs between speed, scope, quality and risk
- A systems engineer who designs the whole way of working (the AI Harness), not just the model
- A practitioner who treats evaluation, security, observability and rollback as part of the solution
- An outcome owner who counts usage and business impact as measures of technical success
- A builder who turns field learning into method and reusable components
Why the traditional delivery chain is not enough
The more handoffs, the thinner the context.
Business analysis, product management, experience design, architecture, development, testing and operations remain valuable. The problem is the context lost in long chains where each responsibility is handed to another team. As the problem in the business unit's mind becomes a requirements document, the document becomes a backlog and the backlog becomes technical components, the original intent thins out. The system is technically complete; it does not solve the real problem, or no one uses it.
As development cycles speed up in the AI era, that handoff cost becomes more visible. The Forward Deployed Engineer does not remove specialties; they take on broader technical ownership, from discovery to real outcome.
- Taking the requestDiscovering the real problem
- Implementing the requirementBuilding shared context
- Completing the taskOwning the outcome
- A working demoA reliable system people use
- Project deliveryDeployment, adoption and value
- A single technical specialtyBroad engineering and field judgment
How do they work?
The cycle from problem to real use
Eight steps, each with an output. The status list on the right marks the step you are reading: for a Forward Deployed Engineer, “done” means handed over.
- 01
Discovery
Learns the real context of the problem with the business owner, Business Technologist, users and technical teams; separates the request from the root cause.
Output · Problem brief, target user, scope, success measure
- 02
Technical scoping
Assesses data, systems, integration, model behavior, security and operating conditions; separates what can be done from what is worth doing.
Output · Feasibility, alternatives, trade-offs, decision record
- 03
Harness and system design
Designs the model, context, data, tools, execution loop, state, permissions, human approval and human handoff together.
Output · Harness brief and technical architecture
- 04
Prototype and user testing
Builds a working example that quickly tests the most critical assumptions; learns from real user behavior.
Output · Prototype, feedback, updated scope
- 05
Evaluation and security
Builds test sets from real cases; measures accuracy, reliability, security, performance and failure modes.
Output · Evaluation results, acceptance thresholds, risk controls
- 06
Integration and deployment
Connects the solution to real data and systems; prepares controlled rollout, monitoring, rollback and a runbook.
Output · A secure, observable system in operation
- 07
Adoption and measurement
Helps the system become part of users' daily work; tracks usage together with technical performance and business indicators.
Output · Adoption and measured business impact
- 08
Handover and codification
Transfers technical operations, decisions and learned patterns to the organization; produces reusable components and standards.
Output · Technical capacity that stays in the organization; a faster next application
An example
From “it works” to “it works safely”
Management’s first request
“Let’s build an AI agent that answers customer support requests. The prototype already answers most questions fluently.”
The demo looks successful. For a Forward Deployed Engineer, the real work has only just begun.
The questions they ask
- Which organizational sources is the answer based on?
- What happens if an outdated policy is used?
- How are customer identity and permissions verified?
- Where does it only read, and where can it act?
- When are critical cases such as refunds, payments or legal disputes handed off to a person?
- How is quality measured across languages and in ambiguous requests?
- How is a wrong action stopped and rolled back?
- Why and how will support reps adopt the system?
- Is success measured by resolution rate alone, or together with satisfaction and risk?
The harness that gets built
- Current, permitted knowledge sources
- Customer context and access rules
- Limited tool permissions
- Human approval for critical operations
- Handoff and escalation paths
- An evaluation set from real support cases
- Monitoring, audit log and rollback
- Measurement of usage, quality, cost and customer impact
What got built was not a chatbot. It was a system that reliably runs a defined part of customer service and keeps learning.
Capabilities
Strong engineering, field judgment and outcome ownership come together in one profile.
Engineering foundations
Programming, data structures, APIs, databases, testing, debugging, version control, system design.
AI application engineering
Model APIs, structured output, retrieval-augmented generation (RAG), tool use, agent and workflow design; how model behavior shapes the experience.
Context and harness engineering
Designing instructions, context, tools, execution loop, state, memory, permissions and human control as one way of working.
Data and integration
Enterprise data sources, data quality, identity and access, API and event integration, the reality of legacy systems.
System design and engineering judgment
Architectural decisions under uncertainty; trade-offs between scope, speed, cost, reliability and sustainability.
Evaluation, security and reliability
Task-specific evaluation, adversarial testing, privacy, error handling, guardrails, quality gates.
Deployment and observability
Continuous delivery, environment management, monitoring, logging, tracing, controlled rollout, rollback, runbooks.
Field discovery and communication
Discovery with users and domain teams, explaining complex technical decisions, surfacing risk early, keeping teams on a shared outcome.
A good Forward Deployed Engineer can get inside the code and inside the place where the problem lives.
Working with the Business Technologist
The same application, different areas of leadership
The two roles are not alternatives to each other; they combine their strengths on the same business outcome.
Business Technologist leads
- Domain and user discovery
- Problem and process
- Value hypothesis and indicators
- User experience
- Adoption and stakeholders
- Ownership of the business outcome
Shared ownership
- Discovery
- Solution and harness design
- Risk and evaluation
- Pilot design
- Division of work between people and AI
- Handover and learning
Forward Deployed Engineer leads
- Technical feasibility and architecture
- Data and integration
- Application development
- Security and permissions
- Deployment and rollback
- Observability and reliability
The Business Technologist owns what should be transformed, why, and for which business outcome.The Forward Deployed Engineer turns that transformation into a working, reliable technical system.
An application team is not just two people. Depending on risk and complexity, a domain mentor, an experience designer, and data, security, legal or governance representatives join the team.
The role across the Transformation System
Where the role sits across the five stages
- 01
The Briefing stage
The role does not yet appear in this stage.
- 02
The Diagnostic stage
The role does not yet appear in this stage.
- 03
The Proof stage
Builds the Lighthouse Application in the real work of real users; measures it in the fourth week and hands it over to the business owner.
Go to the stage → - 04
The Embed stage
Builds the second application in the EAT Office cadence, together with the organization’s technical team; the way of working is written down.
Go to the stage → - 05
The Scale stage
The organization’s teams build the applications; EnterpriseAIX stays on the team and safeguards adherence to the method and security limits.
Go to the stage →
A Forward Deployed Engineer does more than put one system into production. They leave behind the capacity for the organization to build the next one faster and more reliably.
How is it measured?
Not when the code is complete, but when the outcome is proven
Three headline measures: the days to a first working example on real data; the application handed over to its business owner in the fourth week, with maintenance that can stay in the organization; and at least one way of working from the application written into the organization’s model in the Embed stage.
Where does it break?
Known failure modes in the industry, and the countermeasures
- It works, but it cannot be handed over.Handover is a step in the fourth week, not something added later.
- A solution that only works in the demo.No build starts without evaluation criteria based on the organization’s own data.
- Scope creep.The scope is written in the Lighthouse Application Decision; changes are decided in the EAT Office.
- A broken loop between field and method.At least one pattern from every application is written into the organization’s method in the Embed stage.
- Dependence on an outside team.The role is shared with the organization’s technical team from day one and moves to oversight in the Scale stage.
- Leaving evaluation and security to the end.Both are built in from the start, not added as a final check.
Who is this path for?
For people who can write code, and want to own the real outcome
- Software and full-stack engineers
- AI and machine learning application engineers
- Data and platform engineers
- Solutions architects
- DevOps, SRE and cloud engineers
- Integration and application specialists
- Technical product and customer engineering teams
- Students and recent graduates building engineering foundations
- Do you enjoy giving structure to an ambiguous problem?
- Do you want to work directly with users and domain teams?
- Are you curious about how a technical decision affects the business outcome?
- After the prototype, do you want to own evaluation, security and real use?
- Can you make trade-offs between speed, scope, quality and risk?
- Do you care about communication, documentation and knowledge transfer as much as code?
An honest note for recent graduates
At most advanced technology companies, Forward Deployed Engineer is a senior role that requires experience with real production use. It is not a title earned at the end of a short course. For a recent graduate, the right goal is a proven path toward this way of thinking and working: solid engineering foundations, a real problem, delivery experience, operating discipline and growing responsibility.
Development path
A path you advance by proof in real use, not by title
Six levels; each one is earned with evidence. Inside the organization, on real work.
- 0
Foundation
How AI works, safe use, critical evaluation, systems thinking and human responsibility.
EvidenceA small, explainable human–AI workflow draft.
- 1
Engineering foundations
An explainable product built with programming, version control, data, SQL, HTTP/APIs, testing, debugging and system design.
EvidenceA tested, documented working application.
- 2
Building AI applications
Controlled use of model APIs, structured output, retrieval, tool use, agent and workflow approaches.
EvidenceAn AI application with evaluation criteria.
- 3
Harness and systems engineering
Designing context, tools, execution loop, state, permissions, human control, reliability, evaluation and observability together.
EvidenceA harness with defined security and operating limits.
- 4
Delivery responsibility
Discovery with the Business Technologist and domain expert; responsibility for feasibility, architecture, prototype, testing, risk and pilot.
EvidenceA contribution validated by the team and a reviewer.
- 5
Proven deployment
A solution connected to real data and systems, tested, secure, observable, reversible and handed over to users.
EvidenceReal use, technical reliability, adoption and measured business impact.
This capability is proven not by a coding test, but by a system that works within the complexity of the real world.
Why does the organization need this capacity?
The value of AI investment lies not in model access, but in real use.
Most organizations can now access models and tools. The difference comes not from access but from how fast these capabilities are connected reliably to real workflows.
Without this capacity
- Prototypes never reach real use.
- Context is lost between the technical team and the business unit.
- Evaluation and security are added late.
- Adoption is left until after the project.
- Technical success and business value drift apart.
- Every application starts from zero.
Where this approach takes hold
- Discovery and engineering move forward in the same application.
- Risks and integration issues surface early.
- Production standards apply from the prototype onward.
- Usage and business impact count as technical success.
- Field learning becomes reusable components.
- The organization builds each new harness more deliberately and faster.
Next steps
The engineer of the future will not only build technology. They will make it work in the real world.
Becoming a Forward Deployed Engineer is not about knowing more tools. It is about leaning into ambiguity, learning the domain, developing technical judgment and taking responsibility for outcomes in real use.
Models will change and frameworks will come and go. Understanding the real problem, building reliable systems, making the right trade-offs and owning the outcome will last.
For you
Build your engineering foundations. Deliver on real applications. Prove it in real use.
For your organization
Put Forward Deployed Engineers on your Lighthouse Application; build lasting delivery capability in-house.
SourcesWikipedia, Forward deployed engineer · a16z, “Trading Margin for Moat” (2025) · The Pragmatic Engineer, “Forward Deployed Engineers” · roadmap.sh · ACM Agile (in Turkish) · MIT NANDA, The GenAI Divide (2025) · OpenAI and Anthropic role descriptions