Microsoft's US$2.5 billion bet on deployment, and how to see whether yours pays off

When one of the largest software vendors in the world spins up a US$2.5 billion unit to sit inside its customers' buildings and prove AI works, that is a signal worth reading carefully. On 2 July 2026, Microsoft announced Microsoft Frontier Co. The company said it is investing US$2.5 billion and moving 6,000 employees into the unit to be embedded with clients, in a practice known as forward deployed engineering (Source: CNBC). It is led by Rodrigo Kede Lima, who previously ran Microsoft's Asia business (CNBC).

The timing tells the story. The move came two days after Amazon committed US$1 billion to its own Forward Deployed Engineering organisation on 30 June (CNBC). Two of the biggest names in software are now putting money behind the same view: the hard part is deployment, not access to the models.

What the vendors are actually conceding#Link to this section

The subtext here is that buying the tools was the easy part. Amazon's own framing is that the constraint is deployment capacity, with an initial pod of five or six engineers embedded in a customer to get systems into production (CNBC). Microsoft's Judson Althoff, CEO of its commercial business, described the most success coming from a methodical approach to building out an intelligence platform (CNBC).

This matches the evidence that started the reckoning. MIT's Project NANDA found that 95% of the generative AI pilots it studied showed no measurable profit and loss impact, against US$30 to 40 billion of enterprise investment in generative AI (Source: MIT Project NANDA, The GenAI Divide: State of AI in Business 2025). The same research found that over 80% of organisations have piloted tools, while only a fraction reach production at scale (MIT Project NANDA).

So the vendors are right that outcomes get won in deployment. What gets less attention is that outcomes also get proven in deployment, and proof is a measurement problem, not an engineering one. Embedded engineers can build the system. On their own, they can't tell you whether your people actually use it, whether it saves time, or whether you are paying for seats nobody touches.

What to measure once the engineers arrive#Link to this section

If you are about to host a forward deployed team, or you already run a set of AI tools, here is the short list worth tracking. None of it requires waiting nine months for a case study.

Active adoption, not licences bought. Count the share of provisioned seats used in a meaningful way in the last two weeks, by team. Licences purchased is a cost number. Weekly active use is an outcome number. As a starting point, good looks like adoption climbing and holding above 60% within a quarter for a tool you are paying full price for. Flat or falling use after month one is your early warning that a rollout is stalling.

Time saved, self-reported and specific. Ask people how much time a tool gives back, and on which tasks. Self-reported time is imperfect, but tracked consistently across a whole team it shows direction and size. Watch for the gap the MIT work flagged, where people check outputs so heavily that the promised gains never arrive. If reported time saved is falling while usage rises, you have a trust problem, not a productivity win.

Unused seats. Multiply unused or barely used seats by their cost. This is the single number that turns a vague worry into a defensible line for a CFO. As a starting point, good looks like waste under 10% of your AI budget. Anything higher is a renewal conversation waiting to happen.

Shadow AI. The MIT research described a shadow AI economy, where people use personal tools even when official pilots fail (MIT Project NANDA). If your team leans on tools nobody approved, that tells you where the real value sits and where your approved rollout is missing.

Look at these together, by team, over time. One tool can be thriving in finance and dead in legal. A blended company average hides exactly the detail you need to act on.

The measurement-first point stands whether or not you ever hire a forward deployed team. When a vendor arrives to prove outcomes, you want your own baseline in hand first, gathered independently, so the scorecard isn't marked entirely by the people being paid to deliver a good grade. That is the difference between a number you present to your board and a number you hope is true.