What is an FDE team, and how do you choose one?

What the name usually points to

FDE refers to a forward-deployed engineer; an FDE team provides forward-deployed engineering. In examples published by OpenAI, forward-deployed engineers work alongside customer teams on discovery, technical scope, system design, building and production rollout. AWS describes forward deployment as an embedded team working with a customer through a full AI implementation. Those descriptions show an approach: engineers work close to the customer and the live problem instead of only handing over remote advice.

FDE is not a credential or a uniform service package. One provider may send engineers to extend its own platform; another may build a custom integration across your systems. The people, access, location, duration, deliverables and support after launch can all differ. Ask what the proposed team will do in your environment before assuming that the label promises a particular outcome.

Source: OpenAI: Forward Deployed Engineer role

Source: AWS: Generative AI Innovation Center

When an embedded team can help

This model is worth considering when a useful AI workflow depends on details that are hard to capture in a brief: several systems must be connected, permissions and exceptions matter, or the right design becomes clear only through repeated work with your staff. A team that can observe the workflow, make changes and test them with users may find problems a detached specification misses. OpenAI describes its FDE role as moving deployments from prototype to stable production while working with customer engineering and domain teams. That is a provider's own role description, not proof that every FDE engagement reaches production.

For an SMB, proximity does not have to mean someone sitting in your office every day. It means direct access to the responsible staff, prompt answers about the workflow, an agreed way to test changes and clear responsibility for decisions. Ask how much of the proposed work is on site or remote, who must be available from your side and whether the model fits your operating hours and service coverage. A provider's headquarters tells you little about where it can actually support your business.

Source: OpenAI: Forward Deployed Engineer role

When you may not need an FDE team

An embedded build can be excessive when your need is still to choose a problem, when an existing product already covers a straightforward task, or when a small configuration change would suffice. If you cannot supply a workflow owner, usable examples or access to the systems involved, an embedded team may spend its time waiting. A short advisory project, an implementation partner for one integration, a managed product or a manual process may be a better first step.

NIST's voluntary AI framework calls for defining the intended use and business value and considering whether an AI solution is appropriate. Apply that as a decision prompt, not as a rule that every business must buy a particular service. Ask a candidate, 'What would make you recommend that we do not hire an FDE team for this task?' A specific answer helps you see whether the proposed delivery model follows your need or the provider's preferred package.

Source: NIST: AI Risk Management Framework Core

Questions that reveal the actual engagement

Start with the team: Which people will do discovery, write code, test with users and own production support? Will they build primarily on their employer's product, your existing tools or a mix? How will they work with your staff each week? Ask for a relevant example that separates the provider's contribution from what the client already had. A job title alone does not establish experience with your systems or industry.

Next, define a bounded first outcome. Which workflow and exceptions are included? What access and data are required? Who approves actions with customer, financial or other sensitive effects? What test cases and measures will decide whether to proceed? NIST recommends testing AI systems before deployment and regularly in operation; the exact acceptance checks for your contract should reflect your own context and risk. Do not let a polished prototype silently become the definition of success.

Finally, ask what the team leaves behind: code or configured product, integration documentation, test cases, operating instructions and a named owner. Agree who holds accounts and permissions, how access is removed, what support covers and how your staff can continue or switch providers. If the solution depends on a vendor platform, identify which parts can be exported and which cannot. Record these points in the scope rather than relying on a verbal description of an 'embedded partnership.'

Source: NIST: AI Risk Management Framework Core

A practical selection rule

Invite each candidate to explain one realistic path from your current workflow to a limited live use, including its dependencies and a stop condition. Prefer the team that can name the work it will do, the decisions you must make, the evidence it will collect and the handoff you will receive. If a simpler provider or product can deliver the same bounded outcome with less organizational effort, choose that route. The purpose of hiring an FDE team is useful delivery in your setting, not acquiring the title.