What Is a Forward Deployed Engineer?

A forward deployed engineer is a customer-facing software engineer who ships outcomes on a platform—not a ticket-taker and not a pure back-office SWE.

That definition is short on purpose. The role is not “smart person who travels.” It is a GTM and delivery design: someone who sits close enough to the customer to understand the business, technical enough to build, and disciplined enough to build on shared primitives so the next customer is not a rewrite.

If you are evaluating the title for yourself, for a hire, or for a company that just renamed “professional services” to something sexier, this guide is the full skeleton: definition, when the motion is required, what “good” looks like week to week, the platform vs 55-repo trap, and the agent-era failure modes that separate real FDE work from demo theater.

Read the full playbook (role, 2×2, primitives, agent fleets):

The one-sentence job

Sell and ship an outcome that depends on a technical platform the buyer will not implement alone.

If you only sell software, non-technical buyers stall after the demo. If you only sell hours, you become a services firm. FDE is the motion that packages both: product plus people who understand the customer and assemble the platform into something that runs.

Kevin Bai’s FDE 101 framing (Anthropic Applied AI; founding FDE at Rippling; ex-Palantir) is the cleanest public skeleton for this: customers buy outcomes, not organized tables or “we deployed a model.” Use his frameworks as pedagogy; do not invent quotes. The rest of this post operationalizes that skeleton for hiring managers, candidates, and founders standing up the function.

A short history without the mythology

Palantir popularized the title in enterprise software: put strong engineers next to hard operational problems, assemble on a shared data/app platform, and leave a running system—not a slide deck. The myth that followed was “FDE = elite traveler with a black hoodie.” The durable idea was narrower and more useful:

1. The buyer wants a business result (placement, throughput, cycle time, risk reduction).
2. The product is technical enough that implementation is real engineering.
3. The company refuses to become a pure custom-software house by forcing assembly on platform primitives.

Everything else—travel policy, office hours, on-site vs remote, “embedded squads”—is packaging. The load-bearing constraint is primitives + outcomes.

Design partnership language is useful here. Early-stage B2B product-market fit often looks like a design partnership: intense customer context, incomplete requirements, shared building. Bai’s FDE 101 framing extends that idea: design partnership is not only for seed stage. At enterprise scale, FDE is that same intimacy with a platform underneath so you do not invent a new product per logo.

Why the role exists: the 2×2

Most software GTM fits one of two patterns:

1. Technical product → technical buyer — engineers absorb complexity. You need DevRel, docs, examples, and maybe SE support. You rarely need someone embedded to build the solution on every logo. Think developer infrastructure sold to CTOs and staff engineers.
2. Configurable SaaS → non-technical buyer — sales-led product, admin UIs, templates. Implementation is configuration, not software development. Think HRIS, collaboration tools, ticket systems.

There is a third corner that breaks both patterns: very technical platform sold to non-technical buyers. Ontology platforms, data apps, agent platforms, complex automation suites. The buyer wants shelf placement, claim accuracy, cycle time, or revenue—not a repository.

That corner needs people who can:

• Hear the business problem without drowning in jargon
• Translate it into workflows on the product
• Leave something running under real credentials and real ops constraints
• Feed what they learn back into the platform so the next engagement is faster

That is forward deployed engineering.

Two questions before you stand up the function

Bai’s public FDE 101 advice collapses org design into two filters:

1. Do you need FDE (not want it)? Must you GTM a technically complicated thing to a non-technical buyer? If no, DevRel or sales-led product may be enough.
2. Do you have a platform (or will you invest in one)? Without shared primitives, “engineers who make money” become a maintenance nightmare—even if the first three logos feel magical.

If you skip question two, you will still hire “FDEs.” You will just be running a services firm with a better brand story.

What FDE is not

The load-bearing bar: hire as a software engineer you trust in front of a customer. Soft skills without engineering depth collapse under enterprise entropy. Engineering depth without customer trust collapses under politics and requirements churn.

Bai’s tagline for the ideal profile is deliberately unglamorous: an FDE is nothing more than a customer-facing software engineer—someone you would hire as an SWE and put in front of a customer. The rest of the skills are trained under load.

Platform primitives vs the 55-repo trap

If every engagement is greenfield, you do not have an FDE function. You have a dev shop.

Maintenance wins that war. Engineers quit first; finance notices second. The cartoon failure mode from FDE 101 pedagogy is real: nobody wants to learn 55 repos of slightly different customer snowflakes.

Healthy FDE orgs force a split:

• Platform side — shared building blocks (APIs, auth, data models, runtimes, templates, observability).
• Customer side — configuration, workflows, and integrations unique to one account.

Anything that keeps reappearing across logos should move toward the platform. Anything truly unique stays customer-scoped. Early FDE work is also product scouting: the field is where you learn what to productize next.

How atomic should primitives be? It depends on industry and user base. Some motions look like ~60% pre-built assembly + ~40% customization. Others need extremely granular tooling because every vertical is different. The AWS analogy from the same pedagogy still works: shared primitives exist so you do not invent a database (or a host, or an auth system) per customer—breadth of users drives how atomic those blocks become.

A practical “platform vs customer” checklist

Put each piece of work into one bucket before you write it:

For agent work, the shared primitives look concrete:

• Isolation boundaries per customer (not one laptop with five client keys)
• Always-on compute (agents do not sleep when your battery dies)
• BYOK / key custody inside the tenant
• Snapshots, restore, and a fork path so the next engagement is not a rebuild
• Evaluation harnesses so “it worked in the room” is not the only quality signal

Day-to-day: what “good” feels like

A strong FDE week is not pure meetings and not pure solo coding.

Discovery

• Map the outcome in business language first (“claims cycle time down 20%”), then systems language
• Identify who owns success after you leave (name + team, not “the customer”)
• Surface constraints early: security review, data residency, change freezes, political landmines
• Write a one-page problem statement the executive sponsor will actually read

Assembly

• Compose platform primitives; resist inventing a private stack
• Prefer configuration and templates over a permanent product fork
• Spike the risky integration first, not the pretty demo path
• Keep a living “what is reusable?” note while you build

Production

• Credentials, isolation, monitoring, and a handoff a non-FDE can operate
• Explicit failure modes: what pages, who pages, what is the rollback
• Cost caps and tool permissions treated like auth design
• Restore drill: you have proven you can recover, not only deploy

Feedback

• Open issues or PRs that make the next customer cheaper
• Separate “customer unique” from “we should productize this”
• Socialize field pain with product eng without becoming a pure feature funnel

You will still write code. The difference is where the code lives: on the shared platform and in scoped customer configuration—not a permanent fork of the product per logo.

Scenario: two logos, same category, different FDE outcomes

Logo A (services trap): FDE clones a private repo, hardcodes credentials on a laptop, wins the pilot demo, then spends six months firefighting uniqueness. Logo B requires a full rewrite. Platform receives zero PRs. Headcount grows; margin shrinks.

Logo B (FDE motion): FDE assembles on shared auth, data connectors, and a standard agent runtime. Customer-specific policy lives in config and a private template. After handoff, two platform tickets land: “connector X needs retry semantics” and “template Y needs approval gates.” Logo C starts from the template, not from zero.

Same title on the badge. Different economic system.

The agentic-era reason this role exploded

In 2026 the software business itself shifted. Nearly every platform is agentic. Agentic means customizable. Customizable means buyers often cannot tell what you actually sold them, and cannot implement it alone when they go upmarket.

Bai’s 2026 hypothesis is not “everyone copied Palantir.” It is that the nature of software GTM changed: if nearly every platform is agentic and customizable, leaving success to the customer’s implementation ability fails as you expand. Someone has to close the gap between demo and durable outcome. Title that person FDE, Applied AI, AI Deployment Engineer—whatever. The motion is the same.

Agent products make the gap wider because behavior is not static UI:

• Tools can take irreversible actions
• Models drift under real data
• Long-running work needs uptime and memory
• Secrets are more numerous and more sensitive
• “It worked in the demo” is not a quality bar

Deploy craft when the product is an agent

If you are an FDE shipping agents for customers, the failure modes are not abstract:

Laptop fleets

Fast to start. Dies at the airport. Credentials on devices that leave buildings. Impossible multi-customer hygiene. Great for a spike; fatal as a production strategy.

DIY VPS snowflakes

Always-on is possible. Isolation and restore depend entirely on your discipline. Without a template culture, every logo becomes a unique ops novel—and every engineer becomes the bus factor.

Shared-kernel density hosts

Cheap density. Shared kernel means shared classes of escape and noisy-neighbor risk. Fine for low-trust toys; stressful next to production keys and customer data.

Ephemeral sandboxes only

Perfect for “run this code for five minutes.” Wrong shape for “monitor this inbox / operate this workflow / keep this bot alive.” Metering that assumes short jobs punishes real agents.

Hardware isolation, BYOK inside the tenant, always-on microVMs, and forkable templates are the boring floor. Without them, every engagement reinvents ops and every “pilot” becomes a hostage situation.

Minimal production checklist for customer-scoped agents

1. Isolation — which guest / boundary holds this customer’s tools and data?
2. Keys — where do model and SaaS credentials live; who can read them?
3. Uptime — what stays up when a human laptop closes?
4. Persist — what state survives reboot?
5. Restore — can you roll back a bad day?
6. Fork — can the next logo start from a proven assembly?
7. Eval — which golden tasks must still pass after every change?
8. Handoff — can a non-hero operate this with a runbook?

If you cannot answer those eight, you are still in pilot theater.

Anti-patterns that pretend to be FDE

• Title inflation — “FDE” on a pure SE loop with no production ownership
• Hero culture — one person holds all customer context; no multi-FDE collaboration
• Permanent embedding — success defined as never leaving, not as operable handoff
• Platform starvation — field team ships revenue while product never receives generalization work
• Demo metrics only — “wow” moments without isolation, monitoring, or restore
• Secrets sprawl — customer keys on personal machines “just for this week”
• Repo per logo — accepted as “velocity” until maintenance owns the P&L

Print the list. Use it in hiring debriefs and in quarterly org reviews.

How jurniti fits (soft)

jurniti is a managed Firecracker microVM platform for agent harnesses. You pick the agent stack—Hermes, OpenClaw, Pi, or another harness the platform supports; the control plane stays harness-agnostic. Each tenant gets a dedicated guest, persist volume, and BYOK path. Templates and forks let FDEs productize a working customer setup without cloning a snowflake host by hand.

That is not “we hire FDEs for you.” It is the runtime primitive under customer-scoped agents so your people can stay focused on outcomes: isolation and always-on as a floor, not a side quest.

Economics stay honest: no free trial or free tier. First purchase carries a 30-day money-back guarantee so you evaluate on a real always-on box, not a toy sandbox that lies about production shape.

A one-page definition you can paste into a hiring doc

Forward deployed engineer: a software engineer who owns customer outcomes by assembling a technical platform into production systems, leaving operable handoffs, and feeding field learnings into shared primitives—rather than building permanent snowflakes or pure demos.

Success signals (90 days): one production handoff, two platform improvements from field pain, zero secrets on personal devices for multi-customer work, and a written isolation story per engagement.

Non-goals: ticket-only work, pure pre-sales without delivery ownership, or services revenue that never becomes product.

Get the free series

Seven emails: role definition, the 2×2, primitives vs dev shop, the agentic shift, deploy craft, and a managed third way.

Prefer to provision now? See pricing — 30-day money-back on first purchase, no free tier.

Related reading

• FDE job: what hiring teams actually mean
• FDE vs software engineer
• How to become a forward deployed engineer
• AI agent sandbox for customer deployments
• Forward deployed AI engineer