Forward Deployed Engineer and AI Engineer Capability Roadmap

Learn the responsibilities by completing evidence-backed missions, not by memorizing a preferred stack.

This roadmap is for people growing into forward-deployed engineering (FDE), applied-AI engineering, or adjacent delivery roles—and for leaders deciding what capability a team needs. It complements the concise FDE Guide: the Guide explains the method; this page organizes the capabilities needed to apply it.

It is not a certification, hiring standard, fixed curriculum, or claim that one title owns every responsibility. Titles and team boundaries vary. Evaluate the work, authority, evidence, and operating responsibility instead.

Choose the responsibility, not the title

These roles overlap. The useful distinction is what each person remains accountable for after a design meeting or customer workshop ends.

No role receives authority merely from its title. Production access, approvals, release decisions, customer commitments, and risk acceptance still belong to the target system and its accountable owners.

The capability map

The work moves through one operating loop. Software, data, security, product judgment, and communication support every stage rather than forming separate tracks.

flowchart LR
    O["Observe the work"] --> V["Engineer value"]
    V --> M["Select the mechanism"]
    M --> B["Build and integrate"]
    B --> P["Prove and release"]
    P --> R["Operate and transfer"]
    R --> L["Productize learning"]
    L --> O

    F["Software · data · security · product · communication"] --- O
    F --- M
    F --- P
    F --- R

Breadth matters, but no one must be the deepest specialist in every domain. A strong practitioner recognizes missing expertise, assigns owners, exposes assumptions, and prevents an unowned gap from becoming hidden production risk.

Four practice missions

Use these missions in order when learning the method. On real work, enter at the current lifecycle stage and preserve prior evidence. A repository exercise demonstrates reasoning and implementation technique; it does not substitute for production experience, user acceptance, or target-system approval.

Mission 1: qualify a real workflow

Choose one bounded workflow you can observe. Do not begin with an agent idea.

1. Walk through at least three representative cases, including an exception or recovery path.
2. Record the trigger, decision, working interface, actors, sources, permitted action, current result, and owner.
3. Define an accepted outcome and credible verifier.
4. Estimate the eligible population, baseline, full cost, residual loss, and adoption constraints.
5. Decide discover, defer, or do_not_build; recommend pilot only after the value case is plausible.

Finish with: an observation log, workflow charter, and value case another person can challenge.

Mission 2: design the smallest sufficient system

Use the shipment-risk walkthrough as a reference for separating mechanisms.

1. Decompose the workflow into consequential decision steps.
2. Compare rules, optimization, classical ML, retrieval, model calls, agents, and human review per step.
3. Draw the domain, state, source, identity, and failure boundaries.
4. Select one end-to-end slice that can be accepted or safely rejected.
5. Record what remains manual and why.

Finish with: an intelligence-selection record, architecture decision, domain model, and a tested slice whose complexity is justified by the workflow.

Mission 3: secure and verify a consequential action

Use the invoice-exception reference to inspect a controlled write.

1. Define a narrow typed read or effect contract.
2. Enforce caller identity, tenant, scope, policy, credentials, destination, and data class at the trusted boundary.
3. Give the business operation a stable duplicate-safe identity.
4. Add approval only where required; bind it to the exact proposal and current policy.
5. Verify the source of truth after the effect and reconcile effect-unknown outcomes.
6. Test denial, revocation, retry, stale state, cross-tenant access, receipt tampering, timeout, and recovery.

Finish with: executable positive and adversarial tests, an explicit threat model, and a release claim no broader than the tested behavior.

Mission 4: operate and transfer the service

Treat launch as the start of a recurring decision.

1. Define accepted-outcome, adoption, reliability, safety, cost, and reviewer-load measures with owners and denominators.
2. Exercise alerting, containment, rollback, recovery, and a material change.
3. Run a service review that can continue, constrain, pause, or retire the system.
4. Have the receiving team perform a change and recovery without delivery-team intervention.
5. Record recurring field learning without copying customer policy, data, identities, or confidential context.

Finish with: an exercised service review, customer handoff, and owned improvement or retirement decision.

The quick-start engagement pack

Do not copy every template before the workflow earns that complexity. Start with five linked decisions and expand only when the target system requires it.

This pack is an orientation subset, not a production-complete packet. Use the full artifact sequence when designing or reviewing a real system.

How to assess capability

Whether reviewing yourself, a candidate, or a delivery team, ask for decisions and evidence rather than tool-name recall.

• Can they reconstruct a workflow from cases and recognize when not to build?
• Can they connect an accepted outcome to a verifier, value case, and accountable owner?
• Can they choose a smaller mechanism than an agent when it is sufficient?
• Can they explain source, identity, tenant, authority, failure, and recovery boundaries?
• Can they turn a claim into representative and adversarial tests?
• Can they operate within cost and reliability limits and respond to effect-unknown state?
• Can the receiving team change, recover, support, and retire the service without them?
• Can they convert recurring learning into a shared capability without leaking target-specific context?

A polished demo or diagram can start the conversation. It cannot prove production readiness, customer impact, security, or operating capability.

Concise glossary

Continue into the method

• Read the concise FDE Guide for the complete mental model.
• Follow the FDE lifecycle playbooks for a live engagement.
• Start from business-flow patterns only after qualification and value work.
• Inspect the executable references and Engineering Kit when implementation evidence is needed.
• Give a coding agent AGENTS.md or use one optional task skill for a bounded job.

The goal is not to become indispensable to a deployment. It is to leave behind an owned capability that produces accepted value and can be changed, recovered, and retired without delivery-team heroics.