Over the last few years, I’ve spent hundreds of hours consolidating my work across a few foundational disciplines that have become part of The Business Engineer’s core curriculum.
Now that AI has dramatically accelerated this process, I felt it was time to launch the Foundation Series.
The Forward-Deployed Engineer is another book in that series.
If you’re already a paid member, simply reply to this email, and we’ll send it your way.
The AI era has a distribution problem. Frontier models are extraordinary, but they are increasingly available to everyone. An insurer, manufacturer, bank, software company, and startup can all rent roughly the same underlying intelligence. The API is not the moat. Access to the model is not the deployment. Possessing frontier capability says remarkably little about whether an organization will ever turn it into operating value.
This is the paradox now showing up across enterprise AI. Capability is spreading faster than implementation. Model performance rises, inference gets cheaper, commitments to AI infrastructure grow, and yet an enormous amount of enterprise activity still dies somewhere between the demonstration and the P&L. That gap is the real market: the distance between what intelligence can do in principle and what a particular company can make it do inside its own systems, with its own data, under its own policies, around its own exceptions, with actual people accountable for the consequences.
The generic model knows none of this. It does not know that the supposedly standardized claims workflow actually branches into twelve exception paths; that the process diagram has not described the process for three years; that one spreadsheet maintained by a twenty-year employee quietly coordinates half the operation; that one risk will never survive compliance; that the ERP contains three definitions of the same customer; or that a step everybody officially follows disappeared from actual practice years ago.
The last mile is not merely technical integration. It is organizational reality. That is why the forward-deployed engineer has become one of the defining roles of the AI era.
An FDE is an engineer embedded at the customer’s constraint, building production machinery from the customer’s real work, with a second responsibility running in the opposite direction: what repeats in the field must eventually travel back into the product. Both directions matter. Without the first, the technology never truly reaches the customer. Without the second, the vendor becomes a consultancy.
The role therefore sits on one of the most valuable boundaries in the current economy: the boundary between general intelligence and specific work. Models can be deployed in minutes. Value takes longer because value has to be installed.
The role did not emerge from a human-resources exercise. It emerged because a company ran into a structural problem with its business model.
In the 2000s, Palantir was attempting to sell data software into some of the most complex institutions in the world. The promise of the platform was general, but the environments into which it landed were anything but general. Every customer had different source systems, schemas, operating processes, security constraints, definitions, politics, and ways of deciding what counted as truth. A generic platform could arrive technically complete and still be economically inert.
The missing component was not more software in the abstract. It was someone capable of crossing the boundary between the platform and the institution. So engineers went into the field. Not account managers who could describe the product. Not consultants who would study the organization and leave behind recommendations. Engineers who could understand the institution, touch the systems, build the implementation, and remain accountable for whether the thing actually worked.
That distinction created the forward-deployed model. The engineer lived close enough to the problem to discover what the product team could not see from headquarters. The customer’s real ontology emerged from the customer’s own data. The workflow emerged from watching the work. Requirements that had sounded important in meetings turned out to be irrelevant. Edge cases that had never appeared in specifications turned out to dominate production. The field became a source of truth.
The economics were equally important. The early phase of a customer relationship could be expensive. Engineers spent time learning an institution before the software produced meaningful leverage. In ordinary software economics, that looked ugly: high-cost people sitting with individual customers performing work that appeared difficult to scale. But the motion had a different logic: Acquire. Expand. Scale.
During acquire, the vendor absorbs the cost of understanding the institution. The field team learns the systems, vocabulary, workflow, constraints, and exceptions. Margins can be poor because the vendor is effectively financing discovery.
During expand, the first successful deployment creates evidence. Trust rises, adjacent workflows become easier to enter, and both sides now know the platform can produce value inside the customer’s actual environment.
During scale, the relationship changes character. The ontology already exists, the reusable infrastructure is in place, the customer understands the operating model, and new use cases can be layered onto what has already been learned. Field intensity per dollar of revenue falls, and the economics increasingly resemble software rather than bespoke services.
This is the essential trick: the field work is not supposed to remain field work forever. It is supposed to create leverage.
For years, this made Palantir easy to misunderstand. From the outside, a company employing large numbers of engineers around individual customers looked suspiciously like a consultancy wearing a software valuation. The criticism was not irrational. Any company can call services “deployment” and promise software will appear later. The test is whether the residue actually moves into the product.
That is what eventually matters. Patterns discovered across deployments become primitives. Repeated integrations become connectors. Recurring data structures become ontology patterns. Common controls become platform capabilities. Lessons paid for by one generation of customers harden into software sold to the next. The margins then tell the story.
What looked like an inefficient delivery model can become the manufacturing process through which the product itself is discovered. The field is part of R&D. The customer is not merely where the product is installed; the customer is one of the places where the product is found.
The role itself has changed as the underlying product has changed. At one point, the FDE might have been primarily concerned with platform stability. Then data integration became dominant. Then came turning data into operational decisions, enablement at scale, and now AI-speed deployment. Different vintages can look almost like different professions, but one continuity remains: the FDE owns the distance between technology delivered and outcome achieved.
AI has made that distance more important, not less. The modern model is vastly more general than the software stacks of the 2000s, but the organization it lands inside remains specific. In fact, the more general the intelligence becomes, the more valuable the installation layer can become, because the remaining problem concentrates around everything the generic model cannot know in advance.
That is why the old field-engineering idea has escaped its birthplace. The motion is spreading because the problem that created it has spread.
Four forces have converged to make the forward-deployed model unusually important.
Commoditization above. Frontier capability is becoming easier to procure. A company does not need to train a foundation model to access world-class language, coding, vision, or reasoning capability. It can rent those capabilities from a growing set of providers, and the models continue to leapfrog one another. This pushes differentiation upward. If every serious competitor can access excellent models, the question becomes what each competitor builds around them: the harness, context, workflow, evaluation suite, permissions, integration, institutional knowledge, and operating design. The installation becomes the product.
Stall below. Enterprise appetite for AI is enormous, but appetite and deployment are not the same thing. Organizations can sign large cloud commitments, buy model access, run pilots, create task forces, and still fail to change how a meaningful workflow operates. The failure tends to happen where abstractions meet organizations. The demo assumes clean data; the company has seven systems. The workflow assumes the documented process; operators use another one. The agent assumes it can take an action; compliance requires approval. The model assumes context is available; the decisive information lives in a PDF, an inbox, a person’s memory, and a badly maintained database. These are not edge conditions. They are the enterprise.
Imitation across the market. The role that once looked idiosyncratic is being reproduced across the AI stack. Frontier AI companies, cloud providers, data platforms, and rapidly scaling applied-AI businesses increasingly use field-heavy engineering motions because all of them are discovering the same thing: the product does not finish at the API boundary. The interesting signal is not that companies copy a fashionable title. It is that companies with very different products keep rediscovering the same organizational structure.
The window. Every technology cycle contains a period in which humans manually perform the work that software will later absorb. The early web was full of hand-built pages before content-management systems standardized publishing. Early cloud adoption required armies of migration specialists before the process itself became increasingly automated. Enterprise AI is in the same phase.
Today, field teams manually discover workflows, structure context, build evaluation sets, identify failure classes, configure permissions, encode domain language, and wire agents into production systems. Some of that work will disappear. It is supposed to. The important question is who captures what is learned before it disappears.
Every deployment produces residue: recurring problems, common integrations, reusable ontology patterns, repeated evaluation structures, standard approval flows, predictable objections, common governance requirements. The company that captures that residue gets a roadmap paid for by real customers. The company that fails to capture it simply sells more labor.
The manual work of this decade is the raw material of the products of the next one.
The field is where that material is being generated.
The title is already suffering from its own success. “Forward-deployed engineer” can now mean implementation engineer, solutions architect, data engineer, customer engineer, technical account manager, AI consultant, product engineer, pre-sales engineer, or some hybrid of all seven. Titles are cheap. The structure is what matters.
A useful definition has three clauses: an engineer embedded at the customer’s constraint, building production machinery from the customer’s real cases, with an explicit duty to convert repeated deployment learning into product.
Each clause eliminates a neighboring role. Remove embedded at the customer’s constraint, and the engineer can remain technically excellent while being too far from the real problem. That is conventional product development. Remove building production machinery, and the role can diagnose, recommend, facilitate, and advise without ever carrying the outcome into operation. That is consulting. Remove convert repeated learning into product, and the company can become extremely good at bespoke implementation while never producing leverage. That is a body shop.
The FDE sits at the intersection.
This is also why the comparison with consulting is useful but incomplete. Traditional consulting built enormous businesses around a leverage pyramid. Senior judgment was scarce and expensive. Junior labor gathered information, created analysis, produced artifacts, and moved the project forward. The model scaled because many hours could be sold underneath a smaller number of senior people.
AI attacks the bottom of that pyramid first. Research, first drafts, analysis, reconciliation, formatting, documentation, and many forms of implementation can increasingly be performed by machines. The part that remains scarce moves upward toward judgment, architecture, domain understanding, trust, and accountability.
The forward-deployed model is almost the inversion of the old pyramid: send fewer, unusually capable people armed with enormous machine leverage; build the operating system instead of the recommendation; encode knowledge into the customer’s machinery and the vendor’s product; optimize not for utilization but for the speed at which customer-specific work becomes reusable capability.
This is why the FDE should not be measured as an expensive implementation resource. The right question is: what does each deployment leave behind? If the answer is only revenue, the motion is weak. If the answer is revenue plus customer capability plus reusable product knowledge, the motion compounds.
The first use case determines much of the engagement’s fate. Enterprise AI programs often begin with the wrong instinct: find the largest imaginable opportunity. The transformation office wants something strategic enough to justify executive attention, so the first project becomes a moonshot. That is usually backwards.
The first deployment should maximize the probability of producing a verified, meaningful win. Score the wedge against six properties: volume, whether the work happens often enough for improvement to matter; specifiability, whether the task can be described precisely enough for a machine to attempt it; verifiability, whether success and failure can be judged without relying entirely on opinion; pain, whether solving it matters enough that the organization will notice; then reversibility, whether early failures can be contained; and data proximity, whether the information required to perform the work is actually accessible.
This creates an important discipline: refuse both ends of the temptation curve. Refuse the moonshot whose prestige disguises terrible deployment characteristics, but also refuse the trivial automation nobody will care about. A tiny administrative win may be easy, but if nobody feels the outcome it generates no organizational momentum. The first deployment has to be small enough to succeed and important enough to recruit the second one.
The scorecard itself should become an artifact. Write down why the wedge was selected, why other candidates were refused, what success means, what must remain reversible, and what evidence will count. The FDE is already teaching the customer an important habit: AI deployments should be chosen by operating properties, not executive excitement.
Once the wedge is selected, the real discovery begins. Most companies already possess process documentation. The FDE’s job is not to believe it.
The first phase is process archaeology. Watch the work happen. Ask what happens after the flowchart ends. Find the manual exceptions, duplicated data entry, emergency paths, informal approvals, CSV exports, shadow systems, and spreadsheets nobody mentioned. The gap between the official process and the practiced process is often where the product opportunity lives.
This requires humility. The engineer cannot arrive assuming the customer’s strange…
