Forward-deployed engineering is distribution
Microsoft committed $2.5B and 6,000 engineers to customer-side AI deployment, days after Amazon's $1B version. The hyperscalers concluded the constraint is integration, not model access — services just became a channel.
Microsoft announced a $2.5 billion commitment this week to what it calls its Frontier Company: roughly 6,000 industry experts and engineers placed alongside customers to redesign and deploy AI-enabled work, on-site, inside the enterprise. Days earlier, Amazon reportedly stood up a $1 billion forward-deployed agent organization of its own. Two hyperscalers, one week, three and a half billion dollars — pointed not at models, not at data centers, but at other people's integration problems.
I can't verify how Microsoft's number is allocated, or how many of the 6,000 are net-new versus reassigned. Doesn't matter much. The strategic read is unambiguous, and it confirms what everyone doing this work already knows from the inside: enterprise AI adoption is constrained by integration, not by model access. Everyone has the models. Almost nobody has the deployment.
Why the constraint moved
The stall pattern is remarkably consistent across enterprises, and it has nothing to do with capability. A client has model access, budget, executive sponsorship, a signed platform agreement — and progress dies in the same four places every time. Identity: whose permissions does the agent exercise, and who signs off on that answer? Process redesign: the workflow the AI is supposed to improve turns out to be undocumented, contested, or three workflows wearing one name. Data ownership: the knowledge the agent needs is split across systems owned by people with no incentive to share it. Production integration: the pilot that worked in a sandbox meets change control, audit, and the on-call rota.
None of those yield to a better model. All of them yield to competent people embedded long enough to learn the org — which is precisely what the hyperscalers just financed at industrial scale.
Services as distribution, not labor
The accounting view of what Microsoft announced is a services business: billable people, margins thinner than software, analysts sigh. That view misses the design. Forward-deployed engineering at platform scale is three other things wearing a services badge.
Distribution. Every embedded engineer resolves blockers toward their platform. The identity question gets answered with the vendor's identity stack; the integration gets built on the vendor's primitives. The deployment labor is the sales motion — the tap system installed free, plumbed to one brewery's kegs.
Feedback. Six thousand engineers inside real enterprises constitute the largest product-research operation in the industry. Every stalled rollout, every missing permission model, every integration workaround flows home as roadmap. The platform gets better at exactly the seams where deployments die — an advantage compounding invisibly, deal after deal.
Expansion. An embedded team sees the adjacent workflow, the next department, the unbudgeted problem. Land-and-expand with engineers instead of account managers, and with far better information.
rendering diagram…
That is a flywheel, and $2.5 billion is what it costs to spin one at hyperscaler scale.
The question this asks of everyone else
At work, this lands close to home — deploying AI inside enterprises is the business I am in, so read this section as a competitor thinking out loud rather than a neutral observer. The uncomfortable question the hyperscaler move forces on every independent consultancy and services firm: does your delivery telemetry compound?
The hyperscalers' embedded engineers make their platform better with every engagement. The default consultancy model makes individual people better with every engagement — knowledge that walks out the door with attrition and never accrues to anything reusable. If your hundredth deployment is only marginally cheaper and better than your tenth, you are selling labor against competitors who are selling a compounding asset and pricing the labor at zero when it suits them.
The counter-move exists, but it has to be deliberate: treat every engagement as an instrument. Harvest the recurring blockers into playbooks with names. Turn the identity patterns, the process-mapping templates, the integration scaffolds into artifacts that make engagement N+1 structurally faster. Build the eval harnesses and deployment checklists as products, not project files. Independence remains a real advantage — clients know embedded vendor engineers resolve every fork toward the vendor, and a firm that optimizes for the client's stack has a trust position no hyperscaler can occupy. But independence plus non-compounding delivery is a shrinking niche. Independence plus a compounding playbook is a business.
Steal this
If you buy deployment services: use the hyperscaler math as leverage — integration help is now a competitive giveaway, so stop paying rack rates for commodity embedding, and reserve paid engagements for genuinely independent advice, which just became more valuable precisely because so much "free" help now arrives with a platform attached. Ask any embedded team, vendor or independent, one question up front: when you leave, what stays?
If you sell deployment services: audit your last ten engagements for artifacts that survived the engagement. If the honest answer is "the invoices", the hyperscalers just told you what your future margin looks like. Start compounding or start specializing.
The hyperscalers just priced the real bottleneck at $3.5 billion — integration is the product now, and everyone deploying AI is either building a flywheel or feeding someone else's.
