The fastest way to build AI that works in an operation is to have the engineers work inside the process with the people who run it, where the real process is visible. That is the forward-deployed model, and it fits operations particularly well, provided the engineers stay long enough to run what they build.
Forward-deployed engineering puts the builder where the problem is
Wikipedia describes a forward-deployed engineer as "a customer-facing software engineer who works for a company that makes a product and helps implement that product within a client company, often working alongside the client's employees for a defined period of time." The same article, citing The New York Times, The Wall Street Journal and a 2009 article in Science, says the term "forward-deployed" comes from U.S. military jargon and that the role "was popularized by Palantir Technologies, which used this title for staff by 2009."
Marty Cagan of the Silicon Valley Product Group gave the clearest statement of why the model works, in a September 2025 article: "The core of the FDE model is that you send empowered engineers (and other product creators) directly to spend intense time embedded with customers, with the express purpose of learning the problem and solution space, so they can discover a solution that will achieve the necessary outcome."
The important words are "learning the problem." The model assumes the customer cannot fully describe what it needs, and that the engineers have to find out by being there.
Operations problems cannot be specified from a distance
That assumption holds more strongly in operations than almost anywhere. A billing inquiry process, a claims queue or a back-office reconciliation runs on knowledge that lives in people:
- the unwritten rule that disputes from one region go to a particular team lead;
- the workaround for the system that drops a field on certain account types;
- the judgment about which customers get a call instead of an email;
- the exceptions, which rarely appear in the process documentation and often consume a large share of the hours.
None of that survives a requirements document. Each item is small on its own, and together they decide whether an AI system can carry real volume or needs a person to rescue it ten times a day. A process document will say that disputes over a set amount go to a supervisor. It will not say that the supervisor is out every other Friday and the queue then routes to whoever answers first. As argued in the exceptions post, the cases that do not fit are where AI implementations succeed or fail, and they are visible only up close.
A ticket queue strips out the context operations runs on
| Ticket-queue delivery | Forward-deployed delivery in an operation | |
|---|---|---|
| Where engineers work | In a separate team, often a separate building | With the people who run the process |
| How requirements arrive | Written requests, triaged and prioritized | Observed in real cases, then confirmed with the team |
| Who sees the exceptions | The person who files the ticket, if they remember | The engineers, as the cases happen |
| Time to change a rule | Set by the release cycle and the backlog | Shorter, because the process owner and the engineers work side by side |
| What gets built | What was asked for | What the work turns out to need |
| After go-live | A support queue | Engineers who know the system still close to the numbers |
The ticket queue exists for good reasons: it protects engineering time and keeps priorities visible. For a product used by thousands of customers, it is the right tool. For one critical process in one operation, it filters out exactly the detail the AI system needs. By the time a request has been written, triaged and scheduled, the case that prompted it has been closed by hand and the person who noticed the pattern has moved on.
The model's weak point is what happens after the engineers leave
Forward-deployed engineering has a known failure mode. Engineers embed, build something tailored, and move on to the next customer. Writing about Palantir, Cagan names the risk: if all it had were forward-deployed engineers, it "would quickly end up with thousands of large, bespoke solutions that would need to be maintained and improved indefinitely." His answer, for a product company, is a platform team that turns what forward-deployed engineers learn into reusable product.
An operation faces the same risk from the other side. The bespoke system stays behind, and the engineers who understood it are gone. Inputs drift, a connected system changes its fields, the exception queue grows, and nobody left in the building can adjust the rules safely. The "defined period of time" in the Wikipedia definition is the gap.
In operations, the engineers should stay to run what they build
The engagement has to extend past go-live. The engineers who studied the process and built the system keep operating it with the team that owns the process: watching accuracy and volume, clearing the backlog of rule changes, tuning thresholds as the exception patterns shift, and adapting the integrations when a vendor upgrade lands. The deployment becomes the start of the work, and the Run step in the AI implementation guide describes what that operating work involves.
That is the pattern Manthle's AI engineers follow: they take one process at a time, work inside it with the people who run it, build the AI system with a person on the exceptions and keep running it with the client's team once the pilot works. The commercial side of that arrangement is set out under AI implementation services.
Staying also solves the change problem. People adopt a system faster when the engineers who built it are the ones they talk to when it gets a case wrong; the reasoning is in AI change management.
Questions to ask before bringing forward-deployed engineers in
- Will the engineers spend time with the people doing the work, or only with managers?
- Will they work in your systems from the first weeks, with your real cases?
- Who decides when a rule changes, and how fast can that happen?
- What happens when the engagement period ends: who runs the system, and who can change it?
- Is the documentation written for your team, so the knowledge does not leave with the engineers?
A good answer about life after the engagement period names the people who will run the system and how a change gets made. That is accountability after launch, the part of forward-deployed engineering an operation needs.