Microsoft just put $2.5 billion behind forward-deployed engineers. Here’s why the FDE approach creates a risk for you — and the approach we take instead.

Context

Last week Microsoft announced the Microsoft Frontier Company — a $2.5 billion venture that will place roughly 6,000 engineers, industry experts, and consultants directly inside customer companies to design, deploy, and run their AI systems. It came two days after AWS committed $1 billion to a similar effort, and a few weeks after OpenAI and Anthropic each launched their own deployment ventures with billions of dollars in outside investment. Notably, Microsoft's Judson Althoff, who leads its commercial business, went out of his way to say the effort "goes beyond what has been labeled as Forward Deployed Engineering." The term has become so popular that even the companies that defined it are already distancing themselves from the name.

If you lead a company trying to get real value from AI, this looks like a gift: a software vendor will send excellent engineers to sit with your teams and make the technology work. That appeal is real, and we want to be clear up front — this staffing model solves a genuine problem, and the engineers doing the work are highly capable. This is not a piece about anyone being wrong. It is a piece about the order in which you make decisions, and about who is left holding the useful knowledge once the project ends.

Why this approach is winning

The approach has earned its moment. A state-of-the-art AI model, reached through an API, is enormously capable on its own and yet nearly useless on the first day inside a real company: the model can't connect to decades-old internal systems, it has to satisfy login-security and data-location rules, the workflows it is meant to support are only half-documented, and there is a wide gap between a polished demo and a system reliable enough for daily production use. Palantir showed a decade ago that the way to cross that gap is to put strong engineers physically inside the customer's operation. The current run of announcements is that same lesson — now scaled up, funded, and applied to AI.

So the appeal isn't in doubt, and the capability is real. The question worth asking is narrower and more useful: when the team running your AI project works for the company that also sells you the software, whose problem gets solved first — the problem you hired them to solve, or the vendor's need to prove its own product is the answer?

The one question the sales pitch doesn't answer

Good technology decisions run in a specific order. You start by defining the job to be done and the requirements it carries — the result you actually need, how accurate it has to be, what it can cost to run, and how it will be maintained and supported. Then you look across the market for the tools that best meet those requirements, weighing price, the cost and difficulty of switching later, and how dependent each choice would make you on a single vendor. The specific product comes last, because a product is a means to the result, not the place to start.

A vendor's on-site team, however talented, tends to run that order in reverse. They arrive knowing one product deeply, with a job description that is to make that product succeed inside your company. That isn't a character flaw in the engineers; it is simply the assignment they were given. Ask any capable professional to find the best uses for one specific product line, and they will find them. The uses they are less likely to raise are the ones a different company's product would serve better.

In a field moving this fast, that matters more than it used to. Which provider has the most capable AI model now changes over months rather than years, as each company overtakes the others with every new release. Committing your build to one company's engineers also commits you to that one company's direction. A partner who is independent of every vendor can steer you toward whatever is genuinely best next quarter; a partner whose paycheck depends on a single vendor's software has a harder time telling you to switch.

The incentives behind the offer

Microsoft described its venture, memorably, as AI engineering that "amplifies and protects your intelligence." We take that phrase at its word and turn it into the question we put to every leadership team we work with: across a project that runs for years, who gradually learns how your business actually works — the undocumented details, not the org chart — and who still has that knowledge once the project is over?

These deployment teams belong to companies whose revenue rises the more you use their AI — usage billed by the "token," the unit these models are metered in. Several of them are working hard to be seen as even-handed; Microsoft notes, fairly, that its teams support many different AI models, not only its own, and connect to open systems — and we take that at face value. But good intentions and business structure are two different things. Promising to be paid on results narrows the gap; it does not remove the basic fact that the company advising you on how to build your system also earns more the more of its own software you build into that system. And the most valuable, longest-lasting thing a deployment produces isn't the software code. It is the detailed understanding of how your organization creates value — the actual workflows, the awkward exceptions, and the judgment calls your people make. That understanding is exactly what you should think twice about handing over, in full, to a single software vendor.

This isn't about assuming bad faith from anyone. It only asks you to notice that incentives work like gravity: they quietly pull even excellent work toward whatever the vendor's business model rewards.

The economics: rent the capability, or build one you own

There's a cost argument here too, and it's worth stating plainly. This vendor-team model is designed for large deployments and priced accordingly: a sizable team working inside your company, plus fees that keep climbing the more you use the vendor's AI. For the kind of work it is built for, that can be money well spent. But it helps to be clear about what you are actually buying — you are renting a capability, not building one. When the project winds down, the team leaves, and most of what they learned about how your business runs leaves with them. You keep paying the ongoing fees, but your own people are no better able to run AI than they were before.

A leaner approach is the better choice for many teams, for reasons beyond the invoice. Instead of keeping a large outside team on-site indefinitely, you bring in senior experts who are independent of any vendor, only for as much of their time as you actually need — often part-time — and you point them at the handful of uses where the value is concentrated. Alongside that, you follow a clear method for building your own in-house AI team, sometimes called a center of excellence. The partner's role is to shrink over time: set up how the AI work is run day to day, how you test whether an AI system actually performs, and how you choose tools without bias — and then hand control to your own team.

Independence has a cost advantage of its own. An advisor who earns nothing from how much AI you use is free to put a task on a smaller or cheaper model whenever that model is good enough — choosing the option that lowers your bill rather than the one that raises it. Over time you convert a large, ongoing vendor bill into in-house expertise that grows more valuable the longer your team holds it, and you keep the freedom to pick the best tool for each job as the market keeps changing.

The approach we take with our clients

The alternative isn't to handle AI entirely on your own, and it isn't to distrust the big vendors. It is to keep your overall strategy independent of any single vendor, and to let the products compete, on their merits, for each job. In our engagements it runs as four phases, structured as a build-operate-transfer arc — we build the capability, run it, and then hand it to your team — so that across the phases, ownership moves steadily to you.

Phase 1 — Establish ownership. It starts with clear, vendor-neutral ownership of AI: one internal leader, a small in-house team, or a partner paid for your results rather than for getting you to adopt one company's software. We anchor that ownership to a real business function — marketing is often a strong first step — so the work stays focused on producing value, not on staging an impressive demo.

Phase 2 — Map the value. We map how your business actually works today, and where the money and the costs are concentrated. The leading AI vendors use disciplined methods to find exactly these high-value spots; we apply the same discipline, without a stake in which product wins.

Phase 3 — Match and prove. We match each need to the tool that fits it best and take the quick, affordable wins first. For each task we weigh accuracy, how it is supported and maintained, the full cost, and how hard it would be to leave later. Some needs point to Microsoft, some to a competitor, and some to a small specialist — and being free to say so is the whole point.

Phase 4 — Build to own. We invest the most in the areas that are specific to your business. The detailed knowledge of how your business runs stays inside your own team, with targeted outside help around it — rather than the whole picture handed to one vendor. By the end, your team owns the capability, and our role has faded.

The irony is that this is roughly the same method the vendor deployment teams themselves use to decide where AI creates value. The difference is who is holding it. Run by a software company, the method tends to point toward that company's products. Run by a partner with no product to sell — the way we run it — it points wherever the value actually is.

What we tell the leadership teams we work with

This wave of announcements is a strong signal that the hard part of AI has shifted — from building the models to getting them working inside real organizations — and on that point we agree completely. Where we differ from the popular move is on who should own that last step. Our position is firm: the engineer sitting inside your business should be paid for your results and free of any single vendor, not sent in by the company that is also trying to sell you its software. That is the model we run.

At cxontology, this is the work we do across our three areas of focus — digital experience engineering, go-to-market, and AI and agentic activation. We help teams reach real, working AI results with an approach that starts from the problem rather than a product and stays independent of any single vendor, delivered by a small, named team that builds up lasting knowledge of how you operate. The AI platforms are improving every quarter, which is genuinely good news — and the best way to benefit is to stay free to choose among them.

If you're planning the order of your AI projects and want a partner who has no product to sell, reach out — we'll walk you through it against your specific plans.