OKFDE FIELD NOTES #002｜What Is a Forward Deployed Engineer, Really?
What FDEs own, how they work, and where the role overlaps with other engineering jobs.
OKFDE Research · October 2026
KEY TAKEAWAY
A Forward Deployed Engineer works with customers to turn an unclear business problem into software people can use in production. The role connects discovery, hands-on engineering, integration, and rollout, with responsibility for checking whether the workflow delivers its intended result. That requires support from customer teams and product engineers, along with clear limits on who can approve decisions. Lessons from the deployment should also improve the product.
A borrowed desk and a broken discount
Imagine an FDE named Leo sitting at a borrowed folding desk in a customer’s logistics office. His console is filling with timeout errors. Beside him, an operations manager opens the morning exception report.
“Your system calculated the volume discount incorrectly again.”
Leo has several places to look. The calculation could be wrong. The procurement database could be unavailable. The discount agreement might live in the spreadsheet someone keeps open across 17 tabs.
The operations manager would like the correct discount. A technically sophisticated explanation of the wrong one has limited appeal.
This is a useful starting point for understanding forward deployment. Leo needs to follow the failure across the workflow, find the people who understand it, and help get the fix into production. Some of that work will involve code. Some will involve discovering which spreadsheet contains the agreement everyone assumed was in the database.
The borrowed desk is optional. Access to those people is harder to do without.
01 / What the FDE takes on
An FDE engagement often starts with a request such as:
“Our purchase order approvals take too long. Can we automate them?”
That request leaves most engineering decisions unresolved. Where does the delay occur? Which orders need review? Who can approve an exception? What would count as a useful improvement?
In the procurement example, an engineer might discover that orders with discounts above 15% require Alex’s signature. Alex is away, and nobody has assigned a delegate. An approval-status endpoint would make the waiting easier to observe.
The FDE’s first job is to establish what the team can actually change. That means observing the workflow, examining its systems and data, and agreeing on a manageable scope with the customer.
From there, the work can include writing application code, building integrations, testing exceptions, and helping operators use the deployed system. Ownership continues through the point where people try to do their jobs with it. A merged pull request provides useful evidence about the software. Adoption and workflow performance require their own checks.
For Leo, fixing the discount calculation would involve more than seeing a passing test. He would need to check the result with the operations manager and understand what happens when the procurement database times out again.
Ownership needs authority and support
An FDE cannot personally approve every decision a deployment requires.
The customer still controls its business policies. Security teams approve access. Product engineers decide how shared platform capabilities should evolve. Legal and compliance teams retain their responsibilities.
The FDE keeps the work connected across those boundaries. When a blocker sits outside their authority, they find the person who can resolve it, explain its effect on delivery, and make the decision visible.
End-to-end ownership needs named collaborators. An engineer who is accountable for a result but cannot obtain access, secure a decision, or get product support has a staffing problem.
Calling that engineer “forward deployed” does not grant additional permissions.
02 / How the role overlaps with other jobs
FDEs share substantial ground with Solutions Engineers, implementation teams, consultants, and AI engineers. The boundaries depend on the company and the engagement.
A Solutions Engineer may write production-quality code. An implementation engineer may uncover the business problem everyone missed. A core AI engineer may work directly with customers for months.
The useful comparison is where each role usually concentrates its effort and how long it stays involved.
Several of these roles may belong in the same deployment team. The FDE helps preserve continuity as the problem moves between them.
That continuity matters because a handoff can be perfectly reasonable for both teams and still leave the customer stuck. The architecture supports the feature. The implementation is configured correctly. The operator still cannot complete the order.
Someone needs to follow that last fact.
03 / What working close to the customer changes
The first Field Note examined why enterprise workflows are difficult to automate. For the engineer doing the work, proximity changes how quickly an assumption can be checked.
A remote team sees an agent fail to retrieve procurement data. Sitting beside an operator, the FDE may discover that the application lacks access to the relevant database.
A CRM integration appears to work, but the sales team stopped updating the “Lead Stage” field six months ago. The field is available and beautifully typed. It also describes a business that no longer exists.
A five-step process in the executive deck turns out to involve nine manual reconciliation steps and two Slack messages that nobody logs.
These discoveries affect architecture and scope. They can change which data is usable, which actions need human review, and whether the proposed workflow is worth building.
Being on-site does not make context loss disappear. Operators disagree. Departments have different incentives. The person who understands the exception may be on leave.
Proximity makes investigation easier when engineers use it well. The work still requires checking explanations against records and observing what happens in practice.
An FDE also needs to keep asking whether the project remains useful. Three months of inference optimization cannot rescue a workflow attached to a division the customer plans to close.
That is an uncomfortable discovery. It is cheaper before the next three months.
04 / What a capable FDE needs
FDE job descriptions can resemble an entire engineering department compressed into one vacancy. Full-stack development, distributed systems, AI evaluation, enterprise integration, product judgment, and customer communication all make an appearance.
At OKFDE, we use six areas to think about the work. These are a way to assess coverage across an engineer or deployment team, rather than a universal scoring standard.
Engineering
Can the engineer build and debug the application that carries the workflow?
They need enough practical depth to investigate production failures and make changes that someone else can maintain. Framework familiarity helps. Following a request across several systems helps more when the request fails.
AI and data
Can they recognize model limitations, work with tool calling and retrieval, and evaluate behavior against the task?
They should also be able to distinguish a model failure from missing data or an integration fault. Prompt tuning is an expensive way to discover that a service account lacks read access.
Enterprise integration
Can they work through legacy interfaces, identity systems, and access restrictions?
This includes knowing when to involve infrastructure or security specialists. Private cloud environments and disconnected systems impose different constraints; the engineer needs to establish which constraints actually apply.
Product judgment
Can they turn a broad ambition into a useful, testable workflow?
“We want AI to revolutionize customer service” provides enthusiasm. It leaves scope fairly open. The FDE needs to identify which part of the work can be improved and what evidence would justify expanding it.
Business understanding
Can they explain why the workflow matters and recognize when a technical improvement has little operational value?
This requires learning the customer’s terminology, incentives, and economics well enough to ask useful questions.
Delivery and communication
Can they make dependencies visible, obtain decisions, and help people adopt the system?
A strong deployment team needs coverage across all six areas. Individual engineers will have different strengths.
An excellent model engineer with little integration experience may need an experienced partner for a private SAP deployment. The staffing decision should account for that gap before the customer discovers it during rollout.
05 / When the deployment becomes product work
Forward deployment creates a recurring temptation: solve the customer’s immediate problem with a local patch and move on.
A missing API gets a screen scraper. An exception becomes a conditional branch. A spreadsheet gets its own parser.
Each decision may be understandable. Together, they can produce software nobody wants to touch:
# procurement_override.py
# Temporary fix. Do not remove.
def procurement_override(order):
if finance_override_sheet.column_g_is_blank:
return “bypass”
return process_normally(order)
“Temporary” is doing a lot of work in that comment.
The first Field Note called the work of extracting shared capabilities from these deployments reverse productization. For the FDE, the practical question is what to bring back to the product team.
A useful review asks:
• Which part of the problem belongs specifically to this customer?
• Which integration pattern or failure is likely to recur?
• What evidence would help the product team evaluate a shared solution?
• Which local fixes need to remain supported while that decision is made?
Possible outputs include a hardened connector, a reusable workflow, or a regression test built from a production failure. Some lessons may inform domain models, circuit breakers, and other shared components.
Productization requires judgment. A customer-specific rule can remain customer-specific. A common failure deserves investigation even if only one deployment has exposed it so far.
There is also no reliable customer-number formula. Client 10 may reuse work from earlier deployments; Client 50 may introduce a constraint the team has never encountered. Reuse depends on what the team extracts and how well the product supports it.
The FDE contributes field evidence. Product engineering helps turn that evidence into maintainable capabilities.
06 / How the FDE knows when to hand over
An engagement needs an exit condition. Otherwise, the engineer can become a permanent dependency who happens to have an external email address.
A workflow running successfully once is an early milestone. Before handing it over, the team should be able to explain how it will continue operating.
The customer needs a named operational owner. Operators need to understand the workflow and its exception paths. The engineering team needs a way to detect failures, investigate them, and recover or fall back when necessary.
The deployment also needs evidence against the outcome agreed during scoping. If the goal was faster approvals, the team should check approval time alongside adoption and reliability.
Unresolved issues can remain, provided their owners and consequences are clear. Some require customer decisions. Others belong in the product backlog. Leaving them all in the FDE’s memory makes future support unnecessarily dependent on one person.
For Leo’s discount workflow, a reasonable handover would cover the calculation, database failures, and the process for changing discount rules. The operations manager should know what to do when an order needs review. The product team should receive the relevant integration lessons and test cases.
Leo can then leave the folding desk without becoming the undocumented fallback procedure.
Next / Field Notes · 003
From discovery to deployment: How an FDE engagement actually runs
A practical walkthrough of discovery, technical scoping, shadow-mode testing, production rollout, and handover inside an enterprise environment.
ABOUT OKFDE
OKFDE is a research, engineering, and talent platform focused on Forward Deployed Engineering for enterprise AI. We turn lessons from real-world deployments into practical methods for delivering, operating, and improving AI systems.
OKFDE
Train. Build. Deploy.
For enterprise deployment inquiries, workshops, or field research: