Forward Deployed Engineer  /  AI App Patterns
FDE Track 12~14 min readIntermediate
The Modern FDE Toolkit

Put AI to work on
the customer’s mess.

Most FDE deployments now share a shape: take an LLM and point it at the customer’s messy, specific data. Retrieval over their documents, an agent that drives one of their workflows, evals that decide whether it’s good enough to ship. This is the applied-AI toolkit every modern FDE reaches for — and how to choose among its parts.

01

The modern FDE runs on AI

A decade ago an FDE integrated software with software. Today, an enormous share of deployments have the same core: take a capable LLM and put it to work on the customer’s specific, messy data. The customer has documents no search can navigate, a workflow that eats an analyst’s afternoon, a decision made by reading unstructured text. The FDE’s job is to aim modern AI at exactly that — and the toolkit for doing so has settled into three reliable patterns.

This handbook is a map of that toolkit, written for the FDE who needs to choose and apply the patterns, not invent them. Each pattern has its own deep handbook on this site; here we cover what each is for, when to reach for it, and how they fit together into a solution you can honestly ship.

02

The three patterns

Retrieval, agents, and evals. Almost every AI-shaped FDE deployment is some combination of these.

PatternWhat it doesThe FDE uses it to…
RAGRetrieve relevant chunks of the customer’s documents and ground the model’s answer in themAnswer questions over their knowledge without retraining, and stay current as docs change
AgentsLet the model drive a multi-step workflow by calling tools, deciding what to do nextAutomate a workflow that’s more than one call — with a human in the loop for the risky steps
EvalsScore the system’s output against a representative test setDecide if it’s good enough to ship, and catch regressions when a prompt or model changes

They compose: a typical deployment is a RAG system, sometimes wrapped in an agent that also calls the customer’s tools, gated by an eval that proves it clears the success bar. Understanding each — and, crucially, when not to reach for the fancier one — is the applied-AI half of the modern role.

03

RAG over the customer’s documents

Retrieval-augmented generation is the workhorse. The customer has a body of knowledge — policies, manuals, tickets, contracts — and wants the model to answer using it, accurately and with citations. RAG does this without retraining: chunk the documents, embed them, retrieve the chunks most relevant to a question, and hand them to the model as grounding so the answer comes from the customer’s truth rather than the model’s guesswork.

→ The FDE’s RAG concerns

Two land squarely on you. Chunking + retrieval quality — bad retrieval means confidently wrong answers, so this is where most of the tuning goes. And access control — a user must only retrieve documents they’re allowed to see, which becomes a real security requirement in a multi-team deployment, not an afterthought.

RAG is usually the first thing to try because it’s fast to stand up, grounds the model in verifiable sources, and updates the moment the documents do. The trade-offs versus other approaches are the subject of the RAG vs fine-tuning handbook.

04

Agents for workflows

When the task is more than “answer a question” — when it involves several steps, decisions, and actions in the customer’s systems — you reach for an agent: a model that can call tools, observe the results, and decide what to do next. An agent might read a ticket, look up a record, draft a response, and file it — the kind of multi-step workflow that used to need a human at every hop.

Agents are powerful and easy to over-reach with. The FDE discipline is to use the least autonomy that solves the problem: a fixed workflow with one model call beats a free-roaming agent when the steps are known, because it’s more predictable and easier to debug. And for any consequential action — sending an email, moving money, changing a record — keep a human in the loop. Two site handbooks go deep here: agent patterns for the how, and agents vs workflows for the crucial when-not-to.

05

Evals as the acceptance test

This is the pattern engineers skip and regret. Evals are how "it seems to work" becomes a number you can stand behind.

An AI system without evals is a system you can’t honestly ship, because “it looks good in the demo” doesn’t survive contact with real inputs. An eval is a set of representative examples plus a way to score the output — a test suite for behavior that’s fuzzy rather than exact. For an FDE, it’s the bridge back to discovery: the success metric everyone agreed on becomes the eval you measure against.

What evals give you

  • An objective answer to “is it good enough?” — tied to the agreed metric.
  • A regression guard when you change a prompt, model, or retrieval.
  • Evidence the customer’s stakeholders can trust.

How to start

  • Collect real examples with known-good answers from the customer.
  • Pick a scoring method (exact match, an LLM judge, a task metric).
  • Run it on every change; make the number visible.

Evals turn AI from a vibe into engineering. They’re deep enough to warrant their own study — agent evals and evals in CI — and worth building a reflex for on the interactive challenges.

06

Choose the pattern — and ship honestly

The meta-skill is restraint: reach for the simplest pattern that clears the bar. A well-crafted prompt beats RAG when the knowledge fits in context; RAG beats fine-tuning when the need is knowledge, not behavior; a fixed workflow beats an agent when the steps are known. Complexity is a cost you pay in reliability and debuggability, so add it only when a simpler pattern demonstrably falls short.

If the need is…Reach for…
The model to behave / format differentlyBetter prompting, then fine-tuning
Answers grounded in the customer’s documentsRAG
A multi-step workflow with actionsAn agent (least autonomy that works)
To know if any of it is good enoughEvals — always

And ship it honestly. Most AI solutions aren’t perfect, and that’s fine if the workflow is designed so mistakes are caught, not blindly acted on. Define the good-enough bar in discovery, keep a human in the loop for consequential decisions, be upfront about failure modes, and — because the model reads untrusted customer content — treat every input as potentially adversarial (the security handbook covers prompt injection). An FDE who ships an honest 85% that safely handles the other 15% delivers real value; one who oversells a fragile 95% loses the customer the first time it breaks. That honesty — about what the system can and can’t do — is the last piece of the whole FDE craft.

Frequently asked

Quick answers

What AI patterns does a forward deployed engineer use most?

Three dominate. RAG (retrieval-augmented generation) puts an LLM to work over the customer’s own documents by retrieving relevant chunks and grounding answers in them. Agents let a model drive a multi-step workflow by calling tools, with a human in the loop for consequential actions. And evals — a test set with a scoring method — act as the acceptance test that decides whether the solution is good enough to ship.

When should you use RAG versus fine-tuning?

Reach for RAG when the need is knowledge — the model must answer using the customer’s specific, changing documents; retrieval grounds it without retraining and updates as the documents do. Reach for fine-tuning when the need is behavior or format — a consistent style, structure, or task the base model doesn’t do well. Most FDE deployments start with prompting plus RAG, and only fine-tune if a clear behavioral gap remains.

What are evals and why do they matter to an FDE?

An eval is a set of representative examples plus a way to score the model’s output against them — effectively a test suite for an AI system. For an FDE, evals are the acceptance test: they turn "it seems to work" into a measured number tied to the success metric agreed in discovery. They also catch regressions when you change a prompt or model, and give the customer objective evidence the solution is good enough.

How do you ship an AI solution honestly when it isn’t 100% accurate?

Define a good-enough bar in discovery (e.g. "85% correct with the rest flagged for a human saves four hours a day"), design the workflow so the model’s mistakes are caught rather than acted on blindly, and keep a human in the loop for consequential decisions. Be upfront about failure modes and measure them with evals. An AI system that is honestly 85% accurate and safely handles the other 15% beats one that pretends to be perfect.

AI App Patterns for FDEs · part of the FDE track · Vibe Engines · 2026
Finished this one? 0 / 139 Handbooks done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

Cite this page

Reference it in your work, paper or an AI's context window.

APASingh, S. (2026). AI App Patterns for FDEs. Vibe Engines. https://vibeengines.com/handbook/ai-app-patterns-for-fdes
MLASingh, Saurabh. “AI App Patterns for FDEs.” Vibe Engines, 2026, vibeengines.com/handbook/ai-app-patterns-for-fdes.
BibTeX
@online{vibeengines-ai-app-patterns-for-fdes,
  author       = {Singh, Saurabh},
  title        = {AI App Patterns for FDEs},
  year         = {2026},
  organization = {Vibe Engines},
  url          = {https://vibeengines.com/handbook/ai-app-patterns-for-fdes}
}