The FDE Is a Delivery System—Not a Job Title

Two providers can introduce people called “forward deployed engineers” and still leave a buyer with different responsibilities. Teams with different titles can also perform similar field work.

The title is therefore a poor unit of comparison.

Current materials from OpenAI, Anthropic, and Google Cloud do not reveal complete organizations. They do show where each provider publicly places parts of the path from a promising use case to a production workflow.

I compare six responsibilities: qualification, workflow adaptation, production, adoption evidence, field-to-product learning, and partner coordination. This is an analytical taxonomy, not a claim that the three companies share one structure.

Six responsibilities, one deployment route

Qualification decides whether scarce field capacity belongs on the problem.

Workflow adaptation turns general capability into a specific sequence of users, data, decisions, exceptions, and systems.

Production carries the solution through integration, controls, reliability, and operating ownership.

Adoption evidence shows whether the workflow is used and whether something important changed.

Field-to-product learning converts deployment evidence into evaluations, product requirements, tools, or reusable patterns.

Partner coordination allocates work among the provider, customer, integrators, specialists, and long-term operators.

Every serious deployment needs these responsibilities somewhere. One organization need not own all six. The risk lives at the seams. A provider may produce a strong prototype while the customer assumes production hardening is included. A partner may complete an integration while no one owns adoption. A field team may collect useful feedback while the agreement does not define what can travel back to the product team.

The diligence task is to name each owner and the artifact that crosses each handoff.

OpenAI: a direct feedback loop

OpenAI’s current FDE role is explicit about the loop. It covers discovery and technical scoping, then system design, build, and production rollout. It also names production adoption, workflow impact, eval-driven feedback, codification of working patterns, and feedback to Product and Research.

The source fact is the published role description. The analysis is that direct field work can serve two purposes: change a customer workflow and sharpen the provider’s learning system.

That page does not establish FDE economics, capacity, or the complete organization. It gives the buyer a concrete question: what deployment evidence will be produced, and how will it reach the people who can change the product or model?

Anthropic: delivery plus portfolio operations

Anthropic’s FDE role covers production applications in customer systems, deployment support, adoption, pattern codification, and feedback to Product and Engineering. A second official role makes another layer visible: pre-sales program operations around the FDE function.

The program description says demand exceeds capacity and names qualification, prioritization, pursuit staffing, legal and finance coordination, partner routing, subcontracting or co-delivery, and pre-to-post-sale handoff.

The source-backed point is narrow: Anthropic publishes responsibilities around both embedded engineering and portfolio management. The economic interpretation is an inference. The pages disclose no utilization, pricing, margin, or capacity number. Still, finite specialist capacity creates opportunity cost, which makes qualification part of delivery design.

Google Cloud: leverage through partners

Google Cloud’s 2026 materials foreground ecosystem leverage. Its Cloud Next announcement describes FDE collaboration with major systems integrators. Its partner-ecosystem article describes Google engineers working with partners and an AI-native services program.

The source-backed claim is that direct engineering and partner enablement appear together in Google’s published model. My analysis is that partner capability functions as capacity and distribution architecture.

This is not evidence that listed partners deliver equivalent quality, that partner economics are attractive, or that Google delegates every production responsibility. It tells the buyer to ask where direct provider expertise ends, what the partner carries, how escalation works, and who operates the result.

Compare the missing owner

The three patterns can be summarized cautiously:

This table is analysis based on official pages checked on August 27, 2026. It is not a ranking or complete organizational description. A provider may use more than one model.

For the buyer, start with the missing responsibility. If the workflow is clear but integration capacity is thin, a specialist may fit. If the use case is novel and product learning matters, direct provider involvement may carry distinct value. If standard guidance and internal capability are sufficient, embedded engineering may be unnecessary.

Then build a one-page owner map:

• responsibility;
• accountable organization and named role;
• deliverable or evidence artifact;
• acceptance decision;
• handoff destination; and
• escalation path.

Treat the map as a handoff contract. The sending owner should provide the artifact and disclose unresolved assumptions. The receiving owner should accept the responsibility, name blocked dependencies, and know the next decision date. If either side cannot do that, the responsibility is still unowned—regardless of what the proposal or job title seemed to promise.

A useful test is to walk one foreseeable failure across the map. If production performance drops, who detects it, who decides whether the cause sits in the model, integration, data, or workflow, and who can authorize the remedy? If the answer changes depending on which person is in the room, the delivery system is not yet defined. The same test should be run for adoption failure and for the transfer at the end of the engagement.

The FDE label can be useful shorthand. It is not an operating model. Choose the delivery system that matches the missing responsibility, and make the whole route explicit before the work starts.