Forward deployed engineers can't fix how the work runs

Your board wants AI in production this year. Your CIO has a shortlist of partners. Almost every name on it now promises the same thing: engineers who will sit inside your company and make the AI work. It sounds like the answer. For most mid-market companies and enterprise divisions, it is half of one.

A forward deployed engineer is a software engineer who works inside the customer's business instead of at the vendor's office, building and fitting the system to how the customer actually operates. Palantir created the model because its software was too hard for customers to adopt alone. The engineer moved in, learned the workflow, and stayed until the software was in use.

In 2026 the model went mainstream. The frontier AI labs built deployment arms around it, including Anthropic's Ode and OpenAI's Deployment Company. Accenture and Microsoft launched a joint forward deployed engineering practice on March 18. TechCrunch called forward deployed engineers the AI industry's latest talent obsession. When the labs, the global integrators, and a wave of specialist firms adopt the same model in the same year, buyers should pay attention. They should also ask what the model leaves out.

Start with what it gets right. Distance kills AI projects. A team that builds from a statement of work three time zones away ships something that technically works and nobody uses. An engineer in your building closes that gap. They see the real workflow, the workaround living in a spreadsheet, the approval nobody ever wrote down. That is a real improvement over the old way of buying software, and I would not argue anyone back to it.

Here is where it stalls. An engineer in your building inherits your operating model on day one. If decision rights are unclear, the engineer builds around them. If three teams own the same process, the engineer picks one or builds for all three. If the weekly meeting reopens last week's decisions, the engineer waits. None of that is an engineering problem, and no amount of engineering talent fixes it. You can't implement AI on a broken process. You can only make the broken process run faster.

Consider what an AI agent actually needs to do its job. Picture one built to approve customer credits. It needs a rule for who can approve what, up to which amount, and what happens when the customer is also in a contract dispute. In most companies that rule lives in three people's heads and changes depending on who is in the office. A forward deployed engineer can build the agent in weeks. What the engineer cannot do is decide the rule, because deciding it is an executive act. It means telling one leader they no longer own a decision they have owned for years. That conversation is the work, and it sits outside any engineering statement of work.

Look closely at how forward deployed teams are staffed and you find the same gap every time. They embed engineers. They leave the executive seat to you. Somebody has to own the business result: which decisions the system is allowed to make, which number has to move, and who changes how they work when it lands. In most proposals that owner is the client, often a CEO who already has the board, the plan, and an integration competing for the same calendar.

I've been in this chair nine times. I spent thirty years inside nine PE-backed technology companies, the last twenty running them as President or CEO. The pattern held every time a new system arrived. The technology was rarely what failed. What failed was the operating model around it: the decision nobody owned, the meeting that never forced closure, the hero who carried the process in their head. Better engineers never fixed that. Fixing the operating model did.

In one KeyDelta engagement, a managed IT services company had a strong product, real demand, and a talented team, and still could not execute. Decisions took five months because everyone had to agree. 83% of pilots died in limbo, never reaching a go or no-go decision. More engineers would have produced more pilots. The work started instead with decision rights and a cadence that closed decisions in the room. Decision cycles went from five months to days, and 19 of 23 pilots converted.

The build still matters. In another engagement, a national managed services provider had already tried AI for sales training, and the tool collected dust because the lag made it feel like talking to a bad chatbot. The rebuild brought voice latency under 500 milliseconds, and rep adoption went from 18% to 92% in nine months. That is engineering, and it is the half of the job forward deployed engineers do well. Generated is not the same as used. The point is not that engineers matter less. It is that they need something solid to build on.

This matters more below the Fortune 500. A senior forward deployed engineer is expensive, and the largest programs concentrate where the accounts are largest. Mid-market companies and enterprise divisions get a smaller version of a model built for someone else. They also have less room to absorb a failed build. A division running lean cannot spend a year learning that its operating model was the constraint all along. So what should a mid-market company or an enterprise division ask for? Both halves. A forward deployed operator at the leadership table: a senior executive who has run a company, owning decision rights, the scorecard, and the business result. Operators working with your functional leaders to redesign the workflow where it happens. And forward deployed engineers who build on what the operators fixed, with your users inside the build from the first sprint. Forward Deployed Operator is our term for the half the market left out.

Here is what that looks like in practice. In the first weeks, senior operators assess the operation, document who decides what, and install a weekly cadence that closes decisions instead of reopening them. They prioritize the quickest wins with the biggest return, and the first measurable result typically lands by day 30. The engineers start building on the parts of the operation that now hold, with the people who will use the system inside the build and trained before cutover. By day 90 the process runs through your own team. Nobody from outside is required to keep the decisions closing.

There is one more thing the engineer-only model tends to skip: what happens after go-live. AI does not stand still. The model you built on can be replaced in roughly a year, and a vendor can retire one with as little as 60 days' notice. Your business changes, the security landscape changes, and the economics of running the system change. Someone has to keep every system current. You can own that internally, or you can choose a partner to own it. What you cannot do is assume the build was the finish line. The build is where the operating work starts paying off.

If you are evaluating forward deployed engineering partners, ask three questions. Who owns the business result, by name? Who fixes decision rights and cadence before the build starts, and how long does that take? What runs without them on day 90? If the honest answer to the first question is you, the answer to the third is usually nothing. If you are not sure whether your own operating model can carry AI yet, start there. Our AI readiness assessment takes two minutes and scores the five things that decide it: vision, outcomes, ownership, cadence, and systems. It will tell you which one to fix first.

Engineers in your building are a good idea. Engineers in your building with nobody owning the result are an expensive one. The model that works puts operators at the table and engineers in the build, and leaves behind a system your team runs without us. Heroes don't scale. Systems do.