A roundtable discussion hosted by South Park Commons focused on the evolution and value of the Forward Deployed Engineer (FDE) role. Moderator Finn Meeks was joined by OpenAI's head of FDE Colin Jarvis, Ramp FDE team builder Calvin, Nominal CTO Jason, and Dataland co-founder Howard to explore how the role has been repositioned amid accelerating AI progress. The discussion noted that the FDE has evolved from an auxiliary role patching infrastructure gaps into a central hub that embeds AI capabilities deeply into complex industries, identifies high-value reusable problems, and translates customers' real workflows into product and model capabilities. Its essence is not outsourced services, but using technology as a lever to drive business outcomes, closing the full loop on-site at the customer—from problem discovery and task abstraction to system design and organizational alignment.
The four companies define the FDE through differentiated practices: Ramp defines the FDE as "unboundedly accountable for winning enterprise customers," allowing them to cross functional boundaries and participate in core roadmap development; Nominal sees the FDE as a probe on the product frontier whose mission is to "empower their mission," embedding deeply on-site to understand hardware engineers' real workflows and feeding insights back into the long-term product roadmap; Dataland, serving highly heterogeneous industries such as healthcare, energy, and manufacturing, treats the FDE as the business itself—every agent it builds must fit a specific labor scenario, and FDEs directly carry delivery responsibility; OpenAI gives FDEs a dual mission—both identifying repeatable, scalable problems and driving them into products, and tackling the hardest industry scenarios such as semiconductors and life sciences, working with the post-training team to customize model capabilities, becoming the "spearhead" of AGI commercialization.
Data shows the number of FDE positions has grown 10x year over year, a growth positively correlated with—not contrary to—increasing AI capability. Howard pointed out that AI has vastly expanded the space of B2B problems that software can solve, but in the real world enterprise labor spending far exceeds software budgets, and jobs and tasks are highly heterogeneous, so generic platforms alone cannot cover them. The key to unlocking this space lies in engineers with deep industry understanding—they must "know how to do the job itself"—and then align it with frontier AI platform capabilities. Colin confirmed that over the past year, FDEs' time spent on building underlying pipelines and evals systems has dropped significantly: early on, five sets of agents and corresponding evals had to be built repeatedly for a single customer; now strong coding models and long-horizon task capabilities allow 50% of foundational tasks to be handled by mature products like Codex, freeing FDEs to focus on higher-level business value such as chip physical design.
Jason emphasized that this trend has historical continuity—Palantir was already practicing forward deployed engineering back in 2012, and AI merely further ignited the expansion of problem scope brought by falling software production costs. Calvin explained that the core logic of Ramp FDEs is "serving customers where they are"—for example, building an Excel agent because customers work in Excel; its fundamental value lies in having code-literate engineers engage customers directly, replacing the inefficient relay chain of account manager–product manager–engineer, and preventing enterprise customers from dragging SaaS companies' product roadmaps off course.
On the boundary between FDE work and consulting outsourcing, the panelists agreed the criterion is "whether it accumulates into reusable assets." Jason cited Nominal's first major customer: the customer asked for a data preprocessing script to run on personal computers; rather than simply customizing, the FDE team designed a generalized architecture that could upload containers of data transformation logic, and after the first case validated it, the capability became a standard product feature; Colin explained that OpenAI's criterion has evolved into "can it be absorbed by the existing platform"—after Codex's capabilities improved, about 80% of originally planned standalone products were absorbed or canceled, keeping only a few directions with genuine independent justification, such as regulatory document writing and high-consistency workflow automation; Howard, from a startup perspective, proposed a financialized measure—focusing on "sustained value after fixed-cost investment"—as long as agents can take on enterprise workflows frequently and at scale and continuously generate value, it fits the essence of software economics.
ROI measurement varies by company: Ramp uses the simplest formula—enterprise revenue divided by FDE team salary cost—while also constraining each FDE to serve 5–6 customers and work directly in the core codebase to control maintenance burden; OpenAI focuses on high-value problems with "potential savings of hundreds of millions to billions of dollars per project," deploying a 15-person FDE team to transform the semiconductor value chain, but better ROI comes from replicable engagements that 2–4 people can complete; its long-term goal remains letting services revenue give way to product ARR and model capability improvements.
Guarding against the illusion of services revenue became a consensus. Jason warned that more dangerous is customer dependence on individual FDEs, leading to churn when the FDE leaves—so companies must ensure customers fall in love with the product, not the consultant; Howard stressed the need to continuously judge whether delivered value is sustainable and to reject demands that only produce momentary value; Colin described OpenAI's ideal end state as customers establishing self-improving loops that no longer need FDE involvement, with its flywheel mechanism being: FDE co-defines tasks with the customer → constructs high-quality training samples → hands them to the post-training team to optimize models → new model capabilities feed back to more customers.
Excellent FDEs must span multiple capability dimensions: technically, they must continuously track frontier models and handle uncertain behaviors; functionally, they combine account management and customer success attributes; cognitively, they must understand customers' organizational politics and navigate internal power games; and in terms of outcomes, they bear final responsibility for delivery results. Howard called it "the best training ground for future founders"; Jason emphasized that rotation between FDEs and core product engineers is crucial—when the former use the product on-site and report "it's too hard to use," refactoring is immediately driven, while the latter proactively fill roadmap gaps thanks to frontline experience; Calvin prefers former founders and early engineers, valuing their "want to say yes" rather than "instinctively say no" business-outcome orientation; Colin summarized the common trait as "outcome-focused"—not enamored with technical form, only obsessed with whether customers actually use it and get results.
Organizational mechanisms are designed to balance responsiveness and sustainability: Ramp deliberately dilutes FDE staffing so customers get only "a third of an FDE," avoiding lock-in; Dataland set up multi-account ownership from the start, clearly signaling "you're buying outcomes, not hours"; OpenAI initially had only a single FDE role, and as it scaled gradually introduced Echo-type customer relationship holders and vertical experts such as chip verification engineers to amplify the general FDE team's effectiveness. On the relationship between platform and FDE, Nominal believes the FDE is the best touchstone for testing platform authenticity—the Palantir-style path is to first build on the platform with FDEs, then transition to customer self-service building; Ramp insists platform-first, with FDEs achieving the platform's set goals under customer constraints, and feeding high-frequency adoption blockers back to drive platform feature internalization.
Disclaimer: This article was automatically generated by an open intelligent model and is for reference only.