/writing · thoughts
What a Forward Deployed Engineer Actually Does in 2026
· 8 min read
The term "forward deployed engineer" has gone from niche Palantir jargon to one of the fastest-growing job titles in tech. According to Indeed data shared with Business Insider, US postings for the title stood at 643 in April 2025 and 5,330 in April 2026 on an index where January 2025 is 100, a 729% year-over-year increase. In India, TeamLease Digital's data cited through Inc42 puts the growth at roughly 800% over the same period.
Growth like that always brings title inflation. Some of what gets posted as "FDE" right now is the role described here. Some of it is sales engineering or professional services with a shinier label. This post tries to sort one from the other, and to say plainly where I stand, since I'm going after this role myself.
Where the role came from
It started at Palantir. In the early 2010s, Palantir built a horizontal data platform (Gotham, then Foundry) and found out fast that "general-purpose" does not mean "self-deploying." Every enterprise customer had its own data formats, its own legacy systems, its own politics about what counted as a source of truth. So Palantir put engineers inside customer organizations and told them to write production code, not stop at advising on architecture.
Inside Palantir these people were "Deltas," as opposed to "Devs," who built capabilities meant for all customers. A Delta enabled many capabilities for one customer. A Dev built one capability that could eventually reach many customers. FDEs fed the friction they hit in the field back to the Devs. That loop was the whole point.
By 2016, Palantir had more FDEs than software engineers. That ratio probably doesn't suit every company, but it shows how central the role was to how they ran.
Around 2024 the term spread to AI labs and AI-native startups. OpenAI built its FDE team to help enterprise clients use the technology on specific business problems. Anthropic's equivalent posting asks outright for people who can ship MCP servers, sub-agents, and agent skills as production artifacts. Google Cloud's 2026 FDE postings describe the job as bridging "frontier AI products and production-grade reality," and list multi-agent systems and MCP servers as requirements.
The four variants
"FDE" in 2026 covers a family of roles, not one job. Four variants keep showing up across research and job postings:
Deployment-heavy (Palantir, Scale AI, Databricks): the original model. Embedded with a customer, often on-site, building custom integrations and production workflows on top of a platform. Heavy travel. The work is operational, not advisory.
Product-feedback (OpenAI, Cohere, Anthropic's closest equivalent): the field-to-product loop is the stated job. You deploy frontier models for strategic customers, then feed eval results and failure modes back to research and product teams. OpenAI's posting puts it plainly: "Share field feedback that helps Research and Product understand where the models succeed and where they can improve."
Startup founding-FDE (Glean, Warp, Harvey): the first or an early deployment hire, owning discovery, scoping, building, and sometimes account management all at once. Warp's Founding FDE posting says the person will turn pilots into production, report directly to leadership, and define success criteria from scratch. This one owns the most and carries the most founder-like risk.
AI-lab FDE (Google Cloud, Salesforce Agentforce, Databricks AI FDE): inside larger platform companies that have shipped AI-native product lines. Google's 2026 FDE posting asks for "agentic workflows incorporating MCP, tool-calling, and OAuth-based authentication." The technical bar here is the highest of the four.
FDE vs the roles it gets confused with
The clearest line, per several 2026 job guides: a real FDE writes production code inside the customer's environment. A solutions engineer sells; an implementation consultant configures; a customer success manager manages the relationship. Only the FDE writes code that runs on the client's infrastructure and then generalizes that code back into the product.
The coding share is real. Several 2026 job descriptions and first-person accounts (including Rippling FDE Kanav Bhatnagar's public account) say outright that the role is not advisory work. The customer time is real too, and it doesn't spread evenly across the week: during a launch window you can get two days of almost pure code, then a full day of customer calls.
What surprised me across the research: the product feedback and playbook work (the 15%) is what most clearly separates a good FDE from a great one. You take what a messy customer deployment taught you and turn it into a reusable pattern, a new eval metric, or a documented failure mode that makes the product better for everyone. Palantir built the role around that loop, and AI labs are now trying to copy it.
The market in 2026
The growth numbers hold up across several sources. 729% year-over-year in US postings (Indeed data, via Business Insider). Roughly 800% in India (TeamLease Digital, via Inc42).
Not all of that growth means the products are maturing. A lot of it shows how hard enterprise AI deployment is in practice. Companies still struggle to make AI useful inside their own walls. That is why strong FDEs are worth a lot, and also why the title has split into real engineering roles and lower-prestige services roles wearing the same label.
In India, as of mid-2026, a range of companies were hiring for FDE and adjacent AI deployment roles: Sarvam AI (Bengaluru, two seniority levels), Cartesia (India, Founding FDE title), Google Cloud Applied AI (Bengaluru, multiple levels), Adobe (Bangalore, 2-5yr), Salesforce Agentforce (multiple India cities), Resilinc (India remote), HackerRank (Bengaluru hybrid), Databricks AI FDE (remote India), and several YC-backed startups including Peakflo, Deductive AI, and Mem0. Pay in India splits sharply: entry-level or IT-services-adjacent roles tend to run ₹10-20L; AI-startup mid-level roles run ₹25-50L; one outlier (FuturePath AI) listed ₹35-50L for a senior profile.
Where I sit
Here is how my background maps to this role: the parts that are strong, and the one real gap.
The technical side fits. I built CAG Deep Research, a multi-agent LangGraph research system with hexagonal architecture, verification loops, swappable search providers (DuckDuckGo, Tavily, Exa), and report generation, in 10 days from a vague problem statement. The 10 days were a real deadline, not a storytelling device, and the system runs on actual hardware with real limits on retrieval quality. I also shipped WebMCP integration into this portfolio: it registers 7 tools through the proposed WebMCP browser API (a W3C Community Group draft, behind a flag in Chrome), so an AI agent in the browser can search projects, read the résumé or turn on reader mode without scraping the page. A WebMCP tool is shaped like an MCP server's tool, and MCP is what the Google and Anthropic FDE postings above ask for. I merged a PR into the Anthropic MCP Python SDK. I work in large, unfamiliar codebases regularly (vLLM has 200k+ lines; the MCP SDK is non-trivial to extend without reading the internals). I use Cursor, Claude Code, and Codex every day, and have for over a year.
The data and stakeholder work at Elite Hotel Group was real: I defined metrics and SLAs with finance and operations stakeholders, built ETL pipelines, and automated reporting across multiple properties. So I have worked in the loop between business requirements and technical delivery, which is closer to FDE work than a pure SWE background.
The gap is external customer deployment. The hotel group work was internal. My agentic systems are personal and portfolio-scale. I have not yet owned a full deployment lifecycle for an external customer from discovery through production with post-launch iteration. The research I read on this role kept naming this gap: "enough if framed narrowly, a stretch if framed broadly."
I'm treating that as something to close, not a reason to stay away from the role. The plan: one real external deployment with an actual user, a documented eval result, and a post-launch changelog. These blog posts are part of that too.
Closing thought
The odd thing about FDE is that the people best at it tend to dislike both the "pure coding" and the "pure customer success" framings. It suits engineers who get energy, not exhaustion, from switching between code and stakeholders; who want to know why something broke in production, not only how to patch it; and who can hold a strong technical opinion while staying open to being wrong about the customer's real problem.
That's a specific kind of person. If it's you, going after FDE roles instead of generic SWE ones is probably the right call, even if the title is newer and noisier than it should be. The interview loop is its own subject, and the follow-up post goes through it round by round.