Forward Deployed Engineers: When the AI Lab Sells the Build

In May 2026, both of the largest US model labs stood up enterprise services ventures staffed with forward deployed engineers who sit inside client companies and build. That is a real structural change, not a press release. The party recommending your architecture is now, increasingly, the same party selling the runtime it will call.

We want to be careful here, because the easy version of this argument is cynical and wrong. These are good engineers with genuinely deeper model knowledge than almost anyone else can hire. For a lot of companies this will be the best offer on the table. It is still a concentration of risk that belongs on the page when you price the deal.

What changed when the model labs started selling integration?

Both announcements landed on May 4, 2026. Anthropic's joint venture came together at a $1.5 billion valuation with Blackstone, Hellman & Friedman, and Goldman Sachs as founding partners, and $300 million committed each from Anthropic, Blackstone, and Hellman & Friedman. OpenAI's venture, The Deployment Company, raised $4 billion from 19 investors at a $10 billion valuation, with TPG, Brookfield, Advent, and Bain Capital among them (TechCrunch, May 4, 2026).

Both follow the same operating model: forward deployed engineers embedded with the customer, aimed at mid-sized enterprises. Anthropic described an engagement as beginning with its engineering team sitting down with clinicians and IT staff to build tools that fit workflows people already use.

That is a services business. Two years ago the labs sold capability and left the integration to consultancies, agencies, and internal teams. Now the integration layer is something the model vendor sells directly, with its own margin attached.

Why the distribution detail matters more than the valuations

The valuations got the headlines. The structural detail worth reading twice is where the money came from.

Both ventures raised from asset managers, and those asset managers get preferred sales access to their own portfolio companies. The capital is not just capital. It is a distribution channel into hundreds of mid-market businesses that these firms already own a stake in.

Think about what that means from inside one of those portfolio companies. The AI implementation partner arrives with a warm introduction from your own investor, technical credibility the market agrees is real, and a commercial interest in one particular inference bill. Every one of those three things is individually fine. Together they mean the pressure to standardize on one lab is going to feel like consensus rather than like a sales motion.

We should say our own position plainly, once: we build AI systems for teams, so these ventures compete with us directly. Weigh what follows accordingly, and apply the same test to us that we are about to describe.

Is this actually bad for a mid-market buyer?

Often, no. It is worth being fair about what is genuinely good here.

Forward deployed engineering works. Putting the people who understand a model's failure modes in the same room as the people who understand the workflow is how you avoid the classic disaster where a technically impressive system solves a problem nobody had. The labs can staff that with people who have read the model's evals rather than its marketing. For a company with no internal AI capability and a real deadline, that is a strong offer.

The cost is not the price. It is optionality. A deployment designed, staffed, and tuned by the vendor of one model tends to become a deployment that only makes economic sense on that model, not through any bad faith, just through a thousand reasonable local decisions that each assume the same runtime.

The consultancies had a version of this conflict first, when the firm recommending the platform also billed the implementation. The market eventually learned to price that in and ask harder questions. The lab-owned version is newer, technically much stronger, and deserves exactly the same scrutiny rather than more or less of it.

What does this change about how you evaluate a vendor?

Less than you would think about architecture, and more than you would think about process.

The architectural answer has not moved. Lock-in does not live in which model you call, it lives in whether your orchestration, your evals, and your data plumbing are yours. We wrote that frame up in detail in how we keep vendor lock-in out of what we ship, and nothing about May 2026 changes it. If anything it raises the value of having done that work before the engagement starts.

What does change is who you are asking. When the integrator was neutral, "which model should we use" was a technical question with a technical answer. When the integrator has a preferred runtime, that same question now has a commercial component, and the honest thing to do is name it out loud in the room rather than pretend it is absent.

So the questions worth asking any AI vendor, us included, are mostly about what you keep:

• Who owns the eval harness when this is done? Whoever can score a competing model against your actual tasks owns every future switching decision. If that lives with the vendor, you have outsourced the argument, not just the build.
• Does the orchestration run somewhere we control? Control flow, retries, approval gates, and tool definitions inside a vendor's proprietary runtime turn a migration into a rewrite.
• What does a provider switch cost, in weeks? Ask for a number. The answer tells you more about the architecture than any diagram.
• Can we export our prompts, our traces, and our data without your help?
• What happens to this system if you stop selling it?

If the honest answer to what it costs to leave is that nobody has measured, that is the finding. You do not need to act on it. You do need to know it before you sign, because it is the one number that quietly sets your negotiating position for every renewal after this one.

What we do on our own builds

We run three platforms of our own: Smile PreVue, Howdy Dispatch, and RunLink. On each one we picked a lab for a decisive reason rather than a general preference, and in every case the orchestration and the evals stayed in our own codebase.

The clearest example is the healthcare-adjacent work. Smile PreVue handles patient data, so the decisive constraint was HIPAA and a signed BAA, and that requirement narrowed the field before any capability comparison started. The model was chosen second, inside the constraint. That is usually the right order, and it is the opposite of how most vendor conversations are structured, where capability is discussed first and compliance is treated as a procurement detail to sort out later.

We are not neutral about this and we are not pretending to be. We build provider-agnostic because we are the ones who have to live with the consequences when the model layer moves, and it has moved several times in 2026 alone. A system that cannot be re-pointed cannot benefit from any of that movement. This is the same reason the evaluation work sits in the figure-it-out phase of how we work rather than getting deferred until after something is running.

The takeaway

The labs selling integration is not a scandal and it is not a reason to avoid them. It is a change in who holds which incentive, and incentives are the part of a vendor relationship that survives after the enthusiasm wears off.

Buy the engineering if the engineering is good. Just keep the three things that let you leave: the evals, the orchestration, and the data. Own the ability to walk, and you will almost certainly never need to use it. That is a fine outcome, and it is a much better position than discovering the cost of leaving at renewal time.

If you want a hand thinking through AI integration for business without handing over the parts that matter, tell us what you are building. If you would rather build the muscle in-house, that is a real option too, and it is what /learn is for.