Forward-Deployed Engineering for Enterprise LLM Adoption

openai_/ramp/nominal/_dataland · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: enterprise LLM adoption and forward-deployed delivery

The panel examines why LLM companies use forward-deployed engineering teams to convert frontier model capability into enterprise production adoption, while balancing customer-specific work against scalable product, platform, and model improvements.

Constraints:

• enterprise workflows are heterogeneous and require deep customer context
• more capable models make harder customer problems feasible, increasing the need for domain translation rather than removing it
• custom enterprise work can derail product roadmaps if it is not kept generalizable
• FDE customers can become dependent on embedded engineers unless value transfers into product and process
• specialized domains such as semiconductors, life sciences, hardware testing, finance, and outsourced labor require domain experts to define tasks and evals

Architecture

The panel describes FDE as a customer-embedded operating system for enterprise AI: technical teams identify a production workflow, work directly with users and domain experts, build or adapt agents, data layers, evals, product features, and model-improvement loops, then feed the resulting lessons into core product, platform, or post-training. OpenAI uses FDE for adoption and model capability, Ramp uses it as an enterprise-roadmap shield, Nominal uses mission/domain teams to convert hardware workflow needs into platform features, and Dataland uses it to build heterogeneous customer agents.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  customer-workflow[Customer workflow]
  forward-deployed-engineer[Forward-deployed engineer]
  domain-expert[Domain expert]
  evaluation-task-set[Evaluation task set]
  customer-specific-agent[Customer-specific agent]
  core-product-platform[Core product platform]
  model-improvement-loop[Model improvement loop]
  customer-workflow --> forward-deployed-engineer
  customer-workflow --> domain-expert
  forward-deployed-engineer --> core-product-platform
  forward-deployed-engineer --> model-improvement-loop
  forward-deployed-engineer --> customer-workflow
  domain-expert --> evaluation-task-set
  domain-expert --> forward-deployed-engineer
  evaluation-task-set --> model-improvement-loop
  evaluation-task-set --> customer-specific-agent
  customer-specific-agent --> core-product-platform
  customer-specific-agent --> evaluation-task-set
  core-product-platform --> forward-deployed-engineer
  core-product-platform --> model-improvement-loop
  model-improvement-loop --> core-product-platform
  model-improvement-loop --> evaluation-task-set

Components

Data flow

A customer need enters through an embedded FDE or domain specialist who understands the workflow. The team maps that need to product/platform gaps, agent or model capabilities, eval tasks, and customer-specific constraints. The implementation may ship as code in the core product, a customer agent, a model/post-training improvement, or a reusable platform feature. Feedback from the deployment returns to product, research, or roadmap planning, while the FDE team tries to avoid permanent bespoke support.

Why this architecture

The panel argues that FDE became more important as models improved because teams can now tackle harder workflows, not because deployment became automatic. The architecture keeps humans close to customer context while using better coding agents, product platforms, evals, and post-training loops to convert field work into scalable adoption.

Models used: OpenAI models · Codex · OpenAI real-time voice model · agentic coding models · Ramp Excel agent · Dataland heterogeneous agents

Scale

• The panel cites roughly 10x growth in FDE roles over the prior year.
  “the number of FDE roles has increased 10x uh from where it was last uh last year.”transcript, stated
• OpenAI's real-time voice customer-service deployment reached about 70,000 calls per day.
  “six months later we shipped it and now it's like like something like 70,000 calls a day getting deflected by this like AI real time thing”transcript, stated
• OpenAI's telco deployment took about six months of iteration with post-training and FDE platform work.
  “that was like probably like you know 6 months of iteration with the post training team to improve the model and also building as FDEs like a bunch of useful platform”transcript, stated
• A Japanese sales-team slide assistant was built for about 2,000 sales users.
  “we were working with this this like this like Japanese sales team with like these 2000 sales guys and they wanted like this like slide buddy”transcript, stated
• Dataland reports multiple millions of ARR per headcount.
  “we we have multiple many millions of ARR per per per head per head count.”transcript, stated
• Ramp tries to have one FDE cover five or six customers when possible.
  “we try to serve a lot of customers at once. So, one FTE is taking on like five or six when when we can.”transcript, stated
• Ramp keeps individual customers to roughly a third, quarter, or sixth of an FDE to avoid dependency.
  “any given customer, they only ever had like a third of an FDE. And so if that goes to like a quarter or a sixth, they they they don't notice quite as much.”transcript, stated
• Nominal's first large contract wanted 40 people reviewing data every flight instead of two.
  “his goal was get 40 people in his organization looking at data every single flight on average before us it was two”transcript, stated

Alternatives considered (roads not taken)

sell a generic core platform to every enterprise customer

Rejected because: Dataland says its customers need heterogeneous agents tailored to their enterprise labor needs.

route enterprise needs through account managers, product managers, and engineers in a telephone chain

Rejected because: Ramp created FDE so engineers with customer and codebase context could solve problems directly without roadmap delays.

let enterprise deals derail the product roadmap with one-off custom features

Rejected because: Ramp uses FDE as a sword and shield: win enterprise deals while protecting core product teams and minimizing maintenance.

absorb every FDE-built product as a standalone offering

Rejected because: OpenAI increasingly asks whether the capability can become a Codex extension instead of another separate product.

expect generalist engineers alone to define specialized AI tasks

Rejected because: OpenAI added industry experts because harder problems require people who can write good tasks and evals in the target domain.

Patterns

forward-deployed-engineering (delivery-operating-model)

The companies use embedded technical teams to own customer outcomes, translate enterprise workflows into AI systems, and feed deployment learning back into product and model development.

tool-use-orchestration (agent-architecture)

FDE teams build customer-specific agents and workflows that connect models to domain tools, Excel, core products, and platform capabilities.

eval-driven-development (evaluation)

OpenAI frames FDE work as creating tasks, evals, and synthetic task analogs that both validate deployments and improve underlying models.

fine-tuning-adaptation (model-improvement)

Customer deployments feed model improvement and post-training, including the telco voice case and the slide-generation case.

human-in-the-loop-gate (domain-expertise)

FDEs and domain experts remain in the loop to understand workflows, define tasks, and protect customers from generic model or product assumptions.

Tradeoffs

Use FDE to balance enterprise revenue with product focus.

Chose engineers who win enterprise while protecting core roadmap over directly pushing every enterprise request into core product teams.

Rationale: Ramp's model keeps core teams focused while letting FDEs solve customer blockers and feed reusable insights into roadmap work.

Meet users in their native workflow.

Chose Excel-native or customer-environment agents over forcing finance teams and other users into new AI-native tools.

Rationale: Ramp's Excel agent reflects the FDE principle that adoption improves when the AI enters the customer's existing work surface.

Keep FDE changes minimal and roadmap-aligned.

Chose core-codebase work with minimal maintenance burden over large bespoke custom systems per customer.

Rationale: Ramp measures FDE ROI partly by avoiding maintenance-heavy custom work and accelerating features that help multiple customers.

Scale OpenAI FDE work through product or model improvement.

Chose productization and post-training loops over one-off customer delivery as the only scaling path.

Rationale: OpenAI frames FDE success as outcome first, then scaling either through reusable products or by making the model better at the task.

Use thin FDE allocation to prevent customer dependency.

Chose one FDE spread across several customers over large dedicated FDE teams per account.

Rationale: Ramp uses thin allocation to force attention toward what moves the business and reduce the risk that customers depend on a named person.

Gotchas (what bit them)

More capable models do not eliminate deployment work.

Root cause: Better models allow teams to attack harder, more specialized workflows, so the bottleneck shifts to domain understanding, task formulation, and eval design.

Resolution: Use FDEs and domain experts to embed with specialists and define the right tasks, evals, and product abstractions.

Enterprise custom work can derail the roadmap.

Root cause: Large customers request features that may only work for one customer, pulling core product teams away from broad product work.

Resolution: Use FDEs as a boundary layer that wins enterprise deals while keeping changes minimal and roadmap-informed.

Customers can become addicted to embedded FDE support.

Root cause: FDEs tend to have high empathy and ownership, which can make the person feel like the product if the value is not transferred.

Resolution: Thin the FDE allocation, make value engineering explicit, and ensure the product or workflow keeps delivering after FDEs pull back.

Telephone-chain product discovery loses technical context.

Root cause: Customer needs pass through account managers and product managers before reaching engineers, causing delays and missed solutions.

Resolution: Let engineers talk directly to customers while holding both customer context and codebase context.

Customer-specific builds can be useless if they do not match actual field workflows.

Root cause: Nominal's panelist describes prior platform work that field teams found unusable for customer engagements.

Resolution: Staff early FDEs with people who understand platform engineering and the customer workflow so bespoke work becomes generalizable architecture.

Evaluation

The panel evaluates FDE through customer adoption, ARR per headcount, enterprise revenue versus salary cost, production scale, product-roadmap impact, model-improvement feedback, and the ability to pull FDEs back without losing customer value.

Metrics: FDE role count up about 10x year over year · OpenAI voice customer service at about 70,000 calls per day after six months · Dataland at multiple millions of ARR per headcount · Ramp ROI as enterprise revenue divided by FDE salaries · Ramp target of five or six customers per FDE when possible · Nominal customer target of 40 people looking at data every flight versus two before

Outcomes

• OpenAI uses FDE both to drive broad enterprise adoption and to push model capability through customer-derived tasks and post-training loops.
• A telco real-time voice customer-service deployment reached about 70,000 calls a day after six months of iteration.
• Ramp's FDE model protects the roadmap while still helping win enterprise customers and inform core product work.
• Nominal turned a customer-specific data-transformation need into a generalizable containerized architecture sold across more customers.
• Dataland reports high leverage from heterogeneous customer agents, with multiple millions of ARR per headcount.

The panel frames FDE as a rapidly growing function: roles up 10x, OpenAI operating with both repeatable and frontier-problem tracks, Ramp spreading FDEs across five or six customers, and production examples ranging from 2,000 sales users to 70,000 daily calls.