Appearance
00.2 — AI FDE Competency Map
The core identity
AI FDE = AI Engineer + Production Engineer + Solution Architect + Customer-Facing Problem Solver
The role originates from Palantir's "Forward Deployed Engineer" model — engineers embedded directly in a customer's environment and workflow, rather than sitting behind a generic product team building features in the abstract. AI FDE is that same model applied to LLM-based systems: you don't ship a chatbot SDK to the world, you sit with one hospital, one bank, one logistics company, learn exactly how their claims/underwriting/support process actually works, and build the specific system that fits it — then make it survive contact with their production environment, their compliance team, and their existing SaaS stack.
The reason this role exists at all: generic AI products underperform in the enterprise because enterprise problems are never generic. Two banks with "the same" fraud-review chatbot requirement will have different data sources, different auth systems, different regulatory constraints, and different definitions of what a "good" answer even looks like. Someone has to bridge that gap, and that person needs enough engineering depth to build the real thing, not just prototype it — because in FDE work, the prototype often ships.
The five competency layers
Layer 5 · FDE / Customer-FacingDiscovery, requirements, feasibility, solution architecture, demos, deployment, iteration, measuring business impact
Layer 4 · Enterprise & System DesignAuth/RBAC/SSO, data pipelines, CRM/ERP, multi-tenant design, architecture trade-offs under real constraints
Layer 3 · Production & ReliabilityDocker/K8s/CI-CD, scaling, cost control, evals, observability, guardrails, security
Layer 2 · AI EngineeringLLMs, prompting, structured output, tool calling, RAG, agents, MCP, memory, multimodal — built with LangChain/LangGraph/LangSmith
Layer 1 · Software Engineering FoundationPython, APIs, SQL, Git, Linux, testing, databases
Each layer depends on the one below it. A weak Layer 1 shows up as bugs in Layer 3. A weak Layer 3 shows up as an outage during a customer's board demo. A weak Layer 4 shows up as a great prototype that a customer's security team refuses to let into production. Layer 5 is what turns all of that engineering into something a non-technical stakeholder will actually pay for and keep using.
What "good" looks like at each layer
| Layer | A junior AI engineer | An AI FDE |
|---|---|---|
| Software Eng | Writes working Python | Writes Python that survives someone else reading it under a deadline, with tests and clear failure modes |
| AI Engineering | Can call an LLM API and get RAG working on a demo dataset | Knows why the RAG pipeline will silently degrade on the customer's real (messy, inconsistent, huge) documents |
| Production | Ships to localhost, calls it done | Assumes the customer's environment is hostile: no internet egress, strict RBAC, unknown load patterns, someone else's outdated dependency pins |
| Enterprise | Has never seen a real SSO integration | Can read a customer's IdP config and know which OAuth flow will actually work |
| FDE Layer | Answers "can you build X" literally | Asks five questions before answering, because the customer usually asked for the wrong X |
Skills that are often underrated by AI engineers but critical for FDE work
- Reading a business process before touching a tool. Most bad AI projects come from skipping this.
- Data engineering. The LLM is rarely the hardest part of an enterprise AI system — getting the customer's documents, databases, APIs, and permissions into a reliable pipeline usually is.
- Saying no to RAG/agents. A significant part of FDE judgment is recognizing when the customer's problem doesn't need either.
- Security and compliance literacy. Enterprise deployments live or die on data privacy, auth, and tenant isolation — this is covered as deeply as the AI engineering itself (Part 9).
- Written and verbal communication with non-technical stakeholders. You will explain a vector database to a VP of Operations. Part 12 teaches this explicitly.
How to read your own current position
If you are already a practicing AI engineer (comfortable with LangChain/LangGraph/LangSmith), you are strong in Layer 2 and should move quickly through Parts 1–2, spend real time in Parts 3–6 on the internals and production patterns you may have skipped, and treat Parts 7–15 as the material that differentiates an AI engineer from an AI FDE.