The term "Forward Deployed Engineer" comes from Palantir, the US software company that builds data and AI platforms for governments and large enterprises. Palantir found that selling a customer the software and leaving them to make it work did not solve hard problems, so it started sending its own senior engineers to sit with the customer and build the solution with them. It called that role the Forward Deployed Engineer. One thing to be clear about: this model is not new, and it is not really about AI. Palantir ran it for years on data and analytics problems, well before the current AI wave. It is a way of delivering software, not a technology. What is new is that AI now makes the custom build far cheaper, and that is what puts the approach within reach of a mid-sized company instead of only a government with a huge budget. The best way to understand it is to watch it run on a real engagement. Here is one of ours, fully anonymized, delivered to the people doing the work inside a single short phase.
The problem. A nonprofit runs recuperative-care beds: medical respite for homeless patients leaving the hospital. Hospitals send the same referral to four or five facilities at once, and the first to respond wins the patient. The operator's window was about fifteen to twenty minutes. Before, a staffer had to notice the email, open a dozen pages of attachments, read them, and decide. Every empty bed is lost revenue against a fixed payroll.
What we built. About a month after their first email to us, they had a live system running one workflow end to end:
The AI reads the packet in minutes and never guesses. A fixed rulebook, not the model, applies the operator's own admission policy, so every decision can be explained. A person makes the final call, with the source document on screen. Beds filled is the number it moves.
That system took a month of decisions, and the decisions are the method. Here is what actually happened.
The model, in plain terms
A Forward Deployed Engineer is a senior engineer who embeds with your operation. "Embed" here does not mean a desk in your office. It means the working pairing: our engineer and the one person on your side who knows the business cold, working together in a tight, continuous loop, usually fully remote. The pairing is the unit of delivery, not a place. There are no hand-offs, and nothing gets lost between the business and the engineer. In this engagement that pair, our engineer and the operator himself, shipped a live system in about a month. The ontology is simply the map the software works from: the referral, the bed, the admission policy, the decision. Run that map live over the real operation and you have what Palantir calls a digital twin: the thing that lets AI act inside your business instead of just describing it.
Requirements come from talking, not a spec
Nobody wrote a requirements document. The requirements came from the people who live the work:
- The operator's first email already held a ten-step description of his process and a real, de-identified sample referral.
- His referral manager, the person who works referrals every day, sent an internal write-up so precise she worried it was "too detailed." It was not. It held the exclusion list, the payer traps, and the real decision deadline.
- Planning calls were recorded and transcribed.
- Where the sources were unclear, our engineer sent five specific questions and a decision diagram. The answers came back within a day and became tested rules the next.
The operator put the sequencing plainly, and it became the rule for the project: get the chassis built first, worry about the air conditioning later.
AI reads, fixed rules decide, a human always signs off
This is the core of the build, and every part of it is deliberate:
- AI reads, and never guesses. It pulls facts from messy documents. If it cannot find something, it flags it as unknown, and every fact it pulls carries a note of where it came from and how confident it is.
- Fixed rules decide. A rulebook, not the model, applies the operator's confirmed policy, so the same input always gives the same answer and every answer can be explained.
- A person signs off. Every final call is a human's.
Decisions about money and patients have to be explainable, not a black box, and two choices kept it that way. When someone tried to let the AI judge whether an infection was "stable on antibiotics," it proved unreliable, so we made it a hard rule that sends every such case to a person. And the system launched in shadow mode: it recommended while people still decided, so we could compare the two before it held any authority. It holds by default whenever anything is uncertain, because a missed referral is worse than a wrong one.
What you own when it is done
Ask this first of anyone. Here is what the client owns:
- The code, the rules, and the pipelines, built on open standards, with nothing they cannot export.
- Their own cloud account, under a signed business associate agreement, with the AI model running inside that boundary. Patient data never left it, and never trains a model.
- No new platform. The AI went into the systems they already run.
We keep our reusable methods; the client owns the result. That is the whole difference from renting a platform, where the map of your business sits inside someone else's system and you cannot take it with you if you leave.
The proof it was real
One engineer, running an automated delivery loop, shipped a lot in that first phase.
Every release had to pass a live end-to-end test, not a lab test. On every change:
- a real email with fake patient content sent into the live inbox;
- the actual cloud pipeline processing it;
- the recommendation checked against the known-correct answer;
- the staff screen opened in a real browser to confirm the card appeared.
That test caught two problems before they reached production: a payer-matching bug that would have accepted a patient whose insurance was not covered, and a shortcut in the error handling that would have destroyed real data. A set of 51 test referrals with known answers covered every path a real referral could take, so we checked every case, not just the ones we expected. Nothing reached production without passing it.
The model in one line
A senior engineer paired with the person who knows the business. One workflow taken to production in weeks. The AI reading, fixed rules deciding, a person signing off, and you owning what gets built. It is not exotic, and it does not take a Palantir-sized budget. The harder question is which workflow to point it at first, and that is Part 3.