By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_). 2026-08-24. A straight answer first, then the receipts.
A forward deployed engineer is the engineer who goes to where the AI has to actually work, and makes it work there. Not the person who trains the model. The person who takes a model that looks good on a benchmark and turns it into a system a real business can run every day. The job has three parts: find the leverage point in a real workflow, build the smallest thing that moves it, then stay and own it in production. The rest of this post is that sentence unpacked, demonstrated on a mini-PC that costs $1,400.
The title is loud right now because the AI labs are hiring humans for it as fast as they can. The work is older than the name. Anyone who ever shipped software into a bank branch, a hospital, or a factory floor has done forward deployed work. I did versions of it for twelve years in enterprise learning systems. Now I run the whole job on my own hardware, and every number I will show you is public.
Part one: find the leverage point
Ten things in a business look automatable. Usually one of them matters. The forward deployed engineer finds it by watching real work, not by reading a pitch deck. The tool for this is measurement, not opinion.
Here is a measured leverage decision from this desk. Should the local model think by default? We ran it both ways on a fixed problem set. On 40 hard problems, thinking rescued 15 that failed without it. On HumanEval-30, thinking bought nothing: 28/30 either way. So the shipped default is thinking off, with a manual override for hard tasks. That one routing decision saves tokens all day and costs nothing where the work is easy. Full method in the measured-knees note.
Scale that pattern up and you get model routing: work moves across five lanes here, chosen by measured cost and speed, not by brand. Same discipline, bigger surface.
Part two: build with evals
The customer never asks "is it smart." They ask "can I hand it work and walk away." No leaderboard answers that. So the FDE builds the test that does.
We built one. It is open source: delegation-bench. Nine job classes from real work. Hidden tests the system never sees. A sabotage cell with a planted bad instruction. Certified floors, meaning exact statistics that say "at least this reliable," not vibes. Result on this machine: 495 trials, 29 cells, every capability cell passed 20/20, and eight cells earned walk-away certification at 35/35 or 30/30 with floors of 90.5 to 91.8 percent. Code, debugging, document search, reasoning, decisions, two vision types: all at the walk-away bar.
The coding skill underneath that is measurable too: 93% HumanEval (28/30, frozen subset, seed published) and 67% LiveCodeBench-30 (20/30, Wilson 95% interval 49 to 81, always cite the interval) on the same $1,400 box.
Part three: own it in production
This is the part that separates the title from the demo. The system runs unattended. It is always on, with automated watchdogs, restart recovery, and queue discipline. When it breaks, the FDE is the pager.
A real production story from this rig: mid-project, long context and vision silently broke. The easy read was "the model got worse." We did not take the easy read. We bisected nights of changes to one upstream llama.cpp commit, reported it as issue 26209, fixed it locally, and validated the upstream fix on our silicon with 9/9 identical paired answers. Then we re-ran the frozen benchmarks to confirm nothing moved. That is the job. The full serving story is on this blog with raw logs.
The actual FDE skills list
People search for "fde skills" and find wish lists. Here is the honest one, each skill proven by an artifact above:
- Evals and basic statistics. You can prove "at least 90 percent reliable" with exact intervals, or you cannot claim it.
- Integration glue. The AI never works alone. It sits in a pipeline with document stores, queues, and approvals.
- Environment debugging. When output turns to garbage, you find the layer that broke. Here it was a host buffer commit, not the model.
- Production ownership. Watchdogs, restarts, logs, and the willingness to be paged.
- Plain talk with non-engineers. The decision table ships with floors printed on it so an operator can read "walk away" without knowing what a quant is.
What the job is not
It is not prompt tricks. It is not a demo that works once on stage. And it is not data science: the FDE ships systems, not notebooks. If you like the last mile more than the lab, this is the job. If you like clean problems, stay near the model.
Every claim in this post has a raw log or a public repo behind it. That is the standard. Point it at your own machine and see what your floors look like.
Next in this series: the FDE title decoder (forward deployed vs solutions vs implementation vs customer engineer) and why evals are the FDE skill nobody lists. Need this kind of work in your environment? Implementation intake. Conditions for every number: $1,400 GMKtec EVO-X2, Qwen3.8-27B Q4_K_XL, llama.cpp, raw logs in delegation-bench and the stack repo.