The newspaper of the Forward Deployed Engineer
Every skill of the FDE craft, taught through cases: code and customer work, with steps and exercises.
Stripe can resend the same event for up to three days, with a new signature each time. A time window cannot stop those duplicates, so your receiver needs a separate line of defence.
09/10/2026
An agent can fail at a client site even when the model is perfectly capable. Often the cause is simply that business process knowledge was put in the wrong place: the system prompt, a tool description, or a sub-agent nobody needed.
A refusal that comes with a reason and an alternative, and gets written down, usually keeps a client’s trust better than a yes.
The client wants a system that is ‘always right’. Any model will sometimes be wrong. If you want the project signed off, agree on how many errors the client will accept in the very first week.
When a client sends you a file full of "dissatisfied" clicks, the first job is to read the traces and label them, not to count the clicks.
A pilot starts to fail when the model works but users quietly ignore it. The fix is on the shop floor, next to the people using the tool. It is not in the code.
A single "not yet" in a money column can make reported revenue lower than it really is, and nobody notices, because pandas treats a missing cell as zero.
A polished demo only proves the agent got it right once. A repo worth sending shows where the agent fails and how often.
A bank that has moved to the new message standard does not necessarily have clean data. Measure how clean it is before a model learns the wrong things.
JSON that parses is not the same as JSON that is correct. This guide builds a pipeline that knows when to trust a figure and when to send it to a human reviewer.
Your pilot may have run well. Spend the first minute of the meeting on architecture, though, and there may not be a second meeting.
What a team learns on a deployment usually leaves with the FDE when the project ends. This guide shows how to keep it in five documents and a template repo.
When one RAG system serves many customers, a single missing WHERE clause can put one customer's documents into another customer's answer. To prevent that, the boundary has to be built into the database, the vector store and the encryption keys.
When the next link in the chain is an agent from a vendor whose code, memory and tools you cannot see, three things matter: use MCP for your own tools, use A2A to hand work to the other vendor, and expect the hard part to be authentication and tracing.
In a hospital, data reaches you by two routes: HL7 v2 pushes events to you, while FHIR lets you ask for state. If you pick the wrong route early on, your agent will either act too late or read the wrong data.
The person who brought the project into the client has just resigned. The code still runs, but nobody is left to approve requests, sign off delivery or defend the project. The FDE is often the first to notice.
Ten examples drawn at random from a client's ticket backlog can push a model towards the majority label, and changing only their order can shift results dramatically.
Asking a model "how confident are you?" and trusting the number it gives is the quickest way to put a wrong answer in front of a customer.
If your SQL needs JOIN after JOIN just to trace a fraud ring, the problem may be the data model, not the query.
The system holding a client's transaction data doesn't need you to like it. You do need to know where it breaks before you run your first job.
Security reviews rarely turn on algorithms. The client's security team will ask three things: who holds the keys, who can see what, and whether one person's data can be deleted when they ask.
"Revenue by province, by product category, by month" sounds like a simple question. A client's sales database is rarely built to answer it, and the FDE is the one who has to build the bridge.
The client already has a queue that runs reliably. The FDE's job is to attach an AI consumer to it without charging a payment twice, letting failures pile up unnoticed or setting off an event storm.
When your service has to run behind a customer's load balancer, three faults tend to surface together: users' real IPs disappear, sessions jump between servers and health checks report the wrong thing. All three can be fixed once you know what each network layer can see.
When the client's infrastructure team asks "what's the p99, and how many requests per second can it take?", answering "it runs pretty fast" will cost you their trust in the very first meeting.
Getting a model to run in a notebook is the easy part. Customers will ask harder questions: will messages be lost, will anything be scored twice, and what happens to the pipeline when the model slows down?
A credit scoring model works well until someone asks why one particular application was rejected. The answer then has to hold for that application.
Databricks asks you to write a dictionary-processing function in a notebook. OpenAI sets an implementation task split into several parts. Palantir gives you 60 minutes of decomposition on a problem that leaves out information on purpose, and it does not care whether you know Dijkstra by heart.
When a system is slow and expensive, the usual first move is a cheaper model. That lever belongs near the end, and only once an eval is in place.
The trade-off question checks whether you can see what you gave up, why you gave it up, and how you explained that to the customer.
The first time a client calls to say the model's forecasts are wrong, you need immediate answers to three questions: which model is running, when it started going wrong, and whether the fault lies in the data or the model.
A passage cut from its source document can lose both the company name and the time period. Adding back a few dozen tokens of context reduced failed retrievals by 49%, and by 67% with reranking added.
If your API returns only a 500 with "Something went wrong", every incident on the customer's side becomes a ticket for you. A few JSON fields in the right places can change that.
The code is identical, yet a bank or factory network can return a 407, a 504 or a red CORS line in the console. The FDE who can tell which layer the fault sits in fixes it first.
A model that runs well in the cloud can still fail next to a conveyor belt with a weak connection. FDEs need to plan for the device, the power supply and the rollout before they think about the model.
A client sends a screenshot of a wrong number. If you trace that number back to the job and the run that produced it, you can look for the root cause methodically instead of guessing at the model.
A model can keep returning HTTP 200 in a few milliseconds even after customer data has moved far from the data it learned on. This guide shows how to build a system that catches the change before the customer does.
When a client asks "what data was last month's model trained on?", an FDE should answer with a commit hash, not from memory.
With one workflow file and three Python scripts, reviewers can see whether your change makes the model better or worse before they merge it.
On a ten-thousand-row table, tree-based models are still hard to beat. On images and text the balance flips, and a good FDE should be able to explain why in the first meeting.
In a credit-scoring example from scikit-learn, the model stays the same and only the decision threshold moves. That one change makes the business outcome nearly twice as good.
Six steps to make sure a person approves every refund or email your agent sends, without leaving customers waiting forever. Answer the button click within 3 seconds, wait as long as the decision takes, and reject automatically if nobody responds.
An agent with no stop condition can run forever and burn money without throwing a single error. The person left explaining that to the client is the FDE.
A judge with 90% agreement can still miss every wrong answer. If you want a client to trust your eval numbers, measure the judge against the person on their side who knows the domain best.
The Llama 3.1 model card lists Thai but not Vietnamese. You need to catch details like that before you put an open model into a client's system.
Before handing everything to a framework, work through a full cycle of requests, streaming and tool calls with Claude and OpenAI, and learn where Gemini differs. These are the things you will end up debugging at a client's office.
Prompt injection has no complete fix yet, so FDEs have to stack several layers of defence, so that when one layer fails the damage stays small.
Newer models have not made prompt engineering obsolete. They have made the habit of starting with the heaviest technique expensive.
Embeddings are good at understanding what a question means, but they easily mistake HD-2024-0153 for HD-2024-0135. This guide fixes that in six steps, from an eval set and a tokenizer through to reranking, and shows how to measure the result.
A model fine-tuned on Vietnamese legal text reports that its Accuracy@1 rose from 0.5682 to 0.7274. That number tells you nothing yet about the insurance documents of the client you are working with.
When an agent gives wrong answers at a customer site, the fault usually lies not in the prompt but in what you put into the context window, or forgot to put there.
On your first day at a client site, the Git mistake to fear is usually not a merge conflict. It is a commit with the wrong email pushed to the wrong server.
You don't need to learn a new language before the integration review. You need to know which three files to open first, then trace one request all the way to the database.
When a client's AI assistant invents a clause that does not exist, these four concepts tell you where the fault lies. Without them, all you can do is edit the prompt and hope.
When you are the only person who can see a system running, your most valuable skill is turning what you see into a reproduction that someone far away can run straight away.
At a customer site, an FDE has to persuade engineers who don't report to them to change their own systems. A job title won't help with that.
The CTO, the chief accountant, the CFO and the clerk at the screen all look at the same system, but each asks a different question. An FDE who can answer only one of them will never get the deployment past the demo.
When the customer's CFO asks whether the project was worth the money, "users say it feels faster" will convince nobody.
A green test suite on launch day only shows that the agent handles the questions you guessed users would ask. The questions they actually ask are in the traces.
You cannot work as an FDE without coding. Once candidates have shown they can code, what decides who gets hired is how well they communicate with customers and win them over.
Databricks ties each FDE engagement to OKRs shared with the customer before anything gets built. A one-page brief split into three layers lets you pin down the "what" the same way.
Kevin B., an FDE at Rippling, calls the customer's complaint a symptom. Your job is to find the disease before you write the first line of code.
Both roles can draw the same diagram. Only one has to open a pull request in the customer's repo and get it running reliably in production.
MIT NANDA surveyed 300 enterprise AI projects and found that 95% produced no measurable profit. OpenAI and Anthropic are responding by sending engineers into their customers' offices.
Two studies tested the same pair of techniques. In one, the gains added up. In the other, the model got worse. For FDEs, that means classifying failures and measuring a baseline before choosing anything.
"It's all in the warehouse" is usually only half true. An FDE who takes it at face value can lose weeks before finding out the model has been learning from a dashboard table.
