The first week at a new customer starts with an export. The engineer gets a table where customer_id appears in two formats, a status column with nine values the business only recognizes four of, and a field called region that turns out to be the sales rep’s region, not the customer’s. Nobody wrote any of this down, because the people who knew it never needed to. Before any model runs, the engineer reconstructs it by sitting with the team, one question at a time.
A forward deployed engineer is a software engineer who works inside a customer’s environment to make an AI product produce results on that customer’s data, and most of that work is finding out what the data means before any model runs.
By Ho Bae, Founder & CEO, CUBIG Corp. · Updated October 2026.
The role is no longer rare. An analysis of about 1,000 job postings found that forward deployed engineer openings grew 1,165% year over year from January through October 2025, and that 60% of those postings describe a builder who ships working software inside the customer’s stack. Companies are hiring people to do by hand what their product cannot do on its own. For AI products, that hand work has a name few job descriptions use: data discovery.
This piece is about what a forward deployed engineer actually establishes at each customer, why it repeats, and what a company has to record so it stops repeating.
Key takeaways
- The forward deployed engineer role is growing because every AI deployment starts with the same question: what does this customer’s data mean? In a typical engagement, two of the three phases are about data, not models.
- Every deployment has to establish three things before the model’s output can be trusted: field meaning, the exceptions the business handles by habit, and the pass criteria. None of them is model work, and all three leave with the engineer unless they are recorded in a form the next deployment can reuse.
- The test of a deployment is not whether this customer’s result is good. It is whether the next customer in the same industry starts from this one’s field profile, preparation rules, and evaluation conditions instead of from zero.
What does a forward deployed engineer do in the first weeks?
Palantir created the role in the early 2010s and still describes the split plainly. A product developer owns “one capability, many customers”; a forward deployed engineer owns “one customer, many capabilities.” That inversion is the whole job. The engineer arrives with a product that works on the sample data and leaves when it works on this customer’s data, inside this customer’s rules.
OpenAI’s customer projects, as described in The Pragmatic Engineer’s account of the model, run in three phases: scoping with synthetic data, validation by building evaluations, and delivery, which begins with getting data from the customer. Two of the three phases are about data before the model is touched.
Engineers argue over whether the role is a consultant with a newer title; a hiring manager answering that question on Reddit describes the enterprise version of the work as something that “revolves heavily around messy pipelines, data models, and API integrations.” The title is new. The work is the data work that was always there.
Why does the same data work repeat for every customer?
The problem has been measured. In a 2021 study of 53 AI practitioners in India, Africa, and the United States, Sambasivan and colleagues at Google found that 92% had experienced “data cascades”: compounding downstream failures caused by data problems that were cheap to fix early and expensive to fix late. The paper’s title quotes a practitioner: “Everyone wants to do the model work, not the data work.”
A forward deployed engineer is the person assigned to the data work. That is why the role repeats. Each customer’s fields mean something slightly different, each has exceptions the business handles by habit, and each has a definition of a correct result that lives in someone’s head. The engineer discovers all of it, applies it, ships the deployment, and moves to the next account. The discoveries leave with them.
Ask a sales team which objection comes up most and you will hear a version of the same thing: “Your AI missed a rule everyone here knows.” A model that has never been told the rule cannot follow it. The forward deployed engineer’s job is to find the rule; the company’s job is to make sure it does not have to be found twice.
CUBIG Shorts
It Worked in the Demo. Not in the Pilot.
The section above, in short form: the product passed on sample data and missed the rules this customer runs on.
What does every deployment have to establish before the model can be trusted?
Field meaning. What each column the model depends on actually represents, including units, time zones, and which system is the source of truth when two disagree.
Exceptions. The records the business treats differently: test accounts, grandfathered contracts, manual overrides, the one region with a different fiscal calendar. These are usually the rows a model gets wrong first.
Pass criteria. What result counts as good enough for this use case, on which evaluation set, measured how. Without this, the deployment ends on a feeling rather than a number.
None of the three is model work. All three decide whether the model’s output can be trusted, and all three are rediscovered at the next customer unless someone writes them down in a form that can be reused. Which form matters, and the next section is about that.
What should be recorded so the next deployment starts further along?
Most of what a forward deployed engineer learns is written down somewhere, which is the trap: it sits in notebooks, chat threads, and a project wrap-up deck that the next engineer never opens. The record only helps if it is kept in the form the next deployment can run, not read.
| Work the engineer redoes | Why it repeats | What to keep as a reusable asset |
|---|---|---|
| Mapping customer fields to what the use case needs | Mappings live in notebooks and chat threads | A field profile for the use case: required fields, their meaning, and the join keys |
| Finding the exceptions | Exceptions are tribal knowledge | Preparation rules that name each exception and how it is handled |
| Agreeing what “works” means | Criteria are set per project, verbally | Evaluation conditions: metric, threshold, evaluation set, model version |
| Proving the deployment helped | Before and after are run on different data | A versioned before-and-after record under the same conditions |
The pattern is familiar from data onboarding in any system: the connection is the easy part, the confirmation of meaning is the slow part, and time to value is mostly the second. The difference with AI is that the confirmation has to be checked against a result, because a field that looks fine can still be the one the model misreads.
Is your deployment rediscovering what the last one found?
Five questions, answered honestly, show whether the data work is being kept or lost.
- Can a new engineer find the field definitions for your last deployment without asking the person who did it?
- Is there a written list of the exceptions the model must handle, and who confirmed each one?
- Was the “before” result measured on the same data and evaluation set as the “after” result?
- If the customer’s data changes next quarter, do you know which checks to rerun and which to skip?
- Could the next customer in the same industry start from your last customer’s profile, or do they start from zero?
Two or more “no” answers mean the forward deployed engineer is the product’s memory. That works until they move accounts.
How CUBIG keeps the discovery from being done twice
AI-ready data is data that has been prepared for a specific AI task, checked against the result that task needs, and can be rechecked when the data or the conditions change. Read that definition again and it is a description of what a good forward deployed engineer produces by hand, minus the part about rechecking later. Preparation that starts from the task and an assessment of where the data stands are the two steps that turn one engineer’s discovery into something the next deployment can reuse.
That is the gap Syntitan is built to fill, and it maps onto the three things above. A Project starts from a copy of the customer’s dataset for one use case, and the original stays untouched. Ready for Raw Data diagnoses that copy across six axes (usability, integrity, context, consistency, reproducibility, and traceability), flags what to review first, and applies only the preparation steps the team chooses; each applied step becomes a new project Version, so the field decisions and the exception handling the engineer worked out are recorded as rules rather than remembered.
Ready for Model takes the task type and the target column, prepares the data for that task, fills in the cases the task lacks, and compares performance before and after on the same model under the same evaluation conditions, which turns “it works” into pass criteria with a number attached. Ready for Agent builds test cases from the exception situations an agent tends to miss and compares its answers before and after the data is supplemented; connecting live agent runs to those cases is planned for December.
When the customer’s source data is updated, Execution Trace shows which Versions the update produced and keeps every run tied to the Version, settings, and evaluation conditions it ran under, so the same preparation can be reapplied and the same comparison rerun instead of rediscovered. Applied Status shows which Version is connected to which downstream system, as a file, through an API, or over MCP. The engineer still does the first discovery. They stop doing it twice.
None of this replaces the customer’s own definition of a successful deployment. Whether a deployment is ready is decided by that definition and the before-and-after result; the recorded profile, rules, and conditions are the evidence behind the decision, and the reason the next one starts further along. Try it on your data, free.
