What you'll learn: what a forward deployed engineer (FDE) does, how the role differs from an applied AI engineer and an AI architect, who owns which decision on one customer request, and how to read a job description with four verbs.
At a glance
Figure 1. Three roles around one customer problem
How to read this: solid arrows follow the work from problem to product, dotted arrows are review and feedback, and in a small team one person may hold all three boxes.
- An FDE works with the customer to get a result running in the customer's environment.
- An applied AI engineer owns quality and operation after the feature exists.
- An AI architect owns the design, the review and the written decisions.
- Titles overlap, so judge a role by its verbs, not its name.
- This course is the build and interview companion to the AI Architect course.
Scenario
Composite scenario, not a real company. Lumen Industrial Supply, a fictional distributor, has sales engineers who spend hours on vague requests such as "something to monitor vibration on our pumps". The sales director wants an assistant that finds products and cites the datasheet. Three people could take the job. One sits with the sales engineers and builds a first version. One later runs it. One writes the design review.
What you will be able to do
- Describe the FDE role in three sentences without naming any employer.
- Place a task on the build, deliver, operate or design side using the four-verb matrix.
- Decide which role should own a given decision on the Lumen request.
- Turn three job descriptions that you collected into a gap list for your own plan.
Prerequisites
Read the AI Architect overview for the design-and-governance side. This is the first lesson of the course, so nothing else is required.
Core ideas
Role matrix
What this table is. A working definition for this course, not a fact about any employer.
| Question | Forward deployed engineer | Applied AI engineer | AI architect |
|---|---|---|---|
| Main question | Does it work for this customer, in their systems? | Does it stay accurate, fast and affordable in use? | Is the design sound, safe and recorded? |
| Where the work happens | With the customer, often on their data and access rules | In the product codebase and its pipelines | In reviews, diagrams and decision records |
| Typical output | A working MVP, a demo, a proposal | An evaluated, monitored feature | An architecture, ADRs, review findings |
| Hands on keyboard | Most of the day | Most of the day | Some of the day |
| Judged by | The customer's outcome | Quality, reliability, cost over time | Whether decisions hold up in review |
In a small team one person may hold two columns. Read verbs, not nouns.
In the interview: "How is this role different from a software engineer?" A good answer names the customer loop (discover, build, demo, adjust) and ownership of an outcome, not only of code. It admits the boundary with neighbouring roles moves between teams.
The four-verb reading
Every responsibility in a job description is one of four verbs: build (write and ship code), deliver (get it working inside the customer's constraints), operate (keep it working) or design (decide and record how it should work). Count them to find the real column.
Predict first. A listing says: "own the technical relationship with the customer, prototype in days, write Python, present to the customer's engineers". Which two verbs dominate?
Answer
Deliver and build. Owning the customer relationship and presenting are delivery; prototyping in Python is building. Nothing asks for operation or standards, so it reads as an FDE-style role.
Who owns what on one request
Figure 2. The Lumen request through three roles
How to read this: each box sits in the lane that owns the decision, and the arrow from review back to the workshop shows that findings can reopen the requirements.
The default here is to build the MVP first and let the review shape the hardening. If the data is regulated or the action is irreversible, review first.
Worked example
Tally the verbs in six invented lines. Assumptions: the lines are illustrative, not copied from any posting.
| Line | Verb |
|---|---|
| "Prototype solutions on customer data in days" | build |
| "Join customer workshops and write the follow-up proposal" | deliver |
| "Own on-call for the production service" | operate |
| "Run weekly design reviews and maintain ADRs" | design |
| "Debug integration issues in the customer's network" | deliver |
| "Write Python services with tests" | build |
Tally: build 2, deliver 2, operate 1, design 1. Deliver and build are 4 of 6 lines, about 67 percent, which points to the FDE column. A listing with 5 of 6 lines on operate would point to the applied AI engineer column.
Three listings are a small sample. The tally tells you what to practise, not how the market behaves.
Practice task
Collect three job descriptions from a source you trust and may copy for personal study. Do not paste them into this course.
- Copy each responsibility line into a table: Line, Verb, Evidence you already have.
- Tally the verbs per listing and write the dominant column next to each.
- List every line with empty evidence. That is your gap list; the next two lessons use it.
Exercise
Decision exercise. Lumen asks for the vague-request assistant. You have one person for two weeks. Choose one: (A) build a working MVP with the sales engineers and review later, (B) write a full design and ADRs first, (C) harden an existing prototype for production. State which role leads, why, and what you would not do yet.
Model answer
Option A, led by the FDE role. The requests are vague and the data is unseen, so a design written first would rest on guesses. Do not harden yet: scale and monitoring work is wasted if the sales engineers reject the first output.
Explain it back. In three sentences, explain to a Lumen sales engineer what an FDE does for them. A good explanation:
- names the customer problem;
- says what the FDE builds and where;
- says what the customer gets at the end.
Done when you have the tally table for three listings, a gap list with at least three lines, and your three-sentence explanation written down.
Hint 1: the tally is stuck
Split a line that holds two verbs before counting.
Hint 2: the explanation sounds like a job title
Start with a verb and name the customer's problem: "Take a vague request and turn it into something the sales engineer can try this week."
Common mistakes
- Treating the matrix as a fact about every employer. It is a reading aid.
- Counting nouns ("AI", "cloud") instead of verbs. Nouns appear in every listing.
- Assuming an FDE does no design. The difference is who records and reviews the decision.
- Skipping the gap list. The plan in lesson three has nothing to fill without it.
Knowledge check
1. Which verbs dominate an FDE-style role, and why does that matter?
Build and deliver dominate. Delivery work (workshops, access rules, demos) needs more than coding, so a plan that trains only coding leaves half the job untrained.
2. Why read verbs instead of titles?
Organisations use titles differently, so one title can describe different jobs. The verbs describe what you would actually do.
3. On the Lumen request, why does the review lane connect back to the workshop?
A review can find a requirement ambiguous or unsafe, such as access to partner-only documents. The fix then belongs in the requirements, not in a patch to the build.
4. When would you design before you build?
When data is regulated or an action cannot be undone. A wrong first build there costs more than time, so an early review is cheaper.
5. What does a tally of three listings prove?
It shows what those three listings ask for and where your evidence is missing. It says nothing about the wider market, because three is too small a sample.
You can now
- Explain the FDE role in three sentences without naming an employer.
- Read a job description as build, deliver, operate and design verbs.
- Say which role should own a decision on a customer request.
- Produce a gap list from three listings.
Further reading
- Building effective agents (Anthropic): separates workflows, where LLMs and tools follow predefined code paths, from agents, where the LLM directs its own process.
- OWASP Top 10 for LLM Applications: the 2025 list of LLM application risks, as of 2026-11-02.
Last verified: 2026-11-02