Glossary — The Forward Deployed Engineer Track

Forward Deployed Engineer — FDE: An engineer who embeds with a customer and builds production software directly on that customer's problems — "half engineer, half consultant, full owner." Unlike a product engineer (one capability for many customers), an FDE enables many capabilities for a single customer. In 2026 the role centers on deploying AI systems: prototypes, agents, integrations, and the evals that prove they work.
FDSE — Forward Deployed Software Engineer: Palantir's original name for the role (internally "Deltas"), embedded on customer sites configuring and extending the product against real operational problems. The template every AI-era FDE role descends from.
Solutions architect — SA, vs FDE: A customer-facing technical role that advises, designs, and demos — but typically does not write production code on customer infrastructure. The FDE boundary line: an FDE ships working code into the customer's world; an SA guides someone else's hands.
AI judgment: The competency of telling when AI is the wrong answer — recognizing that models are persuasive even when incorrect, and having the courage to say so to a customer. A named thread of this course: it shows up in scoping ("don't build this"), in hardening (confidently-wrong outputs), and in the capstone's required "what we recommended NOT to build" section.
Problem discovery: Finding the real problem behind what the customer asks for — separating what they think they want from what they actually need, then articulating it clearly. The make-or-break FDE interview round (often called the decomposition round), and the fastest-growing requirement in FDE job postings.
The deployment gap: The 2026 finding, from an analysis of 1,000 FDE job posts, that ~95% of enterprise GenAI pilots show no measurable impact — model capability isn't the bottleneck, deployment is. The market force behind FDE hiring: someone has to close the gap between what models can do and what actually ships inside an enterprise.
Field practice: The small real-workplace reps at the end of every lesson: asking "why" before a ticket, volunteering for unscoped work, explaining a trade-off to a non-technical colleague. Labs simulate FDE work; field practice builds the same muscles inside the job you already have.
Portfolio artifact: The tangible output of each lab — working code, an eval harness, a demo, a scoping doc — accumulated in your portfolio repo. Each doubles as hiring evidence and an interview story; the capstone assembles them into a full engagement case study.
Context engineering: Deliberately curating everything the model sees — instructions, retrieved documents, tool definitions, history — treating the context window as a finite budget. Subsumes prompt engineering: the question shifts from "what do I say?" to "what does the model need in view, and what must stay out?"
Agent — vs workflow: An LLM system that directs its own tool use in a loop to pursue a goal, versus a workflow where code orchestrates fixed LLM steps. The canonical guidance: use the simplest thing that works — workflows for predictable tasks, agents where paths can't be enumerated in advance.
MCP — Model Context Protocol: The open protocol for connecting AI applications to tools and data sources through a standard interface. For an FDE, MCP servers are the integration seam: wrap the customer's messy systems once, and any MCP-capable model or app can use them.
RAG — retrieval-augmented generation: Answering with the model grounded in retrieved documents rather than parametric memory. Quality lives in the retrieval half — chunking, contextual retrieval, reranking — not the generation half. Not always the right tool: sometimes long context, tools, or "don't use AI" wins.
Grounding: Constraining model output to verifiable sources — mandatory citations, direct quotes, and an explicit "allow I don't know" escape hatch. The primary defense against hallucination in customer-facing systems.
Eval — evaluation: A repeatable, graded test of an LLM system against defined success criteria — exact-match checks, similarity scores, or an LLM judge. The FDE's real deliverable: a demo shows it can work once; an eval proves it keeps working. Evals gate every change made in the field.
LLM-as-judge: Using a model to grade another model's outputs against a rubric. Powerful and dangerous: the judge must itself be validated against human judgments (critique shadowing) before its scores mean anything.
Guardrail: A layer that constrains what goes into or comes out of a model — input filtering, output validation, citation checks, human-in-the-loop gates. Placed around the model because prompting alone cannot make a persuasive model safe.
Prompt injection: Adversarial instructions smuggled into content the model processes — a document, an email, a tool result — that hijack its behavior. The signature security failure of LLM systems, and unsolved in the general case: assume any untrusted content the model reads is potentially hostile.
Synthetic data: Model-generated data shaped like the customer's real data — fake patient records, consult transcripts, claims. A core FDE skill: you rarely get production data in week one, and regulated domains may never hand it over. You demo and eval on synthetic data that is realistic where it matters.
Engagement: The full arc of FDE fieldwork with one customer: discovery → scoping → prototype → evals → hardening → deployment → case study. The capstone runs one end-to-end for a fictional virtual-care provider.