The Problem
In 2026, AI companies face a structural bottleneck: their models work in the lab, but getting them to work inside an enterprise — with its legacy systems, security constraints, data silos, and skeptical stakeholders — requires a different kind of engineer. OpenAI, Anthropic, Palantir, and Google Cloud are all hiring Forward Deployed Engineers. This lesson breaks down what the role actually is, why it exists, and how it differs from every other engineering role.
The 75/15/10 split
The FDE role breaks down into three buckets. "75/15/10" is a rule of thumb for a build-heavy week, not a measured average — but the shape of it is the difference between being an FDE and being a solutions engineer who codes: engineering is the majority of the job.
75% Engineering — Building and deploying production systems. This is not "writing API wrappers." It's building data pipelines that handle 2M documents, deploying RAG systems behind client firewalls, integrating SAML SSO, writing evaluation harnesses, and hardening services for production traffic. You write real code that runs in real environments with real consequences.
15% Consulting — Discovery sessions, scope management, architecture recommendations, stakeholder alignment. You run a 90-minute discovery call with a client CTO and extract concrete requirements from vague desires. You push back when a client wants to expand scope mid-deployment. You translate technical trade-offs into business language that a VP can act on.
10% Client Relationship Management — Building trust, managing expectations, navigating internal politics. You build relationships with the client's engineering team so they adopt the system rather than resist it. You manage the nervous VP who expected AI to work like magic. You establish a communication cadence that keeps stakeholders informed without overwhelming them.
# FDE time allocation tracker — what a real 8-week engagement looks like
engagement_timeline = {
"week_1": {"engineering": 30, "consulting": 50, "client_rel": 20}, # Heavy discovery
"week_2": {"engineering": 60, "consulting": 25, "client_rel": 15}, # Building PoC
"week_3": {"engineering": 80, "consulting": 10, "client_rel": 10}, # Deep build
"week_4": {"engineering": 70, "consulting": 15, "client_rel": 15}, # Deploy + review
"week_5": {"engineering": 75, "consulting": 15, "client_rel": 10}, # Production hardening
"week_6": {"engineering": 60, "consulting": 20, "client_rel": 20}, # User testing + feedback
"week_7": {"engineering": 70, "consulting": 15, "client_rel": 15}, # Iteration
"week_8": {"engineering": 40, "consulting": 25, "client_rel": 35}, # Handoff + expansion
}
# Average the split across the whole engagement
totals = {"engineering": 0, "consulting": 0, "client_rel": 0}
for week, split in engagement_timeline.items():
for k, v in split.items():
totals[k] += v
grand_total = sum(totals.values())
for k, v in totals.items():
pct = (v / grand_total) * 100
print(f" {k}: {pct:.0f}%")
# Output:
# engineering: 61%
# consulting: 22%
# client_rel: 18%
Run it and the average is nowhere near 75/15/10 — and that is the lesson. The build weeks (3–5) average exactly 75% engineering, but discovery in week 1 and handoff in week 8 are dominated by consulting and client work, and they drag the whole engagement down to roughly 60/20/20. When someone quotes "75% engineering," ask which weeks they mean: the rule of thumb describes the build, not the engagement.
The AI last mile problem
The structural reason FDEs exist is the AI last mile problem: the gap between a model that works in a demo and a system that works in production.
What the last mile looks like in practice:
- Demo
- Data: 100 curated documents, clean text, no access control
- Users: The demo presenter, who knows the right questions to ask
- Infra: OpenAI API, Pinecone cloud, no firewall
- Failure mode: If it's wrong, you show a different example
- Timeline: 2 days to build
- Production
- Data: 2M documents across SharePoint, SAP, Oracle — messy, conflicting schemas, access control required
- Users: 500 employees with varying technical literacy asking unpredictable questions
- Infra: Behind client firewall, on their Kubernetes cluster, with their SSO
- Failure mode: If it's wrong, the VP sends an angry email and the deployment is at risk
- Timeline: 6-8 weeks to deploy
The last mile is where most of the work in an enterprise AI deployment lives. The model is the smaller part; the deployment — data integration, access control, evaluation, monitoring, stakeholder management — is the larger one, and it is the FDE's job.
Companies hiring FDEs in 2026
| Company | FDE Focus | What They Look For |
|---|
| Palantir | Government/defense, Foundry enterprise deployments | Clearance eligible, Gotham/Foundry experience, data integration depth |
| OpenAI | Enterprise ChatGPT deployment, custom GPT integration | Production AI deployment, RAG systems, client communication |
| Anthropic | Enterprise Claude deployment, safety-critical AI | AI safety awareness, enterprise integration, evaluation methodology |
| Google Cloud | Vertex AI deployment, enterprise AI migration | Cloud architecture, ML engineering, GCP certification |
| Startups (Runway, Glean, etc.) | Customer-facing AI deployment | Full-stack capability, speed, customer empathy |
Pay varies widely by company, level and location, and moves quickly. Check current postings and compensation data for the specific role and level you are targeting rather than relying on a single range for the industry; the lab has you do exactly that.
How FDE differs from related roles
Role comparison matrix:
- FDE
- Primary output: Production AI system deployed in client environment
- Time horizon: 4-16 weeks per engagement
- Code relationship: Builds custom integrations + deploys existing product
- Client contact: Daily — embedded with client team
- Ownership: Owns outcome for 6 months post-deployment
- SWE
- Primary output: Features and systems in the product codebase
- Time horizon: Ongoing — owns services long-term
- Code relationship: Builds the product itself
- Client contact: Minimal — receives requirements via PM
- Ownership: Owns code and services, not client outcomes
- Solutions Engineer
- Primary output: Demos, POCs, technical sales support
- Time horizon: Days to weeks per opportunity
- Code relationship: Shows what's possible, doesn't ship production
- Client contact: High — but during sales cycle only
- Ownership: Owns the demo, not the deployment
- AI Engineer
- Primary output: ML models, training pipelines, inference services
- Time horizon: Quarters — model development cycles
- Code relationship: Builds ML systems and infrastructure
- Client contact: Low — works on the model, not the deployment
- Ownership: Owns model performance, not client outcomes
The key distinction: an FDE ships production systems on infrastructure they don't control, with stakeholders they don't manage, on timelines they don't set. That combination is unique to the role.