Forward-Deployed Engineer Model

Value in the deployment, not the code

The model describes a hybrid operating structure in which engineers are embedded inside a customer's real workflows rather than selling a tool over the wall. Alex Karp states it plainly: the company "was never pure software."¹ He describes four layers, forward-deployed engineers embedded with the customer, the same role amplified by AI, an orchestration layer that makes the humans, models, and customer systems act as one, and primitives, which he defines as taking "the tribal knowledge of an institution and coding it into logic" that is then extended in models. His sharpest formulation of where the value sits is that it "is not a monolithic codebase that never changes. It is the people, the deployment, the relationships."

Karp presents the model as the answer to a long-running critique. For two decades the bear case was whether the company was "a consulting firm" with no real software, a framing he says kept some investors out. He inverts it: the services layer is "underrated" and "crucial" in an AI world, because what clients buy is transformation on a timeline that "would have taken 3 years and would never have happened," delivered in months. He describes the difficulty of assembling the hybrid as the source of the moat, noting that "all these places that made fun of us are running around trying to get FDEs," and ties it to his broader claim that a business's value is "directly convergent with people's inability to understand what you're doing." Competitors who assemble the pieces still stop short of charging on delivered value: even once they have assembled it, in his words, they are "still not saying, we're going to charge on value."¹

Why a bare model degrades over a long deployment

Karp gives an operational reason the embedded layer resists commoditization. A model may score "160 against a test," but institutional transformation is "a thousand tests" over time, and "by the 50th step it's zero IQ." The forward-deployed stack of embedded humans, orchestration, and encoded primitives is what carries a deployment across that long chain of differentiated, regulated, real-world steps where a bare model degrades, which he offers as the reason clients ask for more deployment capacity rather than less.

The pattern observed from the losing side

Ryan Petersen supplies an independent instance from freight, which he calls the original forward-deployed model, except the embedded people were logisticians rather than engineers.² He describes a hyperscaler that runs its logistics through a direct competitor's 130 full-time embedded employees, badged and on-site, and concludes "we cannot crack the door at that place" because all the decision-making is done by the competitor. He calls it "an insanely great competitive advantage" and says he is "jealous," which is the same moat Karp describes, observed from the side that is locked out.

Petersen's account also illustrates the key-person fragility that both founders treat as an open question. He describes a competitor's embedded logistician who was laid off after an acquisition, was hired by the customer, and chose Flexport "to get back at them," so the relationship walked out the door with the person. Petersen's own strategic answer is to build owned-employee deployment globally: Flexport ships to roughly 147 countries but staffs about 22 of them directly, a gap he treats as the room still left to close. The two accounts together frame the durable version of the model as owning the deployment and the encoded institutional knowledge rather than the software, a pattern adjacent to enterprise coopetition, where the owned infrastructure and relationship, not the workflow layer, is the thing competitors cannot easily copy.