Forward deployed engineering (FDE) teams that compound their impact in 2026 do two things at once: they scope relentlessly before writing code, and they replace every stage of their workflow pipeline with AI agents. Do only the first and a competitor who automates will eat your lunch. Do only the second and you build a "token-maxing slop cannon" — fast output that solves the wrong problem. The teams winning the enterprise AI race combine both.
Last verified: 2026-07-31
- Forward deployed engineering originated at Palantir (founded 2003) and has since spread to Ramp, OpenAI, Anthropic, Scale AI, and dozens of enterprise AI companies.
- Ramp raised $750M at a $44B valuation in June 2026 and launched "Applied AI Solutions," embedding FDEs inside enterprise finance teams to build custom AI agents (Ramp blog).
- 87% of CFOs say AI is critical, but only 21% report measurable results — the gap FDE teams exist to close (Deloitte CFO Signals Q4 2025, cited by Ramp).
- Volatile facts: Pricing, model capabilities, and enterprise AI adoption numbers change frequently — re-check monthly.
What Is Forward Deployed Engineering?
A forward deployed engineer (FDE) is a software engineer who embeds directly inside a customer's environment to make a complex product actually work for that customer — shipping production code, not slide decks. The role originated at Palantir after its founding in 2003, when engineers were literally deployed to military sites and customer offices to integrate Palantir's platforms into real operations (Palantir careers). For over a decade, the title was nearly exclusive to Palantir. In the late 2010s, Scale AI, C3.ai, Databricks, and Snowflake adopted similar functions for their complex enterprise deployments (Ramp Builders Blog).
The role exploded in the AI era because enterprise customers don't buy software — they buy outcomes. Foundation Capital observed that "forward-deployed engineers have become one of the most strategic assets in enterprise AI companies" and a16z called FDE "the hottest new role in tech" (Ramp Builders Blog). The reason is structural: AI products require deep contextual integration into each customer's data, workflows, and legacy systems — work that cannot be fully productized into a self-serve tool.
Why FDE Teams Need AI Agents Now (The Urgency)
Ramp processes $200B+ annually across 70,000+ businesses and reports that AI token spend among its customers has jumped 13x since January 2025 (Ramp blog). Yet in a Deloitte survey Ramp cites, 87% of CFOs called AI very or extremely important while only 21% of active users said it had delivered clear, measurable value (Ramp blog).
That gap — between AI spend and AI results — is exactly what FDE teams exist to close. But closing it manually doesn't scale. A team of 30 engineers cannot personally scope, spec, and implement custom integrations for every enterprise customer. The solution is to look at the entire FDE lifecycle and ask: which stages can an agent do faster?
The Two-Principle Framework: Always Be Scoping + Scale With Tokens
The framework that guides high-performing FDE teams breaks into two operating principles. Neither works alone.
Principle 1: Always Be Scoping
The most common misconception about FDE is that the job is to say "yes" to whatever the customer asks for. It is not. An FDE who simply builds whatever sales requests ends up shipping software nobody uses — burning engineering hours on integrations that were urgent for a quota, not for the customer.
What good scoping looks like in practice:
Before writing a single line of code for a customer request, a well-trained FDE asks:
- What is driving the urgency? Is the customer actually blocked, or is a sales rep trying to close a deal before quarter-end? The distinction matters.
- Who will use this? Understanding the end user — not just the buyer — determines whether you build the right thing.
- Have we exhausted workarounds? Is there a manual process, an existing integration, or a way for the customer's own technical team to hit your API instead?
- Will other customers benefit? If yes, the request becomes a product investment, not a one-off. If no, the cost-benefit analysis changes.
- What are our basic assumptions? Which platform, which device, which data format — validate every assumption before you build.
The cost of skipping scoping is best illustrated by a real example. An FDE team once spent two weeks building a reimbursement feature for both iOS and Android — only to discover the customer mandated iOS-only devices for all employees. Every hour spent on Android was wasted. Basic assumption validation would have taken ten minutes and saved two weeks of engineering time.
The scoping checklist before building anything:
| Question | What it catches |
|---|---|
| Is the urgency from the customer or from sales? | Building for a quota deadline, not a customer need |
| Who is the actual end user? | Building for the buyer, not the person who will use the feature |
| Is there a manual workaround? | Over-investing in automation when a process fix works |
| Can the customer hit our API instead? | Building a定制 integration when a self-serve path exists |
| Will other prospects need this? | Missing a product-level investment opportunity |
| What are our platform assumptions? | Wasting weeks on the wrong platform, data format, or device |
Principle 2: Scale With Tokens
If scoping is about building the right thing, scaling with tokens is about building it efficiently. The FDE lifecycle — from receiving a customer request to shipping working code — has distinct stages:
Request received → Context gathering → Scoping → Spec writing → Implementation → Shipping
Each of these stages is a knowledge-work task that AI agents can partially or fully automate. The key is to break the pipeline down and tackle one stage at a time.
Stage 1: Context gathering and triage
This is the first and most tractable stage. Consider the typical pattern: customer-facing teams (sales reps, account managers, CSMs) post requests into a shared channel or workflow tool. The quality of these requests varies wildly — some are detailed with full context, others are a single line like "we need an SAP integration."
An AI agent deployed at this stage can:
- Immediately acknowledge the request and start asking clarifying questions (latency drops from hours to seconds)
- Run multiple rounds of back-and-forth with the submitter until it has enough context
- Check what already exists in the product that could address the request
- Draft a structured spec when it determines the request is ready
In practice, teams that have deployed agents at this stage report saving roughly 20% of the time they previously spent on scoping — and the improvement in request quality means downstream stages move faster too.
Stage 2: Spec writing
Once the agent has gathered context, it can draft a spec. The FDE's role shifts from writing specs to reviewing and editing them — applying taste and judgment to the agent's output rather than starting from a blank page.
Stage 3: Implementation
This stage is increasingly tractable thanks to frontier coding models. Claude, GPT, and similar models can one-shot medium-sized features from a well-shaped spec. The FDE reviews the code, tests it against the customer's actual environment, and handles edge cases the model misses.
Stage 4: The hard middle — spec to working product
The gap between a spec and a working product in a specific customer's environment is the hardest stage to automate. It requires understanding the customer's data, legacy systems, approval chains, and business logic. This is where FDEs add the most value — and where getting the right context into the agent is the biggest challenge.
How to Build Your FDE Agent Factory (Step-by-Step)
Building an agent-powered FDE pipeline is not a moonshot. Here is a practical approach, stage by stage:
Step 1: Start with triage
Deploy an AI agent where customer requests arrive — your Slack channel, Notion workflow, or ticketing system. Configure it to ask scoping questions (the same ones from the checklist above) and not generate a spec until it has answers. Tools like Notion's Custom Agents (launched February 2026 for Business and Enterprise plans) support trigger-based autonomous workflows that can run multi-round questioning without human prompting (Notion AI documentation).
Step 2: Build the spec drafter
Once the triage agent has enough context, have it generate a structured spec. Define a spec template that includes: problem statement, affected users, proposed solution, alternatives considered, and acceptance criteria. The FDE reviews the spec — this is where human judgment enters the pipeline.
Step 3: Connect the implementation agent
Feed the approved spec into a coding agent (Claude Code, Copilot, Codex, etc.) configured with access to your codebase. For a deeper dive on running parallel coding agents for free, see our guide to parallel AI coding agents in 2026.
Step 4: Build evals and rubrics
Every stage of the pipeline needs quality gates. Define what a "good triage result" looks like, what a "good spec" looks like, and what a "good implementation" looks like. Use rubrics and human feedback to improve the agent's output over time. This is not optional — without evals, you are flying blind.
Step 5: Solve the context problem
The single hardest challenge is getting the agent the right context at each stage. A product manager's knowledge of the product — edge cases, historical decisions, why something was built a certain way — lives in Notion docs, help articles, and people's heads. Only a fraction is written down. Invest in building a knowledge base that captures this context in a format agents can use: skills, memories, and tools that give the agent the same information a human FDE would have.
What Happens When You Skip a Principle
| You have... | You get... |
|---|---|
| Scoping + tokens | Compounding impact — the team scales without losing quality |
| Scoping only | Great work, but you cannot keep up with demand. Competitors who automate will overtake you |
| Tokens only | A fast output machine that builds the wrong things — "a token-maxing slop cannon" |
| Neither | You lose. Slowly at first, then all at once |
The two principles are interdependent. Scoping without automation means your team becomes a bottleneck — every request requires a human to gather context, ask questions, and write a spec. Automation without scoping means you ship fast but solve the wrong problems, burning customer trust and engineering capacity.
What This Means for You
If you run an FDE team: Audit your current pipeline. Which stages are still manually done by engineers? Start with triage — it is the cheapest to automate and the highest-leverage because it improves request quality for every downstream stage. Read our guide on when your company actually needs forward deployed engineers to make sure the role fits before investing.
If you are an FDE: Your job is not disappearing — it is evolving. The taste and judgment you apply to the final output is the throughline that does not get automated. But the mechanical parts (gathering context, writing specs, implementing from a spec) increasingly can and should be delegated to agents. Learn to manage agents the way you would manage a junior engineer: give them clear specs, review their output, and build feedback loops. For more on structuring FDE teams that scale, see our team structure playbook.
If you are building an AI product for enterprise: The gap between AI spend and AI results is your market. The companies pulling ahead are not just spending more on AI — they are changing how they deploy it. FDE teams that scope well and scale with tokens can close that gap faster than any off-the-shelf tool. For the ROI framework, see our FDE and AI coding agents ROI playbook.
FAQ
Q: What is forward deployed engineering? A: Forward deployed engineering (FDE) is a model where software engineers embed directly inside a customer's environment to make a complex product work for that specific customer. The role was pioneered by Palantir after 2003 and has since spread to Ramp, OpenAI, Anthropic, and other enterprise AI companies. FDEs ship production code, not consulting deliverables.
Q: How do AI agents change the FDE role? A: AI agents can automate the mechanical stages of the FDE lifecycle — gathering context from customer requests, asking scoping questions, drafting specs, and even implementing features from a well-shaped spec. The FDE's role shifts toward reviewing agent output, applying judgment, and managing the agent pipeline the way you would manage a team of junior engineers.
Q: What is "scale with tokens" in forward deployed engineering? A: "Scale with tokens" means looking at every stage of the FDE workflow pipeline (from request intake to shipping code) and replacing each stage with AI agents where possible. The goal is to multiply the team's throughput without adding headcount, by letting agents handle the mechanical work while engineers focus on taste, judgment, and customer relationships.
Q: Why is scoping still important if agents can do the work? A: Without disciplined scoping, an agent pipeline produces fast output that solves the wrong problems — what one Ramp engineering leader called a "token-maxing slop cannon." Scoping ensures the team builds the right thing before spending any tokens on implementation. The two principles are interdependent: scoping without token scaling creates a bottleneck, and token scaling without scoping wastes effort.
Q: Which tools can be used to build an FDE agent pipeline? A: The triage stage can use Notion Custom Agents (available on Business and Enterprise plans since February 2026), Slack-integrated AI bots, or custom agents built on APIs from OpenAI or Anthropic. The implementation stage can use coding agents like Claude Code, GitHub Copilot, or OpenAI Codex. The critical investment is in evals, rubrics, and a knowledge base that gives agents the right context at each stage.
Q: How much time can AI agents save in FDE workflows? A: Teams that have deployed agents at the triage and scoping stage report saving approximately 20% of the time previously spent on manually reviewing and scoping customer requests. Additional gains come downstream when well-shaped specs are fed into coding agents — but the exact savings depend on request complexity, codebase maturity, and how much context the agent has access to.
Discussion
0 comments