A forward deployed AI engineer is the FDE role when the product is not a classic app—it is models, tools, and agents that change behavior under real data and real keys.
Same GTM skeleton as classic FDE: customer-facing software engineer, outcomes over software-or-hours, shared platform primitives, refuse the 55-repo trap. Different failure modes. Laptop demos that die at the airport are not outcomes. Shared kernels next to production credentials are not isolation. “It looked good in the room” is not evaluation.
If your title says AI and your week never touches multi-customer boundaries, eval harnesses, or restore drills, you are wearing a sticker—not doing the job.
The AI-native job description (without the fluff)
You still:
- Face the customer and hear the business problem without drowning in jargon
- Ship production systems someone else can operate
- Build on platform primitives instead of permanent private stacks
- Leave something operable with a written handoff
- Feed field lessons back into product
You also:
- Choose when not to use a model
- Design tool permissions like you design auth
- Plan for long-running work, not only request/response chat
- Evaluate quality continuously after go-live
- Isolate multi-customer secrets as a first-class design problem
- Budget for cost drift when agents loop, retry, and call tools
If your “AI FDE” role skips isolation and evaluation, it is a rebranded SE track. If it skips customer discovery, it is a rebranded platform SWE track. The job is both bars at once.
Why AI products force the FDE motion
Agentic platforms are customizable by default. Skills, tools, memory, workflows, and policies make every serious deployment look different. Customizable platforms confuse non-implementing buyers. The more powerful the agent, the less a static demo proves production readiness.
The pedagogical hypothesis from FDE 101 materials (Bai’s public framing is useful; attribute carefully) is simple: nearly every platform is agentic → customers often cannot implement alone → someone must close the gap. Titles proliferate; the motion does not.
| Classic FDE stress | AI-native stress multiplier |
|---|---|
| Requirements churn | Plus model nondeterminism |
| Integration glue | Plus tool side effects and permissions |
| Training tax | Plus eval tax that never ends |
| Security review | Plus prompt injection and data exfil via tools |
| Multi-tenant data | Plus multi-tenant keys, tools, and memory |
You do not get a free pass because “the model is smart.” Smart systems with tools are higher blast-radius systems.
Agent failure modes AI FDEs actually fight
This section is denser on purpose. These are the incidents that kill pilots after applause.
1. Silent quality collapse
Prompts change. Tools change. Underlying models change. Customer data drifts. Without golden tasks that re-run after every change, quality dies quietly. Customers notice when the business metric moves—or when a bad tool call emails the wrong person.
Mitigation: treat eval as continuous infrastructure. Golden tasks per outcome. Fail the deploy if they fail. Log model version, prompt hash, and tool schema version with every run.
2. Tool permission disasters
Agents with broad tools are powerful and dangerous. “Can write tickets” becomes “can close tickets.” “Can read the repo” becomes “can push.” “Can send draft emails” becomes “can send.”
Mitigation: design tools like auth. Least privilege. Human gates for irreversible actions. Dry-run modes. Clear audit trails. Prefer narrow tools over god-mode shells when the customer will not staff a 24/7 babysitter.
3. Key and secret sprawl
The fastest path to a demo is keys in a laptop environment file for five customers. The fastest path to a career-limiting incident is the same.
Mitigation: BYOK inside the tenant boundary. No shared platform ledger of customer keys if your threat model forbids it. No multi-customer secrets on a single personal machine. Rotate when people leave the engagement.
4. Isolation theater
Marketing says “isolated.” Reality is shared-kernel density next to production credentials—or containers co-tenants can pressure. Under a serious security questionnaire, theater dies.
Mitigation: name the isolation boundary honestly. Prefer hardware-level guest isolation (microVM) for customer-scoped agents with production keys. Do not invent security properties your runtime does not have.
5. Always-on work on ephemeral-only runtimes
Ephemeral sandboxes are excellent for short jobs. Using them as the only home for an agent that must live overnight is a category error.
Mitigation: match runtime category to job shape. Long-running agents with memory need always-on guests and persist—not only per-second sandboxes.
6. No restore, no fork
A bad day with no snapshot is a rebuild from chat history and hope. Every new logo starts at zero because nothing was productized as a template.
Mitigation: snapshot and restore as routine drills—not disaster folklore. Templates and forks so logo two is assembly, not archaeology.
7. Hero handoff
If only the original engineer can operate the system, you sold a person. When they rotate off, the agent becomes a haunted machine.
Mitigation: runbooks, dashboards non-heroes can read, paging that is not a personal cell phone as the only alert path, and a handoff meeting that includes a restore drill.
8. Cost runaway
Agents loop. Retries multiply. Tools call models that call tools. Without caps, the business case evaporates while the agent “works.”
Mitigation: budgets, rate limits, max steps, and alerts on spend before finance notices.
Multi-customer isolation is not optional polish
For AI FDEs, multi-customer isolation is the design problem that separates productized delivery from boutique chaos.
Ask, for every engagement that might become two:
| Question | Weak answer | Strong answer |
|---|---|---|
| Who can read customer A’s keys? | “Only us” | Tenant-scoped custody, auditable access |
| Can A’s agent see B’s files? | “We are careful” | Hard isolation at guest boundary |
| What is blast radius of a compromised tool? | “Unlikely” | Scoped tools + network + secrets |
| Can we prove isolation in a review? | Slide deck | Architecture that matches the claim |
| How do we add logo three? | Clone the VPS | Template/fork from a proven assembly |
If your answers live in the weak column, stop hiring for volume. Fix the primitive layer first.
A week in the life (AI-native)
This is a realistic loop—not a calendar fantasy.
Monday — discovery and metrics
Map the workflow that currently costs humans hours. Name the metric that already exists in the business. Map tools, data sources, “who gets paged,” irreversible actions, and political owners. Write success criteria that could fail the pilot honestly.
Refuse vanity metrics invented only for the vendor demo.
Tuesday — assemble on primitives
Compose the platform: harness, tools, memory shape, evaluation cases. Refuse a private stack unless uniqueness is real. Spike three failure cases on purpose (bad tool args, empty data, model refusal) before you optimize happy path.
Wednesday — production path
Secrets, network, logging, isolation boundary between this customer and others. Confirm BYOK placement. Confirm who can access the guest. Write the first draft of the runbook while the system is still simple.
Thursday — harden
Retries with budgets, human approval gates, cost caps, restore drill, golden-task suite in CI or a scheduled runner. Break something on purpose and restore it. If restore fails, Thursday is not optional.
Friday — handoff + productize
Handoff notes a non-hero can use. Open a platform issue: “three customers needed the same integration—productize it.” If Friday never produces a platform ticket, you are sliding into services.
That Friday feedback loop is the difference between FDE and a pure services bench.
Deploy craft checklist for AI FDEs
Print this. Argue with it. Do not ignore it.
- Isolation — guest kernel / microVM vs shared container kernel
- Keys — BYOK inside the tenant vs shared platform ledger or laptop sprawl
- Uptime — always-on agent vs ephemeral sandbox billed per second
- Persist — memory, files, and config survive restarts
- Restore — snapshot and roll back a bad day
- Fork — next customer starts from a proven template
- Eval — golden tasks run after every change
- Blast radius — one customer cannot read another’s tools or data
- Tool gates — irreversible actions require human approval or hard policy
- Cost caps — max steps, budgets, alerts
- Handoff — non-hero operators with a written runbook
- Productize — repeats return as platform primitives
How categories fail the checklist
| Category | Common fails |
|---|---|
| Laptop fleets | 1–3, 8, 11 |
| DIY VPS snowflakes | 5–6, 11–12 (ops tax) |
| Shared-kernel density | 1, 8 under production keys |
| Ephemeral-only sandboxes | 3–6 when the agent must live |
Categories only—no vendor scoreboard. Honesty about category beats brand debate.
Evaluation discipline that survives go-live
AI FDEs who skip eval become incident responders with better titles.
Minimum viable eval for an agent engagement
- Golden tasks tied to the business metric (not only model benchmarks)
- Regression set for tool misuse, empty data, and permission denials
- Version pins for model, prompt, tool schema
- Scheduled runs after deploys and on a cadence after go-live
- Human review sample for edge cases models miss
- Cost metrics alongside quality metrics
Anti-patterns
- One red-team day, then silence
- Only happy-path demos in the eval set
- No ownership of eval failures (everyone shrugs)
- Swapping models weekly without re-running goldens
- Optimizing for a leaderboard the customer does not care about
If you cannot re-run goldens after a prompt edit, you do not have eval—you have folklore.
Platform primitives for agents (what to demand)
Whether you work at a lab, a startup, or an agency, demand a platform layer that includes:
- A runtime you do not reinvent per logo
- Isolation that matches your security claims
- BYOK for customer model keys
- Always-on shape when the agent must live
- Persist + restore for real work
- Templates for common assemblies
- Observability that non-heroes can read
- A path for field work to become product
Without those, “forward deployed AI engineer” is a burnout title with a GPU sticker.
Scenarios you will meet (and how strong AI FDEs respond)
| Scenario | Failure | Strong response |
|---|---|---|
| Overnight batch | Laptop dies when lid closes | Always-on guest, persist, budgets, morning eval sample |
| Second business unit | Copy-paste VPS snowflakes | Template/fork; re-run goldens; no shared keys “for convenience” |
| Scary tool ask | God-mode shell “for flexibility” | Narrow tools; gate irreversible actions; document residual risk |
| Quiet drift | Quality drops weeks later | Goldens fail the deploy; roll back; pin versions; add the case |
| Security questionnaire | Isolation claimed, not real | Architecture that matches claims—or fix runtime before sales |
Anti-patterns that wear AI branding
Outcome theater with no pre-existing metric; private stacks with no productize path; eval optional after launch; hero laptop as multi-customer production; ephemeral sandboxes as permanent workers; shared-kernel density sold as strong isolation; no restore path; handoff = “Slack me”; cost ignored until finance screams; model swapping as a substitute for systems work.
If your team ships three of these regularly, rename the role to services until the primitive layer exists.
How jurniti fits the AI FDE toolkit
jurniti provides managed Firecracker microVMs for agent harnesses (Claude Code, OpenClaw, Hermes, and the rest of the catalog). You bring model keys (BYOK). Each tenant is isolated. Persist volumes keep work durable. Templates and forks turn a working customer setup into a reusable primitive.
Soft pitch on purpose: you remain the hero who ships outcomes—discovery, eval, tool design, handoff. jurniti is the boring always-on machine under the agent: hardware-level isolation, BYOK, always-on compute, persist, templates/forks, multi-harness platform so you are not locked to one agent stack for every customer.
No free trial and no free tier. First purchase includes a 30-day money-back guarantee—evaluate on a real isolated box, refund cleanly if it is the wrong fit.
Career and founder notes
Candidates: shipping bar equal to product SWE; discovery weekly; multi-tenant instincts early; handoffs and restore drills as portfolio; runtime categories (laptop, DIY VPS, shared-kernel density, ephemeral sandbox, microVM) chosen deliberately; eval as craft; refuse god-mode tools and unnecessary models. SE → raise engineering. SWE → raise customer entropy. Prompt-only → acquire systems before production ownership.
Founders: opening “AI FDE” reqs without a platform invents a services firm. Fund shared primitives, a deliberate multi-customer runtime floor, eval infrastructure field engineers can extend, and Friday productize time. Hire people who face customers and ship. The title is optional; the motion is not.
Get the free series
FDE 101 walks role → 2×2 → primitives → agentic shift → deploy craft → managed third way. It is written for people who will run fleets, not only decks.
Pricing — 30-day money-back on first purchase, no free tier.