Their Engineer, Your Standup

On May 4, 2026, Anthropic announced a $1.5 billion enterprise services venture with Blackstone, Hellman & Friedman, and Goldman Sachs. Seven days later, on May 11, OpenAI launched the OpenAI Deployment Company with $4 billion, nineteen investors anchored by TPG, and a same-day acquisition of a British applied AI consultancy called Tomoro for its 150 forward-deployed engineers. Fifty-two days after that, on July 2, Microsoft launched Frontier Company with $2.5 billion and 6,000 engineers. Its early clients include the London Stock Exchange Group, Land O'Lakes, Unilever, and Novo Nordisk. The consulting firms that used to run projects like these (Accenture, Capgemini, EY, KPMG, PwC) showed up on the announcement as partners supporting the rollout.

Three labs. Three announcements. Eight billion dollars. Same playbook.

Somebody from a model lab is now walking into your building.

What Actually Happened

The public framing is that the labs are helping enterprises fix a broken adoption story. MIT's Project NANDA report from August 2025 counted 300 enterprise generative AI initiatives and found 95% produced zero measurable return. The number circulated through boardrooms for a full year. It stuck. When CFOs read it, they froze budgets. When boards read it, they asked awkward questions. The labs read it too, and the labs saw the shape of the problem: their buyers wanted outcomes, not tokens.

So the labs stopped selling tokens and started selling people.

That is the actual change. Everything else is packaging. When Microsoft's Rodrigo Kede Lima describes the Frontier Company, he calls it "AI transformation." When OpenAI describes its Deployment Company, it calls it building organizations "around intelligence." When Anthropic frames its Blackstone venture, the language is applied AI at scale. The words vary. The move is the same. The lab now has employees with badges walking into your headquarters, sitting in your daily meetings, learning your compliance bar, and shipping production code against your data.

This is the Palantir playbook. Palantir has run forward-deployed engineers for two decades. The engineer flies in, learns the client's operations, ships code against the client's data, and stays. What is new is not the model. What is new is that OpenAI, Anthropic, Microsoft, Amazon, Google, and Databricks all decided in the same eight weeks to copy it.

That coordinated timing is not a coincidence. It is a repricing of what generative AI is.

The Generative AI Business Use Case Has Changed Shape

If you are a CEO or founder trying to figure out where generative AI business use cases actually pay off inside your company, the last five years told you one story and the last six weeks told you a different one.

The story from 2020 through the first half of 2026 was that generative AI use cases lived inside your team. A product manager identified a workflow. A vendor sold you a subscription. A consultant ran a pilot. You measured a percentage lift on some metric, or you didn't, and you moved on. The generative AI business use case was a project. Projects have owners. Projects have budgets. Projects end.

The story since May is that generative AI use cases live inside a stranger. The stranger has a badge from Microsoft. Or from OpenAI. Or from Anthropic. The stranger sits in your team's daily standup for six months, sometimes twelve. The stranger writes production code against your customer database. The stranger designs the evaluations that measure whether the model is doing its job, and the stranger tunes the model against those evaluations. When the engagement ends, the stranger leaves. The code stays. The dependency stays. The switching cost stays.

This is a different corner of the org chart. It has a different power dynamic. It has a different cost structure. The old cost showed up as software line items. The new cost shows up as embedded people whose payroll runs through a company you do not own.

The Services Layer Was the Prize All Along

Every strategy essay about the AI stack in 2024 and 2025 spent time on the same architectural question. Would the model layer commoditize? If so, where would the margin move?

The labs answered the question. They moved on the answer. In the enterprise, the model layer is a small slice of the pie. Bain and BCG have both put enterprise services spending at roughly six times the size of enterprise software licensing. Deloitte and Accenture and Capgemini and TCS have made careers out of that ratio. What the labs figured out is that if the model is commoditizing, then the way to capture value is to buy your way into the services layer directly, before someone else does.

So they did. Microsoft's $2.5 billion is not for training runs. OpenAI's $4 billion is not for tokens. Anthropic's $1.5 billion is not for research. All of it is for people. People who will bill by the day, embed inside enterprise operations, and generate revenue that looks like consulting revenue, not software revenue. The labs are becoming vertically integrated services companies with a model on the side.

For a CEO thinking about generative AI business use cases, this is the biggest structural change of 2026. You are no longer buying software from a model lab. You are buying labor from a model lab. And the labor sits in your building.

The Consultants Got Demoted

Look carefully at the Microsoft Frontier Company release from July 2. Read the sentence about the consulting partners.

Accenture, Capgemini, EY, KPMG, and PwC are named in the release. They are listed as partners. But the release says Microsoft engineers lead the engagement. The consulting firms support the rollout.

That sentence describes an inversion that would have been unthinkable in 2021. Historically, when a Fortune 500 company deployed a big enterprise system, the systems integrator ran the show. Accenture or Deloitte was the general contractor. The software vendor was a subcontractor. The vendor showed up when there was a technical problem, then went away. The integrator collected the fees and owned the relationship.

Frontier Company inverts the roles. Microsoft is the general contractor. Accenture is the subcontractor.

OpenAI has done the same thing. The OpenAI Deployment Company lists Bain & Company, Capgemini, and McKinsey among its founding partners. But OpenAI's own engineers lead the client engagement. The consulting firms show up to fill the seats OpenAI cannot fill fast enough.

If you are one of the big consulting firms, this is a strategic loss you cannot easily recover from. If you are a CEO watching this from the outside, the question is different. The question is: whose interests does the person embedded in your operations actually represent?

What the Embedded Engineer Actually Does to Your Business

Watch what happens week by week when a forward-deployed engineer from a model lab shows up in your building.

Week one. The engineer maps your workflows. They ask which decisions get made where, which data sits where, which handoffs happen between which teams. They take notes. They spend time with your operations people, your product people, your data people. They learn the shape of your business faster than a new director would.

Week four. The engineer starts writing code. They connect their lab's model to your data. They design evaluations that measure whether the model is producing outputs your team can trust. They build a small tool for a specific team. It works. Somebody in that team says the thing every embedded engineer wants to hear. "Can you make it do this other thing too?"

Week twelve. The tool is used every day. Three teams depend on it. The evaluations live in a repository the engineer set up. The prompts live in a prompt library the engineer designed. Nobody on your side knows how it works well enough to change it without breaking it. Nobody on your side wrote the tests. Nobody on your side chose the model. The engineer becomes the person who answers the question, "Can we switch to a different provider?" And the engineer answers that question honestly, with a shrug and a number. Switching would take four months and cost eight hundred thousand dollars.

Week twenty-four. The engagement ends. The engineer leaves. Your team keeps using the tool. You keep paying the model lab. The switching cost has quietly reached the point where nobody bothers to discuss switching anymore. The dependency is complete.

You did not buy an AI product. You bought a set of switching costs, delivered by a person whose actual employer is the model lab.

This is not a bad deal. It might genuinely be a good deal for many companies. The point is that it is a specific deal, with a specific structure, and most CEOs are signing versions of it right now without thinking about what it actually is.

Why This Is a Trojan for Lock-In

The forward-deployed engineer is the most effective lock-in mechanism the enterprise software industry has ever produced.

Traditional software lock-in worked through data formats and integration complexity. Oracle databases had proprietary schemas. SAP had years of configuration nobody wanted to redo. Salesforce had org charts full of admins whose careers depended on the platform. Migration was painful because the artifact was hard to move.

The FDE lock-in works differently. The artifact is not hard to move in a technical sense. The AI code the engineer writes could probably run on a different provider's model with modest rework. The lock-in is not in the code. The lock-in is in the tacit knowledge the engineer holds. The lock-in is in the evaluations they designed. The lock-in is in the workflows they redesigned to fit the model's behavior. The lock-in is in the sequence of prompt versions they iterated on. The lock-in is in the relationship they built with your operations team. When the engineer leaves, that knowledge does not leave with them, exactly. It gets left behind, embedded in your systems, but it is embedded in a way only the lab knows how to service.

Palantir understood this in 2005. Microsoft, OpenAI, and Anthropic understood it in 2026.

Here is the clean summary. When you rent a forward-deployed engineer, you are giving the model lab a soft lien on your operational intelligence. Every week the engineer works, the lien grows. When the engagement ends, the lien is fully written. You cannot repay it by writing a check. You can only repay it by letting the model lab keep collecting rent.

The Land O'Lakes Signal

One of Microsoft Frontier Company's launch customers is Land O'Lakes. Land O'Lakes is a hundred-year-old dairy cooperative in Minnesota. It sells butter and animal feed and crop protection products. It has 9,000 employees. It has never been on the leading edge of software adoption, and it has no reason to be.

If Land O'Lakes is a launch customer for Microsoft's forward-deployed engineering unit, that tells you something.

It tells you the labs are not selling to Netflix and Stripe anymore. The tech-first buyers already built their own AI teams. They hired their own engineers. They wrote their own evaluations. They own their own capability graph. The labs cannot embed inside those companies because those companies do not need the embedding.

The buyers who need the embedding are the ones without an AI engineering culture. The mid-cap manufacturer. The regional bank. The insurance carrier. The consumer packaged goods conglomerate. The dairy cooperative. These are the companies where the CEO reads the MIT paper, freezes the AI budget, and then gets a phone call from Microsoft saying, we will send engineers, we will own the outcome, we will meet you on your terms.

If you run a company that fits this profile, meaning any company that is not a top-100 software business, the pitch will land on your desk in the next twelve months. The pitch will be persuasive. The pricing will look reasonable. The reference customers will be impressive. And you will need to decide, in that moment, whether you want a piece of your operations to belong to a company whose real business is training the next model.

What CEOs Should Actually Do

Do not refuse the meeting. Refusing to talk to Microsoft or OpenAI or Anthropic about applied AI is a losing strategy. These are among the most sophisticated technology organizations that have ever existed. Their engineers know things your team does not.

But do not sign the outcome-based contract without architecting the seam yourself first.

Architecting the seam means owning three things before you let any external engineer sit inside your operations.

Own Your Workflows

Before an engineer from a lab writes a single line of code inside your building, you should have a written map of the workflow they are going to touch. You should know what the current handoffs are, what the current failure modes are, what the current cycle time is. If you do not know these things, the engineer will learn them for you and then own them. That is the first switching cost.

Own Your Evaluations

The evaluations that measure whether an AI is doing a good job at your business are the most valuable artifact your company will produce in the next five years. They are the specification of what "good" looks like inside your operations. If a lab writes them, the lab owns your definition of good. Write your own evaluations, in your own repository, before the engineer arrives. Let the engineer test against them. Do not let the engineer create them.

Own Your Capability Graph

Every model lab has a legitimate interest in getting your workflow to depend on their specific model. Your interest is the opposite. You want to be able to swap the model without swapping the workflow. That means building the seam yourself. It means keeping the prompts, the tool definitions, the retrieval pipeline, and the orchestration in a repository your team controls. The lab's engineer can help you make it excellent. The lab's engineer should not be the person who wrote it.

If you own these three things going in, the forward-deployed engineer becomes a resource. If you do not own them, the forward-deployed engineer becomes a fact about your future.

Why This Cannot Be a Purchased Solution

The tempting response to everything above is to hire another vendor to sit between you and the lab. The systems integrators would love this. So would the boutique AI consultancies popping up in every major city. The pitch would be: we will architect the seam for you, then we will run the FDE relationship on your behalf.

That pitch is a repeat of the problem one layer up. Any external firm that owns the seam for you also owns your capability graph. You are just picking which lab or which consulting firm gets the lien, not eliminating the lien.

The only durable answer is that the seam has to be architected by a group that reports to you, keeps its work inside your repositories, hands off to your team, and leaves the building. Not embeds. Departs. That is a different kind of engagement, and a different kind of relationship, and it is the one that keeps you in charge of your own operational intelligence.

At Agor AI Advisory, this is the engagement we run. We show up to design your seam, write your first set of evaluations, build the initial capability graph in your repositories, teach your team how to keep it alive, and hand the keys back. We do not work for OpenAI. We do not work for Microsoft. We do not work for Anthropic. We do not sell you tokens. We do not depend on a lock-in for future revenue. Our incentive is to make you the owner of your own generative AI business use cases, not a tenant in someone else's operations.

If your board is about to sign a contract that puts a forward-deployed engineer inside your operations, get the architecture right before you sign. The switching cost of getting it wrong is the highest switching cost the enterprise software industry has ever priced. Schedule a strategic consultation with us today.