RAG, Evals, and Agents: The AI Skills Every FDE Must Master

The technical core of forward deployed engineering is not training models. It is four skills that decide whether a strong model actually works inside a customer's environment: retrieval-augmented generation to ground answers in the customer's data, evaluation to prove the system works, agents and tool use to let it take action, and a working grasp of cost and latency so it survives production. Master these and you cover the bulk of the technical loop. Below is what good looks like for each and how it shows up when you interview. For practice questions, go straight to RAG and agent design and the LLM and GenAI sets.

Retrieval-augmented generation: grounding in the customer's reality

RAG is the workhorse of FDE work because customers do not want a model that knows the internet. They want one that answers from their data: their policies, their tickets, their documents. Retrieval-augmented generation fetches the relevant pieces and feeds them to the model so the answer is grounded in real sources instead of the model's memory.

What good looks like is the ability to debug it, not just draw the boxes. You should be fluent in chunking choices, the difference between keyword search and vector search over embeddings, and why hybrid search plus a reranking step usually beats either alone. More importantly, you should know the failure modes cold. The two that bite in production: the system surfacing a document the asking user has no permission to see, and the model confidently citing a retrieved chunk that does not actually support its claim. An interviewer who hears you volunteer those failure modes knows you have run a real RAG system, not read about one. If the underlying terms are fuzzy, the concepts library breaks each one down.

Evals: how you earn trust

Evaluation is the skill that separates someone who can demo from someone who can ship. A demo proves the system can succeed once. An eval suite proves it does not fail in the ways that would embarrass your customer in front of theirs.

Good eval work starts with a real test set, not a vibe. You pull genuine cases from the customer's domain across three buckets: the easy ones, the ambiguous ones, and the adversarial ones where the correct answer is "the source does not say." You run the system and you read the failures, not just the aggregate. A 92 percent pass rate is meaningless if the failing 8 percent are all the high-stakes questions. When the task is open-ended, you might use an LLM as a judge, but the strong candidate immediately names that judge's weaknesses, like a bias toward longer answers, and explains how they would validate it against human labels on a sample. This is the answer to the question every stakeholder eventually asks: how do you know it works. The evals category in the must-know set drills exactly this reasoning.

Agents and tool use: power with restraint

Agents let a model take actions: call a function, query a database, file a ticket, then decide what to do next based on the result. They are powerful and they are over-applied, and interviewers know it.

What good looks like here is restraint. The strong candidate reaches for an agent only when the task genuinely needs multi-step tool use with branching decisions, and otherwise prefers a simpler, more predictable chain. When an agent is warranted, you talk about clear tool boundaries, a hard termination condition so it cannot loop forever, and error handling for when a tool call fails or returns garbage. The detail that marks real experience is idempotency. The moment an agent can take real actions in a customer system, a naive retry that double-charges a customer or double-files a ticket stops being hypothetical. You design for it with idempotency keys. Reaching for a multi-agent swarm on a task a single chain would handle is a reliable red flag, and it shows up in the RAG and agent design round constantly.

Decision: do you need an agent?
  Single call answers it           -> just call the model
  Fixed sequence of known steps    -> a chain, not an agent
  Branching, tool results drive    -> agent, with limits:
      next step                       - explicit tool boundaries
                                      - termination condition
                                      - idempotent actions
                                      - failure handling per tool

Cost and latency: where strong candidates quietly fail

This is the skill that gets the least study time and causes the most silent rejections. You can design a beautiful RAG-plus-agent system and lose the room when the interviewer asks what it costs at a million queries a day and you have no framework.

Good means closing every design with rough numbers. Estimate tokens per query, multiply by the per-token price of your chosen model, and multiply by volume to get a per-day cost the customer can react to. Then state a latency budget: if a user is waiting on a response, every extra retrieval hop and every agent step adds to p95, and a chatty agent that takes eight seconds will not ship no matter how accurate it is. The moves you reach for are concrete: caching, a smaller model for the easy cases with escalation to a larger one, and cutting unnecessary agent steps. You do not need exact figures. A defensible back-of-envelope number proves you think about production, which is the entire reason the role exists.

How these fit together in the loop

These four are not separate trivia. A typical FDE design round hands you a vague customer problem and watches you reach for them in sequence: scope the problem, ground it with retrieval, decide whether it needs an agent, plan how you will prove it works with evals, and close with the cost and latency story. Strong candidates move through that arc naturally because it is how the actual job runs.

If you want to build the instinct, do not study these as a reading list. Work real questions until the moves are automatic. Start with RAG and agent design for the modal design round, layer in the LLM and GenAI fundamentals, and keep the concepts library open for anything that still feels shaky.