The deployment that works in the demo and fails in the building
An AI vendor sells a claims-triage product to a large insurer. The model is good. The evaluation numbers are good. The demo, run against a clean sample, is genuinely impressive.
Then it goes into the insurer’s actual environment. The claims system exposes an API that behaves differently from its documentation in three places nobody can explain. Twelve percent of historical records use a status code that was deprecated in 2019 and never migrated. The workflow has an exception path for commercial policies that exists in the heads of four adjusters and in no specification. Security will not permit the service to reach the customer datastore directly. And there is a platform migration underway that means half the integration points the vendor assumed will move within eight months.
None of this is an AI problem. All of it determines whether the AI product produces value.
Someone has to stand inside the customer’s environment and close that distance. That person is a forward-deployed engineer, and the role is growing because the distance is growing.
What the role actually is
The forward-deployed engineer is often described as a consultant who codes, which undersells the distinguishing feature. Consultants advise on a system. FDEs modify one, and the system they modify is not theirs.
In practice the work is a mixture: product engineering, integration, customer discovery, data cleanup, debugging across organizational boundaries, workflow redesign, and enough architecture to avoid building something the customer’s platform team will reject. The proportions change weekly.
The constant is the operating condition. An FDE works inside an environment they did not design, under a delivery deadline, with materially less institutional knowledge than the engineers who maintain that environment day to day. Every decision they make is made with partial information about why the system is the way it is.
The defining constraint of forward-deployed engineering is not technical difficulty. It is making consequential changes to a system whose reasoning you have not inherited.
Why enterprise AI made this role structural
Traditional enterprise software asked the customer to adapt to the product. Implementation meant configuration: field mappings, permission models, a data import, some reports. The product’s surface area against the customer’s systems was narrow and well-defined.
AI products invert this. They adapt to the customer. They ingest the customer’s unstructured data, sit inside the customer’s workflows, make judgements about the customer’s specific operational reality, and increasingly take actions in the customer’s systems. The surface area is no longer a configuration screen. It is the customer’s whole operating environment.
That widening is what created the role. When the integration surface was narrow, a solutions engineer and a good API were enough. When the integration surface is the business itself, someone has to go and live in it.
It also explains why FDE work resists productization. The parts that are generalizable get absorbed into the product. What remains forward-deployed is, by definition, the part that is specific to one customer’s environment. The role does not shrink as the product matures, because the product matures by eating the generalizable half.
Repository state is not architectural intent
Here is the problem that sits underneath all forward-deployed work, and it is worth stating precisely because it is usually described as a documentation failure when it is not one.
A repository tells you what exists. Documentation, where it is current, tells you how some of it works. Neither reliably tells you which parts of the current state are deliberate.
An engineer reading a codebase sees a service that could obviously be merged into its neighbour. The code gives no indication whether that separation is an accident of history, a decision someone would defend, or a boundary that exists because of data residency obligations in one jurisdiction. All three look identical in the source.
We can separate what a newcomer needs into three kinds of knowledge, and they are not equally available.
| Kind of knowledge | Example | Visible to a newcomer? |
|---|---|---|
| Implementation state | Which services exist, what the schema looks like, which APIs are called | High — read the code |
| Operational knowledge | How to deploy, where the logs are, what breaks under load | Medium — ask, or find out |
| Architectural intent | Which boundaries must hold, which patterns are prohibited, which decisions superseded older ones | Low — often unwritten |
Internal engineers acquire the third kind slowly, by being present when decisions are made and by being corrected when they violate one. An FDE has neither the years nor the corrections. They have a deadline.
Coding agents change the economics and sharpen the problem
Give that same FDE a competent coding agent and the delivery maths changes substantially. Unfamiliar code can be explored far faster. Integrations, migration scripts, adapters and tests can be generated in a fraction of the time. Work that was not economically viable for a single customer becomes viable. One engineer can plausibly carry more deployments.
This is a real and significant gain, and it is why FDE organizations are adopting agents quickly.
But look at what the agent brings and what it does not. It brings high implementation capability, fast iteration, and broad general knowledge of how software is usually built. It does not bring any knowledge of why this customer’s software is built the way it is, which of its oddities are load-bearing, or which decisions are still in force.
So the asymmetry that already defined the role gets wider. Before, an FDE with incomplete architectural knowledge produced changes at human speed, which gave review a chance to catch the ones that violated something. Now the same incomplete knowledge produces changes at machine speed. The knowledge gap did not grow. The rate at which it converts into committed code did.
The practical consequence is that the FDE becomes the limiting factor for context rather than for code. Their scarce resource is no longer implementation hours. It is the ability to tell the agent what must remain true in this environment, and to notice when it has not.
Retrieval is necessary and it is not sufficient
The obvious response is to give the agent the customer’s documentation: index the wiki, the decision records, the runbooks, and retrieve them at generation time. This is worth doing. It is not a solution, and the reason matters.
Suppose the customer has an architecture decision record stating that all persistent transactional data lives in PostgreSQL. Retrieval works perfectly: the agent surfaces the record, cites it in its plan, and can restate the rule accurately if asked. It then writes a component that uses SQLite for a local cache that quietly becomes a source of truth, because that was the shortest path to a passing test.
Nothing malfunctioned. Retrieval answered the question it was designed to answer, which is did the agent have access to the decision. It was never designed to answer was the agent prevented from contradicting it. Those are different system responsibilities, and we have written about that separation in retrieval and memory terms elsewhere. Forward-deployed work is simply where the distinction becomes most expensive, because the person best placed to catch the violation is the person with the least context.
The problem has two sides, and they want different things
So far this has been described from the vendor’s side. The enterprise receiving the forward-deployed team has its own version, and it is worth stating because the two sides are usually negotiating without naming it.
The vendor wants velocity. Their engagement is priced, staffed and scheduled on the assumption that the deployment completes in a known number of weeks, and every delay erodes the margin that made the deal work. Agents are attractive to them precisely because they compress that schedule.
The enterprise wants containment. They are permitting an external team, and increasingly an external team’s agents, to make changes inside systems they are accountable for long after the vendor leaves. Their platform and architecture groups are the ones who will maintain whatever gets built, absorb whatever breaks, and answer for whatever violates a commitment made to a regulator, a customer, or another internal team.
The instruments available to reconcile those two positions today are poor. The enterprise can restrict access, which slows the vendor down and pushes work into awkward shapes. It can require review by its own engineers, which consumes the scarcest people it has and does not scale to agent throughput. It can write requirements into the contract, which describes outcomes rather than constraining changes. Or it can trust the vendor, which is what usually happens, and is a decision made on reputation rather than mechanism.
An explicit, machine-checkable boundary is the one instrument that serves both sides at once. The enterprise gets containment that does not depend on reviewer availability. The vendor gets to move quickly inside a known perimeter rather than guessing where the perimeter is and discovering it in review. Neither side has to trust the other’s judgement about a decision neither of them has written down.
The negotiation is usually framed as access and permissions. The more useful frame is: which commitments must hold, who states them, and what checks them.
Where this sits in the delivery stack
It helps to be concrete about which layer is being discussed, because “give the agent better context” and “constrain what the agent may do” get conflated constantly.
A forward-deployed agent workflow has roughly five layers. The model generates. The agent runtime plans, calls tools, and decides what to attempt. The context layer determines what information the runtime sees, which is where retrieval, instruction files and project memory live. The constraint layer determines which proposed changes are permitted. And the execution surface is where the change actually lands: the filesystem, the commit, the pipeline.
Almost all current tooling investment is in the middle three. The context layer in particular has absorbed enormous effort, because it is the layer where progress is easy to demonstrate: retrieve a better document, show the agent citing it, declare the problem addressed.
The constraint layer is thinner, and in most forward-deployed engagements it does not exist at all. Its responsibilities are not exotic. It has to know which commitments apply to the part of the system being touched, evaluate a proposed change against them, and produce a verdict that does not vary with how the task was phrased or how long the session has run. What makes it distinct from the context layer is that it is permitted to say no, and nothing in the context layer is.
Not every decision should become a rule
A caution, because the failure mode in the other direction is real. An organization that tries to convert every architectural preference into a hard constraint produces a system that blocks reasonable work constantly, and engineers respond by routing around it. Over-constraint destroys the credibility of the constraints that matter.
A workable split has three tiers. Some decisions can be expressed mechanically and should be enforced: a prohibited dependency direction, a required persistence technology in a specific domain, a boundary that must not be crossed. Some could be enforced but have not been modelled yet. And some genuinely require human judgement and should stay as guidance for review, honestly labelled as guidance rather than dressed up as enforcement.
For forward-deployed work the first tier is the valuable one, because it is the tier that does not depend on the FDE already knowing the answer.
What good forward-deployed infrastructure would look like
Pulling this together, an FDE organization operating agents at scale inside customer environments needs several things that mostly do not exist as products yet:
- Fast context acquisition. A way to establish what a customer’s architecture actually commits to, in days rather than months.
- Authority, not just documents. A distinction between what a wiki page says and what the organization will stand behind, because the two diverge badly in large estates.
- Scoped applicability. Decisions attached to the parts of the system they govern, so a payments constraint does not fire on the analytics service and get dismissed.
- Machine-evaluable constraints. The enforceable subset expressed so that a check, not a person, can apply it.
- Evaluation before the change lands. A point in the workflow where an incompatible change is stopped rather than discovered.
- A handoff artifact. Something that survives the engagement, which is the subject of the next point.
The handoff problem
Forward-deployed engagements end. The engineer leaves, and what remains is a working system plus whatever was written down about why it works that way.
Historically that has been a slide deck, a README, and a small amount of tribal knowledge transferred in a handover call. The customer inherits an implementation whose reasoning walked out of the building. Six months later their own team treats a deliberate boundary as an accident, changes it, and discovers why it was there.
Agents make this both worse and more tractable. Worse because the volume of code produced per engagement goes up, so there is more implementation carrying unstated reasoning. More tractable because the constraints the FDE had to establish in order to direct the agent safely are, if captured, exactly the handoff artifact that was always missing. The work of making architectural intent explicit stops being documentation overhead and becomes a byproduct of operating agents at all.
Forward-deployed engineering is an early look at the general case
It would be easy to read all of this as a niche staffing topic. It is not, and the reason is that the FDE’s defining condition is becoming everyone’s.
An FDE works inside a system whose architectural reasoning they did not inherit, under time pressure, directing a capable agent that has no access to that reasoning. Now consider a large internal engineering organization three years into heavy agent adoption: multiple teams, high turnover, services that outlived the people who designed them, and agents producing a growing share of the changes. The condition is the same. The FDE just arrived at it first, because they cross an organizational boundary on day one instead of reaching it gradually.
Which makes forward-deployed engineering a useful place to test whether architectural intent can be made explicit, scoped, and enforced, rather than carried in people’s heads. If it works where the context deficit is most severe, it works in the easier internal case.
The practical starting question is not “do we have architecture documentation.” Most organizations do. It is narrower and more uncomfortable: of the architectural decisions this system depends on, how many would actually stop a change that contradicted them? That is a question you can answer against a real repository rather than argue about in the abstract.