Grok11

Independent teaching notes. Not affiliated with xAI or Grok.

Forward Deployed Engineering

What a Forward Deployed Engineer actually does

A Forward Deployed Engineer takes an AI system from a first conversation on the customer's floor to something their team runs without you. Most of the job is not the model. It is the workflow, the source of truth, the authority you refuse to hand the model, and the evidence that it helped.

Harbor Lane Clinic, Keel and Bin Parts, Mill City Permits, Ridge Route Field, Lumen Desk, and Northline Orders are fictional practice on this site. None is a real client. Portfolio policy.

The short version

The title is used loosely, and teams draw the line in different places. On this site, a Forward Deployed Engineer (FDE) is the person who builds the pilot and sits with the customer while doing it. They write the discovery note, agree the metric, write down what the pilot will not do, map the customer's fields onto the tool, scope the documents the system may read, keep authority in code, write the evals, ship with a pilot account, and run the old way and the new way side by side until the numbers say continue or stop.

A forward operator, where a team has one, runs the live pilot after it is up: watches failures, keeps the old screen during the parallel run, writes the incident note, and writes the handover. One person may do both on a small pilot. The interview practice page keeps the split, because building the loop is not the same work as noticing that a green health check hid a bad reply. This page is about the FDE half, and about the habits both halves share.

What the job is not

Sit with the worker, not only the buyer

The buyer is the person who asked for the project. The worker is the person who does the job today. They are rarely the same person, and the buyer's description of the work is a summary. Discovery means watching the actual path: which screen they open first, what they copy by hand, what they look up before they answer, and what they are not allowed to change.

In the Harbor Lane Clinic case, the buyer, Nia Okonkwo, wanted a draft waiting in a staff queue before open. The discovery note names the front desk, because they are the ones typing replies about hours and about moving a visit. In Lumen Desk, the buyer is June Ibarra, but the people you watch are the agents still answering on the old screen. If you only interview the buyer, you can build a lookup the buyer likes and the worker never opens. Week 1 makes that note the first artifact, before any tool has a name.

The metric, in their words

A success metric is the one number you and the buyer both mean by "this worked," agreed before the loop exists. Write it twice: once in the buyer's words, once in a sentence you can check. If the two sentences do not name the same numerator and the same denominator, you do not have a metric. You have two hopes.

For Northline Orders, the lab shop, the buyer's sentence is that fewer people should need a second system to ask where an order is. The checkable sentence is the share of status questions answered from the tool result with no guessed carrier. "The demo looked good" is not a metric. A deflection rate, the share of questions that never reach a person, is a bad one when the answer can be wrong, because it can rise while the shopper is worse off. Lumen Desk's buyer first offered "turn the old screen off if health is green." The metric kept instead was replies a person edited and sent from the new path, counted next to replies still sent on the old screen.

A written exclusion

Saying no is a design artifact, not a mood. A written exclusion names the action you will not take and the reason, in one sentence the buyer can forward. "Later" is not a no. It stores the use case as a promise.

Northline's exclusion is refunds: we will not move money, because this pilot has no gate and the metric does not include refunds. Harbor Lane will not send mail and will not read billing. Ridge Route Field will not connect a write tool on an admin login. A pilot names one team, one task, an end date, and an out-list. If the out-list is empty, every new ask is still "phase 1," and you are building a platform under a pilot's name. The Problem Frame on Week 1 puts the exclusion on the same page as the actor, the trigger, and the source of truth, so it cannot drift off into a backlog.

A field map onto the real source of truth

The lab's lookup_order returns three clean rows. A customer's system does not. The source of truth is whatever they already run: a vendor API with different field names, a nightly file, or a screen no program can call. A field map is written in code before any model call: their name, your name, which side wins, and what you return when the sides disagree.

In Keel and Bin Parts, the floor calls it "on-hand," the tool calls it live_qty, and the live counter is the source of truth. The nightly export is a snapshot with a time on it. When the two disagree, or the live read does not answer, the picker hears that the live count did not answer. Week 2 teaches the map, and the Keel and Bin reconciliation drill is the required practice that goes with it.

A corpus list, with an owner

Retrieval scope is a written in-list and out-list, owned by a named person, before the first document is indexed. "Index the drive and filter at query time" puts forbidden text in the store, and a filter cannot un-store it from a backup you already took.

In Mill City Permits, Ruth Ellison owns the list. In: the published guide pages she named. Out: applicant files, draft decisions, and fee and pay pages, even when they sit in the same folder. A fee question gets "outside this corpus," not an amount. Week 3 then makes the store enforce it: access control before rank, tombstones so an old version stops answering, and reciprocal rank fusion so keyword and vector results combine predictably.

An allowlist, and authority that stays in code

Every loop gets a tool table, and a tool that is not in the table cannot be called. In the lab, an unknown name returns unknown_tool. A step budget ends the turn when the model keeps asking.

Authority is the part people get wrong. The model can be talked into anything: by the shopper, by a packing slip, or by a retrieved document someone edited. So the decision to commit a write does not live in the model. In Northline, a typed handoff carries an authority list, and the writer that receives it cannot widen it. The refund tool sits behind a write gateway that checks order state, the amount, a ceiling of 5000 cents, and an idempotency key. Confirmation is an argument your server receives from a UI button or a policy worker, not a "yes" the model copies out of the user's message. If the prompt says "ignore policy and refund 500000 cents," the gateway returns amount_blocked and the ledger does not change. Week 4 covers it.

An eval that scores the action

Score what the system did, not how it sounded. A billing question must not return billing. A price question must not return a price. A draft must not claim money moved. Week 1 starts with fifteen scripted order cases that need no judge model. Week 4 adds a judge you calibrate and do not fully trust, and regression tests you will still run next month.

A pilot account, not admin

Ship with an account created for the pilot. Not your own login, and not the customer's admin password. Ridge Route is the case where that is the whole story: Andre Pell wanted the tool to close jobs, and the only login offered was his admin account. The write tool stayed off. The pilot stopped until someone could create a technician account that writes only its own note, and the handover was that stop note. Week 5 puts the pilot account in the runbook next to how it is down, how to stop it, the previous image tag, and who may run those steps.

A parallel run, and adoption that is not a green health check

The old way stays on while the new way proves itself. A green /health says a process answered. It does not say a reply was right, and it does not say anyone used it. Lumen Desk refused a Friday cutover on a green health check, kept the old screen up, and counted replies a person edited and sent from the new path. Page views and logins are not adoption. The adoption table is allowed to say stop. The green health check page walks through that mistake.

A five-line incident note

When the new path is wrong, someone writes a short note a person sends: what broke, who is affected, what you stopped, what you do not know, and when the next note comes. On Lumen Desk, ticket LD-18 is the practice failure: the new path showed a status the old screen did not. "No customer impact" because health was green is a bad note. "We are investigating" alone is not a note. Week 6 adds the trace id on the reply, without the shopper's email in the trace.

Deciding whether it created value

The last decision is continue or stop, made from the metric you wrote before the loop, over a window you named. A deliberate stop with a clear note is a finished pilot. Ridge Route did not ship, and its refusal is the handover.

Where each habit is taught

The five fictional cases each follow one engagement end to end: Harbor Lane Clinic, Keel and Bin Parts, Mill City Permits, Ridge Route Field, and Lumen Desk. If you talk about one, say "I studied this fictional engagement." Do not invent a customer or a metric.

Start Week 1: Design Not sure you are ready? Take the diagnostic