Forward deployed engineer skills checklist: RAG, evals, MCP, observability
The market signal has changed. Strong AI-forward FDEs are no longer judged only on demos and integrations. They are increasingly expected to audit workflows, build retrieval and tool layers, define evals, instrument production behavior, and teach customers how to operate what they shipped.
Why this page exists now
Fresh job signals point in the same direction. OpenAI’s current FDE postings emphasize end-to-end deployments, eval-driven feedback, production rollout, and codifying repeatable patterns. Anthropic’s Applied AI FDE posting is even more explicit: it names customer-facing deliverables like MCP servers, sub-agents, and agent skills. Google Cloud’s current generative AI field roles likewise emphasize prototypes, model tuning, RAG-style architecture, deployment, and reusable technical assets.
Interpretation: the modern FDE bar is becoming more artifact-heavy. Teams want engineers who can make the workflow real, not just explain the model.
Fast test: if a candidate can only talk about prompting but cannot describe eval sets, tool boundaries, rollback paths, or instrumentation, they are probably not at the current AI-forward FDE bar.
1) Workflow audit
The first skill is not model choice. It is workflow clarity. Good FDEs can identify the business step, the input/output contract, the approval boundary, and the failure cost before they start building.
- Can ship: map the existing workflow, data path, and human checkpoints.
- Can harden: identify constraints like latency, privacy, auditability, offline requirements, and ownership gaps.
- Can teach: explain to a customer why “build an agent” is not yet a scoped implementation plan.
2) Retrieval and context assembly
Most applied AI deployments fail because the model sees the wrong context, stale context, or too much context. FDEs do not need to worship RAG as a buzzword, but they do need to understand how the retrieval layer affects system quality.
- Can ship: build document ingestion, chunking, indexing, and prompt assembly for a real workflow.
- Can harden: reason about data freshness, permission boundaries, bad retrieval, and fallback behavior.
- Can teach: explain why retrieval quality is often more important than another round of prompt tweaking.
3) Evals and failure taxonomy
Evals are no longer optional if the role touches production AI. Strong FDEs can create a golden set, name failure types, and use those failures to guide model, prompt, or tool changes.
- Can ship: define a representative eval set and score the system against it.
- Can harden: track failure categories like wrong tool use, missing context, hallucinated outputs, and brittle edge cases.
- Can teach: align product, customer, and engineering stakeholders on what “better” means.
For the broader loop behind this skill, see Audit, Evals, Deployment: The Operating Loop Behind Applied AI Deployments.
4) MCP or tool-adapter engineering
Whether a team calls them MCP servers, tools, adapters, connectors, or internal actions, the same underlying skill matters: the FDE has to make external systems usable by the model safely and repeatably.
- Can ship: connect business systems, wrap actions in clear contracts, and expose the right operations to the workflow.
- Can harden: handle auth boundaries, retries, idempotency, partial failure, and safe action limits.
- Can teach: show the customer which tool paths are safe to automate and which still need review.
5) Observability and rollback
If the system breaks in production, the FDE needs to know where and why. That means logs, traces, human-review lanes, alerts, and the ability to degrade safely.
- Can ship: instrument prompts, tool calls, response states, and key workflow outcomes.
- Can harden: build rollback paths, manual-review fallbacks, and drift checks when data or behavior changes.
- Can teach: hand the customer an operating model they can monitor without needing the FDE in every incident.
6) Customer execution and transfer
The customer-facing side of the role still matters. Modern FDEs are not only builders. They are translators between customer pressure, technical tradeoffs, and product direction.
- Can ship: move from discovery to scoped delivery with clear tradeoffs.
- Can harden: convert one-off customer pain into repeatable patterns, templates, or shared tooling.
- Can teach: transfer the new workflow so the customer team can actually operate it after the first deployment.
How to use this checklist in interviews
Use the checklist as an artifact filter, not a keyword filter. Ask the candidate to walk through one deployment and show the evidence.
- What was the workflow audit artifact?
- How did retrieval or context assembly work?
- What failures were in the eval set?
- Which tool or MCP boundaries were risky?
- What logs or alerts made production issues visible?
- What became reusable after the engagement?
If you are hiring, pair this with How To Write A Forward Deployed Engineer Job Description. If you are interviewing, pair it with Forward Deployed Engineer Interview Guide.
Sources
- OpenAI careers: Forward Deployed Engineer (FDE) - SF
- OpenAI careers search: current FDE roles
- Anthropic: Forward Deployed Engineer, Applied AI
- Google Careers: Field Solutions Architect, Generative AI, Google Cloud
- Google Careers: Field Solutions Architect, Generative AI (English, Korean)
The question
Which part of this checklist is your team weakest at right now: workflow audit, retrieval, evals, tool boundaries, or production observability?
Get the next FDE role brief
Role teardowns, career maps, and field notes for engineers who live at the customer.