Forward Deployed Engineer Roadmap
Take a customer problem from discovery through integration, deployment, acceptance and handoff.
A Forward Deployed Engineer takes ambiguous customer problems and turns them into working production systems. This roadmap develops the six capabilities SCAI sees in successful FDE hires: software foundations, customer discovery, solution architecture, applied AI with evaluation, deployment and reliability, and user acceptance with handoff. Each stage connects to the evolving capstone — a B2B support workflow — so you build one project, not six disconnected tutorials.
What is a practical FDE roadmap?
A practical FDE roadmap develops six capabilities: software foundations, customer discovery, solution architecture, applied AI, deployment and handoff. Advance when you can demonstrate a working outcome at each stage, not simply when you finish a tool or tutorial.
Sources and methodology · This roadmap is reviewed when production practices, tools or platform patterns materially change.
Stages
6
Last reviewed
16 September 2026
Stage 1: Software and full-stack foundations
Build a production-grade backend service with typed APIs, database migrations, authentication, structured logging, containerized deployment and a tested CI pipeline — the foundation every FDE engagement depends on.
Every FDE engagement at SCAI starts with shipping a working service. If you cannot build, test and deploy a small API with proper error handling and observability, you cannot own a customer outcome. The gap between 'I can write a FastAPI route' and 'I can ship a service a customer team can operate' is where most learners stall.
- What you learn
- Production Python with FastAPI: Pydantic validation, dependency injection, background tasks, streaming responses and structured exception handlers that return consistent error envelopes.
- PostgreSQL with Alembic migrations: schema versioning, transaction isolation levels, connection pooling, indexed queries and EXPLAIN ANALYZE for slow-query diagnosis.
- Authentication architecture: JWT with refresh tokens, OAuth2 password and client-credentials flows, RBAC enforcement at the route level and audit logging for privileged actions.
- Docker with multi-stage builds, docker-compose for local development, GitHub Actions CI with lint + test + build, and health-check endpoints for deployment readiness.
- What you should build
- Build a containerized API service with PostgreSQL, JWT authentication, Alembic migrations, pytest suite with 80%+ coverage, structured JSON logging, a Dockerfile with health checks, and a GitHub Actions CI pipeline. This becomes the foundation for the capstone support workflow — you will extend it in every later stage.
- Ready when
- A different engineer can clone your repository, run `docker-compose up`, execute the test suite, and hit the API endpoint — all from the README, with zero questions to you. The CI pipeline fails on broken code before merge.
- Common mistake
- Building a notebook or a single-file script instead of a service with tests, migrations and CI. SCAI instructors see this pattern repeatedly: learners who can explain FastAPI decorators but cannot answer 'what happens when the database connection drops mid-request?' Production services handle failure; tutorials handle happy paths.
- Acceptance checks
- Another engineer runs `docker-compose up` and the service starts with a health-check endpoint returning 200.
- The pytest suite passes from a clean clone with 80%+ coverage and includes failure-case tests (database disconnect, invalid input, auth failure).
- An authenticated request returns data; an unauthenticated request returns a structured 401 error, not a stack trace.
- A database migration can run forward and rollback without data loss.
- CI pipeline fails on a deliberately broken commit — you cannot merge broken code.
- Related resources
- FastAPI tutorial — validation, security and testing sections — Build the API layer SCAI's FDE course uses as its week-1 foundation
- PostgreSQL tutorial — queries, joins and transactions — Schema design and migrations for customer data
- Docker getting started — multi-stage builds — Reproducible environments that deploy to customer infrastructure
- what a Forward Deployed Engineer does — Understand the role before building the skills
Stage 2: Customer discovery and technical scoping
Turn an ambiguous customer problem into a scoped technical approach with measurable acceptance criteria, a workflow map and a feasibility prototype. This is the capability that separates an FDE from a developer who only writes code.
SCAI's FDE instructors have seen more engagements fail from weak discovery than from weak code. A customer saying 'we want AI to automate support' is not a requirement — it is a starting question. The FDE's job is to decompose it into something buildable, measurable and bounded. If you build the wrong thing, no amount of engineering skill recovers the engagement.
- What you learn
- Stakeholder interviews and workflow mapping: identify who uses the system, what breaks today, where the handoffs are, and which steps are manual vs automated.
- Functional and non-functional requirements with measurable KPIs: ticket categories, knowledge sources, accuracy thresholds, latency budgets, cost-per-request limits and data access constraints.
- Security, data access and integration constraints: which systems hold the data, who controls access, what actions the AI may perform, what requires human approval and what is out of scope.
- Risk register, feasibility prototype for the riskiest assumption, build-versus-buy decisions and delivery sequencing with a phased timeline.
- What you should build
- For the capstone scenario — a B2B company with thousands of support tickets wanting AI-assisted workflow — produce: (1) a discovery brief with stakeholder map and workflow diagram, (2) a requirements document with functional and non-functional requirements, KPIs and acceptance criteria, (3) a risk register with the top 5 risks and mitigation plans, and (4) a feasibility prototype for the riskiest assumption. Use the decomposition example below as a template.
- Ready when
- Another engineer could begin implementation from your scoped requirements without needing to rediscover the core problem. Your acceptance criteria are measurable (not 'improve support' but 'classify 70% of tickets correctly within 2 seconds at $0.02 per request').
- Common mistake
- Jumping to implementation before the problem, success measures and constraints are defined. The second most common mistake: scoping too broadly. 'Automate all support tickets' is not a scope; 'classify tickets into 8 categories and retrieve relevant knowledge for the top 3' is.
- Acceptance checks
- Your discovery brief includes a workflow map with named pain points and bottlenecks — not just 'support is slow'.
- Requirements have measurable KPIs: accuracy threshold, latency budget, cost-per-request and human-review rate.
- You can explain which ticket categories are in scope and which are explicitly out of scope — and why.
- A feasibility prototype exists for the riskiest technical assumption (e.g., 'can we classify tickets with 70% accuracy?').
- Your risk register has at least 5 risks with mitigation plans, not just 'might fail'.
- Related resources
- AI Developer roadmap — If your discovery reveals the problem is primarily an AI application, this track covers the building skills
Stage 3: Solution architecture and enterprise integration
Design the system boundaries, API contracts, access controls and failure handling that connect your software to real customer systems. FDE systems live inside customer infrastructure — integration design determines security, cost and operability.
A demo that works in isolation fails in production. SCAI's FDE course devotes three weeks to integration because it is where most engagement time goes — not model development. The architecture decisions you make here determine whether the system can survive contact with real customer infrastructure: their firewalls, their rate limits, their identity providers, their data residency requirements.
- What you learn
- System architecture: data-flow diagrams, service boundaries, synchronous vs asynchronous patterns and where to place caching, queuing and rate limiting.
- Identity and access: OAuth2 flows, JWT validation, RBAC with route-level enforcement, tenant isolation in multi-customer deployments and audit logging for privileged actions.
- API contracts: typed clients with Pydantic schemas, webhook handling with signature verification, idempotency keys for writes, retry with exponential backoff and jitter, and circuit breakers for dependent services.
- Failure handling: timeout budgets per dependency, partial-failure recovery, dead-letter queues for failed events and graceful degradation when a dependency is unavailable.
- What you should build
- For the capstone, design and implement the integration: connect your API to a simulated CRM (HubSpot or Salesforce API), a knowledge base (document store), and the customer's identity provider (OAuth2). Implement: typed API clients with retry and circuit breaker patterns, idempotency keys for write operations, a permission model with tenant isolation, and structured logging that traces a request across all three systems.
- Ready when
- Your integration connects at least three external systems with authentication. A simulated failure in any one (timeout, 401, 500, rate limit) produces a defined error path with a user-visible message and a logged trace — not a crash. Your architecture document names trust boundaries, data flow, ownership and failure modes for each integration point.
- Common mistake
- Designing in isolation from the customer's identity, security and network policies. What works on localhost with mock data often fails against real customer infrastructure. The second most common mistake: not handling partial failures — when the CRM call succeeds but the knowledge base call fails, what happens to the user request?
- Acceptance checks
- Your integration connects at least two external systems and handles OAuth2 authentication.
- A simulated timeout, 401, 500 and 429 each produce a defined error path — not an unhandled exception.
- Retrying an idempotent write does not create a duplicate record.
- Your architecture document includes a data-flow diagram with trust boundaries marked.
- A circuit breaker prevents cascading failure when a dependency is down for 30+ seconds.
- Related resources
- AI Engineer roadmap — Deeper model and system integration patterns for AI services
- OpenTelemetry signals — Trace requests across integrated systems — essential for debugging customer integrations
- AWS: control and limit retries — Bounded retry patterns that prevent retry storms in customer environments
Stage 4: Applied AI, agents and evaluation
Add AI only where it improves the customer workflow, and prove it with measured evaluation. An FDE chooses between deterministic software and AI based on fit, not novelty. Evaluation — not model selection — is what separates a shipped system from a demo.
AI is the part most learners over-index on. SCAI's FDE course teaches that if you cannot show why your AI works with evidence, you cannot defend it to a customer. The question is never 'does the model work?' but 'what does it cost, where does it fail, and what happens when it fails?' A customer who sees a demo and deploys without evaluation will discover the failure modes in production — with real users.
- What you learn
- Retrieval and RAG: ingestion pipeline with chunking strategy, hybrid search (lexical + vector), reranking, citation tracking and groundedness checks — plus access filtering so users only retrieve from permitted sources.
- Agent and tool-use patterns with human approval: tool schemas with validation, bounded execution loops, side-effect control with idempotency and explicit approval gates for write actions.
- Evaluation: a held-out test set with 30+ cases, classification accuracy, retrieval precision@k, groundedness scoring, latency p50/p95, cost per request and a failure taxonomy categorizing the top error patterns.
- Production concerns: rate limiting with token budgets, fallback models for provider outages, prompt caching for cost reduction, guardrails for prompt injection and PII, and context-window management for long conversations.
- What you should build
- For the capstone, implement a retrieval-augmented classification and action-proposal feature for the support workflow: classify incoming tickets into categories, retrieve relevant knowledge articles, and propose an action (respond, escalate, route). Build an evaluation dataset with 30+ cases covering normal, ambiguous, adversarial and out-of-scope inputs. Report: classification accuracy, retrieval precision@k, groundedness score, latency p50/p95, cost per request and a failure taxonomy with the top 5 failure patterns.
- Ready when
- Your AI feature has a measured evaluation report (not a demo), and you can answer three questions a customer will ask: (1) what does it cost per request, (2) where does it fail and what happens when it fails, (3) when would a non-AI approach be better for this workflow?
- Common mistake
- Applying an LLM or agent to every problem regardless of fit. SCAI instructors see learners build RAG pipelines for problems that needed a SQL query, and agent loops for decisions that should be a simple if-else. The second mistake: evaluating only on easy cases. Your evaluation set must include adversarial inputs, out-of-scope tickets and ambiguous requests — the cases where the system will be tested in production.
- Acceptance checks
- Your evaluation dataset has 30+ cases including adversarial, out-of-scope and ambiguous inputs.
- You can show a measured classification accuracy and retrieval precision@k — not 'it works on the examples I tried'.
- Your cost report shows cost per request, including model API calls, retrieval and any reranking.
- Your failure taxonomy names the top 5 failure patterns and what happens in each (not just 'sometimes wrong').
- You can name at least one case where a non-AI approach would be better and explain why.
- Related resources
- Generative AI roadmap — Deeper LLM, RAG and evaluation fundamentals — the model layer behind Stage 4
- Agentic AI roadmap — Controlled agent patterns with tool permissions, state management and failure recovery
- Forward Deployed Engineer course — SCAI's 20-week program covers this stage with guided evaluation labs and instructor-reviewed AI components
- Anthropic: building effective agents — The workflow-versus-agent decision framework SCAI teaches — read this before building an agent
- LangSmith RAG evaluation tutorial — How to evaluate retrieval quality, grounding and answer correctness separately
Stage 5: Deployment, reliability and production operations
Ship the system into a real environment and keep it observable, releasable and recoverable. Deployment ownership is what separates an FDE from prototype work — the engagement does not end at 'it works on my machine'.
A system that works in a notebook delivers no customer value. SCAI's FDE course includes deployment drills because the handoff cannot happen until the system runs reliably in something resembling the customer's environment. The question a customer asks is not 'can you demo it?' but 'what happens when the model API is down for 30 minutes at 3am?' If you cannot answer that, you cannot hand off.
- What you learn
- CI/CD with staged deployment: GitHub Actions or equivalent, environment separation (dev/staging/prod), secrets management with vault or cloud KMS, and automated deployment with health checks before traffic shifts.
- Observability: structured JSON logs with correlation IDs, OpenTelemetry traces across service boundaries, a Grafana or cloud-native dashboard showing latency p50/p95, error rate, model API status and cost, and alerts tied to user-facing SLOs.
- Failure handling: model API outage with fallback response, database connection pool exhaustion, external API rate limiting (429) with backoff, traffic spikes with autoscaling and cost alerts for unexpected token usage.
- Rollback and recovery: blue-green or canary deployment, automated rollback on health-check failure, incident response runbook with the top 5 scenarios and post-incident review template.
- What you should build
- For the capstone, deploy the support workflow to a cloud environment (AWS, GCP or Azure). Set up: CI/CD pipeline with staged deployment (dev → staging → prod), a monitoring dashboard with request latency, error rate, model API status and cost, alerting on SLO breaches, and a rollback procedure. Then inject three failures and demonstrate recovery: (1) model API unavailable for 5 minutes, (2) database slow (100x normal latency), (3) external CRM API returns 429 rate limit.
- Ready when
- You can deploy the system to a cloud environment, detect each of the three injected failures through monitoring, recover from each within 5 minutes using your runbook, and roll back to a previous working version. Your monitoring dashboard shows the failure and recovery in retrospect.
- Common mistake
- Treating deployment as an afterthought. SCAI instructors see learners who build impressive AI features but cannot answer: what happens when the model API is down? What happens when traffic spikes 10x? What happens when a deployment introduces a regression? The second mistake: deploying without rollback capability — a bad deployment becomes a crisis instead of a 2-minute fix.
- Acceptance checks
- The system is deployed to a cloud environment (not localhost) and accessible via a public URL.
- A monitoring dashboard shows request latency, error rate, model API status and cost in real time.
- You can demonstrate rollback to a previous working version within 5 minutes.
- Injecting a model API outage triggers a fallback response, not a crash — users see a defined message.
- A written runbook covers the top 5 failure scenarios with step-by-step recovery instructions.
- Related resources
- MLOps roadmap — Deeper CI/CD, monitoring and rollback patterns for ML systems
- AIOps roadmap — AI-assisted incident detection and investigation for production systems
- LLMOps roadmap — Operating LLM applications: latency, cost control, failure recovery and SLOs
- Google SRE monitoring — The monitoring framework SCAI's deployment drills are based on
- OpenTelemetry signals — Distributed tracing for debugging cross-system failures
Stage 6: User acceptance, adoption and handoff
Move from 'software deployed' to 'customer successfully using the system.' Handoff quality is what customers remember; evidence of UAT and adoption is what separates delivered work from abandoned prototypes. The engagement is not done when the system runs — it is done when the customer team can run it without you.
SCAI's FDE course ends with a handoff pack review, not a demo. Instructors have seen engagements where the AI worked perfectly but the customer could not operate it — that is a failed engagement, not a successful one. The handoff pack is also what you bring to an FDE interview: it proves you can deliver end to end, not just write code.
- What you learn
- UAT planning: acceptance criteria from Stage 2 turned into executable test cases, customer validation sessions, defect triage with severity levels and sign-off process.
- Operator guide and training: step-by-step instructions for daily operations, common tasks, alert response and user management — tested with someone who did not build the system.
- Operational ownership transfer: support escalation paths, incident response roles, monitoring access and a documented SLA for the receiving team.
- Business outcome measurement: adoption metrics (tickets processed, time saved, accuracy achieved), stakeholder presentation and a feedback loop for iteration planning.
- What you should build
- For the capstone, produce a complete handoff pack: (1) UAT plan with 20+ test cases covering normal, edge and failure scenarios, (2) operator guide with step-by-step instructions for common operations, (3) training notes for the customer team, (4) monitoring runbook with alert response procedures, (5) handoff document listing ownership transfer, support escalation paths and known limitations, and (6) a final presentation showing the business outcome — not the technical features. Have a peer try to operate the system using only the handoff pack.
- Ready when
- A peer can operate your system using only the handoff pack you produced — without asking you a question. You can present the business outcome in one sentence a non-technical stakeholder understands: 'The support workflow now classifies 72% of tickets automatically, reducing average first-response time from 4 hours to 18 minutes at $0.03 per ticket.'
- Common mistake
- Stopping at deployment instead of completing adoption and handoff. The second most common mistake: writing documentation that describes features instead of operations. An operator guide should answer 'what do I do when the alert fires?' not 'what does the classification endpoint do?'
- Acceptance checks
- A peer can operate the system using only the handoff pack — without asking you a question.
- The UAT plan has 20+ test cases covering normal, edge and failure scenarios.
- The operator guide has been tested with someone who did not build the system.
- You can state the business outcome in one sentence a non-technical stakeholder understands.
- The handoff document lists known limitations, not just capabilities — honesty builds trust.
- Related resources
- Google SRE monitoring — Post-launch monitoring that the receiving team needs to operate the system
Stage 1: Software and full-stack foundations
Build a production-grade backend service with typed APIs, database migrations, authentication, structured logging, containerized deployment and a tested CI pipeline — the foundation every FDE engagement depends on.
Every FDE engagement at SCAI starts with shipping a working service. If you cannot build, test and deploy a small API with proper error handling and observability, you cannot own a customer outcome. The gap between 'I can write a FastAPI route' and 'I can ship a service a customer team can operate' is where most learners stall.
- What you learn
- Production Python with FastAPI: Pydantic validation, dependency injection, background tasks, streaming responses and structured exception handlers that return consistent error envelopes.
- PostgreSQL with Alembic migrations: schema versioning, transaction isolation levels, connection pooling, indexed queries and EXPLAIN ANALYZE for slow-query diagnosis.
- Authentication architecture: JWT with refresh tokens, OAuth2 password and client-credentials flows, RBAC enforcement at the route level and audit logging for privileged actions.
- Docker with multi-stage builds, docker-compose for local development, GitHub Actions CI with lint + test + build, and health-check endpoints for deployment readiness.
- What you should build
- Build a containerized API service with PostgreSQL, JWT authentication, Alembic migrations, pytest suite with 80%+ coverage, structured JSON logging, a Dockerfile with health checks, and a GitHub Actions CI pipeline. This becomes the foundation for the capstone support workflow — you will extend it in every later stage.
- Ready when
- A different engineer can clone your repository, run `docker-compose up`, execute the test suite, and hit the API endpoint — all from the README, with zero questions to you. The CI pipeline fails on broken code before merge.
- Common mistake
- Building a notebook or a single-file script instead of a service with tests, migrations and CI. SCAI instructors see this pattern repeatedly: learners who can explain FastAPI decorators but cannot answer 'what happens when the database connection drops mid-request?' Production services handle failure; tutorials handle happy paths.
- Acceptance checks
- Another engineer runs `docker-compose up` and the service starts with a health-check endpoint returning 200.
- The pytest suite passes from a clean clone with 80%+ coverage and includes failure-case tests (database disconnect, invalid input, auth failure).
- An authenticated request returns data; an unauthenticated request returns a structured 401 error, not a stack trace.
- A database migration can run forward and rollback without data loss.
- CI pipeline fails on a deliberately broken commit — you cannot merge broken code.
- Related resources
- FastAPI tutorial — validation, security and testing sections — Build the API layer SCAI's FDE course uses as its week-1 foundation
- PostgreSQL tutorial — queries, joins and transactions — Schema design and migrations for customer data
- Docker getting started — multi-stage builds — Reproducible environments that deploy to customer infrastructure
- what a Forward Deployed Engineer does — Understand the role before building the skills
Stage 2: Customer discovery and technical scoping
Turn an ambiguous customer problem into a scoped technical approach with measurable acceptance criteria, a workflow map and a feasibility prototype. This is the capability that separates an FDE from a developer who only writes code.
SCAI's FDE instructors have seen more engagements fail from weak discovery than from weak code. A customer saying 'we want AI to automate support' is not a requirement — it is a starting question. The FDE's job is to decompose it into something buildable, measurable and bounded. If you build the wrong thing, no amount of engineering skill recovers the engagement.
- What you learn
- Stakeholder interviews and workflow mapping: identify who uses the system, what breaks today, where the handoffs are, and which steps are manual vs automated.
- Functional and non-functional requirements with measurable KPIs: ticket categories, knowledge sources, accuracy thresholds, latency budgets, cost-per-request limits and data access constraints.
- Security, data access and integration constraints: which systems hold the data, who controls access, what actions the AI may perform, what requires human approval and what is out of scope.
- Risk register, feasibility prototype for the riskiest assumption, build-versus-buy decisions and delivery sequencing with a phased timeline.
- What you should build
- For the capstone scenario — a B2B company with thousands of support tickets wanting AI-assisted workflow — produce: (1) a discovery brief with stakeholder map and workflow diagram, (2) a requirements document with functional and non-functional requirements, KPIs and acceptance criteria, (3) a risk register with the top 5 risks and mitigation plans, and (4) a feasibility prototype for the riskiest assumption. Use the decomposition example below as a template.
- Ready when
- Another engineer could begin implementation from your scoped requirements without needing to rediscover the core problem. Your acceptance criteria are measurable (not 'improve support' but 'classify 70% of tickets correctly within 2 seconds at $0.02 per request').
- Common mistake
- Jumping to implementation before the problem, success measures and constraints are defined. The second most common mistake: scoping too broadly. 'Automate all support tickets' is not a scope; 'classify tickets into 8 categories and retrieve relevant knowledge for the top 3' is.
- Acceptance checks
- Your discovery brief includes a workflow map with named pain points and bottlenecks — not just 'support is slow'.
- Requirements have measurable KPIs: accuracy threshold, latency budget, cost-per-request and human-review rate.
- You can explain which ticket categories are in scope and which are explicitly out of scope — and why.
- A feasibility prototype exists for the riskiest technical assumption (e.g., 'can we classify tickets with 70% accuracy?').
- Your risk register has at least 5 risks with mitigation plans, not just 'might fail'.
- Related resources
- AI Developer roadmap — If your discovery reveals the problem is primarily an AI application, this track covers the building skills
Stage 3: Solution architecture and enterprise integration
Design the system boundaries, API contracts, access controls and failure handling that connect your software to real customer systems. FDE systems live inside customer infrastructure — integration design determines security, cost and operability.
A demo that works in isolation fails in production. SCAI's FDE course devotes three weeks to integration because it is where most engagement time goes — not model development. The architecture decisions you make here determine whether the system can survive contact with real customer infrastructure: their firewalls, their rate limits, their identity providers, their data residency requirements.
- What you learn
- System architecture: data-flow diagrams, service boundaries, synchronous vs asynchronous patterns and where to place caching, queuing and rate limiting.
- Identity and access: OAuth2 flows, JWT validation, RBAC with route-level enforcement, tenant isolation in multi-customer deployments and audit logging for privileged actions.
- API contracts: typed clients with Pydantic schemas, webhook handling with signature verification, idempotency keys for writes, retry with exponential backoff and jitter, and circuit breakers for dependent services.
- Failure handling: timeout budgets per dependency, partial-failure recovery, dead-letter queues for failed events and graceful degradation when a dependency is unavailable.
- What you should build
- For the capstone, design and implement the integration: connect your API to a simulated CRM (HubSpot or Salesforce API), a knowledge base (document store), and the customer's identity provider (OAuth2). Implement: typed API clients with retry and circuit breaker patterns, idempotency keys for write operations, a permission model with tenant isolation, and structured logging that traces a request across all three systems.
- Ready when
- Your integration connects at least three external systems with authentication. A simulated failure in any one (timeout, 401, 500, rate limit) produces a defined error path with a user-visible message and a logged trace — not a crash. Your architecture document names trust boundaries, data flow, ownership and failure modes for each integration point.
- Common mistake
- Designing in isolation from the customer's identity, security and network policies. What works on localhost with mock data often fails against real customer infrastructure. The second most common mistake: not handling partial failures — when the CRM call succeeds but the knowledge base call fails, what happens to the user request?
- Acceptance checks
- Your integration connects at least two external systems and handles OAuth2 authentication.
- A simulated timeout, 401, 500 and 429 each produce a defined error path — not an unhandled exception.
- Retrying an idempotent write does not create a duplicate record.
- Your architecture document includes a data-flow diagram with trust boundaries marked.
- A circuit breaker prevents cascading failure when a dependency is down for 30+ seconds.
- Related resources
- AI Engineer roadmap — Deeper model and system integration patterns for AI services
- OpenTelemetry signals — Trace requests across integrated systems — essential for debugging customer integrations
- AWS: control and limit retries — Bounded retry patterns that prevent retry storms in customer environments
Stage 4: Applied AI, agents and evaluation
Add AI only where it improves the customer workflow, and prove it with measured evaluation. An FDE chooses between deterministic software and AI based on fit, not novelty. Evaluation — not model selection — is what separates a shipped system from a demo.
AI is the part most learners over-index on. SCAI's FDE course teaches that if you cannot show why your AI works with evidence, you cannot defend it to a customer. The question is never 'does the model work?' but 'what does it cost, where does it fail, and what happens when it fails?' A customer who sees a demo and deploys without evaluation will discover the failure modes in production — with real users.
- What you learn
- Retrieval and RAG: ingestion pipeline with chunking strategy, hybrid search (lexical + vector), reranking, citation tracking and groundedness checks — plus access filtering so users only retrieve from permitted sources.
- Agent and tool-use patterns with human approval: tool schemas with validation, bounded execution loops, side-effect control with idempotency and explicit approval gates for write actions.
- Evaluation: a held-out test set with 30+ cases, classification accuracy, retrieval precision@k, groundedness scoring, latency p50/p95, cost per request and a failure taxonomy categorizing the top error patterns.
- Production concerns: rate limiting with token budgets, fallback models for provider outages, prompt caching for cost reduction, guardrails for prompt injection and PII, and context-window management for long conversations.
- What you should build
- For the capstone, implement a retrieval-augmented classification and action-proposal feature for the support workflow: classify incoming tickets into categories, retrieve relevant knowledge articles, and propose an action (respond, escalate, route). Build an evaluation dataset with 30+ cases covering normal, ambiguous, adversarial and out-of-scope inputs. Report: classification accuracy, retrieval precision@k, groundedness score, latency p50/p95, cost per request and a failure taxonomy with the top 5 failure patterns.
- Ready when
- Your AI feature has a measured evaluation report (not a demo), and you can answer three questions a customer will ask: (1) what does it cost per request, (2) where does it fail and what happens when it fails, (3) when would a non-AI approach be better for this workflow?
- Common mistake
- Applying an LLM or agent to every problem regardless of fit. SCAI instructors see learners build RAG pipelines for problems that needed a SQL query, and agent loops for decisions that should be a simple if-else. The second mistake: evaluating only on easy cases. Your evaluation set must include adversarial inputs, out-of-scope tickets and ambiguous requests — the cases where the system will be tested in production.
- Acceptance checks
- Your evaluation dataset has 30+ cases including adversarial, out-of-scope and ambiguous inputs.
- You can show a measured classification accuracy and retrieval precision@k — not 'it works on the examples I tried'.
- Your cost report shows cost per request, including model API calls, retrieval and any reranking.
- Your failure taxonomy names the top 5 failure patterns and what happens in each (not just 'sometimes wrong').
- You can name at least one case where a non-AI approach would be better and explain why.
- Related resources
- Generative AI roadmap — Deeper LLM, RAG and evaluation fundamentals — the model layer behind Stage 4
- Agentic AI roadmap — Controlled agent patterns with tool permissions, state management and failure recovery
- Forward Deployed Engineer course — SCAI's 20-week program covers this stage with guided evaluation labs and instructor-reviewed AI components
- Anthropic: building effective agents — The workflow-versus-agent decision framework SCAI teaches — read this before building an agent
- LangSmith RAG evaluation tutorial — How to evaluate retrieval quality, grounding and answer correctness separately
Stage 5: Deployment, reliability and production operations
Ship the system into a real environment and keep it observable, releasable and recoverable. Deployment ownership is what separates an FDE from prototype work — the engagement does not end at 'it works on my machine'.
A system that works in a notebook delivers no customer value. SCAI's FDE course includes deployment drills because the handoff cannot happen until the system runs reliably in something resembling the customer's environment. The question a customer asks is not 'can you demo it?' but 'what happens when the model API is down for 30 minutes at 3am?' If you cannot answer that, you cannot hand off.
- What you learn
- CI/CD with staged deployment: GitHub Actions or equivalent, environment separation (dev/staging/prod), secrets management with vault or cloud KMS, and automated deployment with health checks before traffic shifts.
- Observability: structured JSON logs with correlation IDs, OpenTelemetry traces across service boundaries, a Grafana or cloud-native dashboard showing latency p50/p95, error rate, model API status and cost, and alerts tied to user-facing SLOs.
- Failure handling: model API outage with fallback response, database connection pool exhaustion, external API rate limiting (429) with backoff, traffic spikes with autoscaling and cost alerts for unexpected token usage.
- Rollback and recovery: blue-green or canary deployment, automated rollback on health-check failure, incident response runbook with the top 5 scenarios and post-incident review template.
- What you should build
- For the capstone, deploy the support workflow to a cloud environment (AWS, GCP or Azure). Set up: CI/CD pipeline with staged deployment (dev → staging → prod), a monitoring dashboard with request latency, error rate, model API status and cost, alerting on SLO breaches, and a rollback procedure. Then inject three failures and demonstrate recovery: (1) model API unavailable for 5 minutes, (2) database slow (100x normal latency), (3) external CRM API returns 429 rate limit.
- Ready when
- You can deploy the system to a cloud environment, detect each of the three injected failures through monitoring, recover from each within 5 minutes using your runbook, and roll back to a previous working version. Your monitoring dashboard shows the failure and recovery in retrospect.
- Common mistake
- Treating deployment as an afterthought. SCAI instructors see learners who build impressive AI features but cannot answer: what happens when the model API is down? What happens when traffic spikes 10x? What happens when a deployment introduces a regression? The second mistake: deploying without rollback capability — a bad deployment becomes a crisis instead of a 2-minute fix.
- Acceptance checks
- The system is deployed to a cloud environment (not localhost) and accessible via a public URL.
- A monitoring dashboard shows request latency, error rate, model API status and cost in real time.
- You can demonstrate rollback to a previous working version within 5 minutes.
- Injecting a model API outage triggers a fallback response, not a crash — users see a defined message.
- A written runbook covers the top 5 failure scenarios with step-by-step recovery instructions.
- Related resources
- MLOps roadmap — Deeper CI/CD, monitoring and rollback patterns for ML systems
- AIOps roadmap — AI-assisted incident detection and investigation for production systems
- LLMOps roadmap — Operating LLM applications: latency, cost control, failure recovery and SLOs
- Google SRE monitoring — The monitoring framework SCAI's deployment drills are based on
- OpenTelemetry signals — Distributed tracing for debugging cross-system failures
Stage 6: User acceptance, adoption and handoff
Move from 'software deployed' to 'customer successfully using the system.' Handoff quality is what customers remember; evidence of UAT and adoption is what separates delivered work from abandoned prototypes. The engagement is not done when the system runs — it is done when the customer team can run it without you.
SCAI's FDE course ends with a handoff pack review, not a demo. Instructors have seen engagements where the AI worked perfectly but the customer could not operate it — that is a failed engagement, not a successful one. The handoff pack is also what you bring to an FDE interview: it proves you can deliver end to end, not just write code.
- What you learn
- UAT planning: acceptance criteria from Stage 2 turned into executable test cases, customer validation sessions, defect triage with severity levels and sign-off process.
- Operator guide and training: step-by-step instructions for daily operations, common tasks, alert response and user management — tested with someone who did not build the system.
- Operational ownership transfer: support escalation paths, incident response roles, monitoring access and a documented SLA for the receiving team.
- Business outcome measurement: adoption metrics (tickets processed, time saved, accuracy achieved), stakeholder presentation and a feedback loop for iteration planning.
- What you should build
- For the capstone, produce a complete handoff pack: (1) UAT plan with 20+ test cases covering normal, edge and failure scenarios, (2) operator guide with step-by-step instructions for common operations, (3) training notes for the customer team, (4) monitoring runbook with alert response procedures, (5) handoff document listing ownership transfer, support escalation paths and known limitations, and (6) a final presentation showing the business outcome — not the technical features. Have a peer try to operate the system using only the handoff pack.
- Ready when
- A peer can operate your system using only the handoff pack you produced — without asking you a question. You can present the business outcome in one sentence a non-technical stakeholder understands: 'The support workflow now classifies 72% of tickets automatically, reducing average first-response time from 4 hours to 18 minutes at $0.03 per ticket.'
- Common mistake
- Stopping at deployment instead of completing adoption and handoff. The second most common mistake: writing documentation that describes features instead of operations. An operator guide should answer 'what do I do when the alert fires?' not 'what does the classification endpoint do?'
- Acceptance checks
- A peer can operate the system using only the handoff pack — without asking you a question.
- The UAT plan has 20+ test cases covering normal, edge and failure scenarios.
- The operator guide has been tested with someone who did not build the system.
- You can state the business outcome in one sentence a non-technical stakeholder understands.
- The handoff document lists known limitations, not just capabilities — honesty builds trust.
- Related resources
- Google SRE monitoring — Post-launch monitoring that the receiving team needs to operate the system
Capstone
From API to handoff: build one evolving AI-assisted support system
The scenario
A B2B company receives thousands of technical support requests. They want an AI-assisted workflow that classifies tickets, retrieves authoritative knowledge, checks account context, proposes actions, calls approved internal tools and escalates uncertain or high-risk cases to humans.
Ship a tested service with PostgreSQL, auth and CI
Map the support workflow, write acceptance criteria
Connect knowledge base, CRM and identity provider
Classify tickets, retrieve knowledge, evaluate with 30+ cases
Deploy with monitoring, inject failures, demonstrate rollback
Run UAT, measure adoption, hand off with a complete pack
What this proves in an interview
You can ship a service, scope a problem, integrate with real systems, evaluate AI honestly, deploy reliably and hand off cleanly. One evolving project across all six stages carries more weight than six disconnected tutorials — it proves end-to-end delivery ownership.
Market demand
Is Forward Deployed Engineering in demand?
Pioneered the FDSE model — engineers embedded with customers from architecture through deployment.
Hires FDEs who own technical discovery, implementation, evaluation, production deployment and handoff.
Announced a $1 billion investment in Forward Deployed Engineering in 2026.
There is no reliable global market-size estimate for FDE roles. These are verified demand signals from companies that publish their FDE hiring, not an invented market-size figure. Role requirements vary: one current Palantir posting asks for 1+ years of experience and up to 25% travel; an OpenAI healthcare FDE posting asks for 6+ years and up to 50% travel.
Sources reviewed 15 September 2026. Individual job requirements may change. For a deeper analysis of what the role involves, read what a Forward Deployed Engineer does.
Training alignment
How this roadmap aligns with SCAI's FDE course
| Stage | This roadmap (free) | FDE course adds |
|---|---|---|
| Stages 1-2 | Self-guided discovery exercises | Simulated stakeholder interviews with instructor challenges |
| Stage 3 | Simulate customer infrastructure yourself | Pre-built customer environment with real auth and rate limits |
| Stage 4 | Evaluation criteria but no feedback | Instructor reviews your evaluation dataset and failure taxonomy |
| Stages 5-6 | Find a peer for handoff testing | Deployment drills with failure injection + handoff pack review |
This roadmap is free and self-paced. SCAI's 20-week Forward Deployed Engineer course covers the same six stages with live instruction, simulated client work, instructor-reviewed evaluation labs and a reviewed capstone. Here is what the course adds that the roadmap cannot:
Want structured review of each stage with instructor feedback?
Explore the 20-Week FDE CourseWhat to read next
What to read next
Application construction with model APIs, retrieval and tools
Reproducible training pipelines, model releases and monitoring
AI-assisted incident detection and investigation for production systems
After completing this roadmap, your next step depends on which capability you want to deepen. The AI Developer roadmap covers application construction with model APIs, retrieval and tools. The MLOps roadmap covers reproducible training pipelines, model releases and monitoring. The AIOps roadmap covers AI-assisted incident detection and investigation for production systems.
FAQ
Forward Deployed Engineer Roadmap FAQs
Direct answers about the FDE roadmap, career path and how it compares to related roles.
How is an FDE different from an AI engineer?
An FDE owns a customer-specific problem end to end — from discovery through deployment and handoff. An AI engineer builds AI systems and capabilities for many users. AI is one part of the FDE toolkit, but many FDE engagements involve data integration, workflow automation and production reliability rather than model development. Employers use these titles differently. If you want to build both skill sets with guided projects, SCAI's FDE course covers the customer-delivery layer that the AI Engineering course does not.
Is Forward Deployed Engineering a beginner role?
No. FDE work requires you to ship a working service, integrate with customer systems and own deployment. This roadmap assumes software foundations — you should be able to build a tested API with authentication before starting Stage 2. Beginners should first complete the AI Roadmap for Beginners or build a deployed application with tests and CI. If you have the foundations but need structured progression through customer discovery and handoff, the 20-week FDE course starts from where a working engineer is.
Does every FDE project need AI or agents?
No. Use AI only where it provides a measured benefit over a simpler solution. SCAI's instructors see learners default to RAG and agents for problems that needed a SQL query or a rule-based classifier. Many FDE engagements are primarily data integration, workflow automation and reliability work. The FDE course teaches this judgement — when to use AI, when not to, and how to evaluate the difference with a 30+ case evaluation set.
How technical is the customer-facing work in FDE?
It is deeply technical. Discovery is not just talking to users — it involves reading security policies, designing integration boundaries, mapping data access constraints and writing acceptance criteria with measurable KPIs. You debug infrastructure failures, write production code and handle deployment. Customer communication happens alongside technical work, not instead of it. The FDE course's discovery sprint pairs you with a simulated stakeholder who challenges your assumptions — something self-study cannot replicate.
What should an FDE portfolio demonstrate?
One evolving project across all six stages: a working service with tests and CI, an integration with documented failure behaviour, a justified AI component with a 30+ case evaluation set (not a demo), a deployment with monitoring and rollback evidence, and a handoff pack another person can use to operate the system. This carries more weight than six disconnected tutorials because it proves end-to-end delivery ownership. The FDE course's capstone review gives you instructor feedback on exactly this — your evaluation set, your deployment drills and your handoff pack.
How long does it take to prepare for an FDE role?
It is self-paced and depends on your starting point. Engineers with production backend experience may need a few months focused on discovery, evaluation and handoff. Engineers newer to services or customer-facing work need longer. Use the stage readiness checks to decide when to advance. If you want a structured timeline with weekly milestones, instructor feedback and a reviewed capstone, the 20-week FDE course provides exactly that pace.
What should I learn after this roadmap?
Depends on your gap. For deeper AI application skills, follow the Generative AI roadmap. For controlled agent patterns, follow the Agentic AI roadmap. For operating LLM applications in production, follow the LLMOps roadmap. For the broader engineering track, follow the AI Engineer roadmap. If you want structured review of all six stages with instructor feedback, simulated client work and a reviewed capstone, explore SCAI's 20-week FDE course.