Not subscribed? Sign up to get it in your inbox every week.

Microsoft just spent $2.5 billion on a job title.

On July 2 it launched Microsoft Frontier Company, a 6,000-person organization whose only job is making AI work inside customer companies. Two days earlier, AWS committed $1 billion to the same idea and said it would seed the unit with thousands of forward deployed engineers. OpenAI and Anthropic are hiring for the role right now, and postings for it grew more than 1,000% last year.

So before the next AI contract crosses your desk, here is the sentence worth holding onto: a solutions engineer owns the adoption of their company's product, and a forward deployed engineer owns your outcome. The entire AI industry just bet billions on that difference.

The title comes from Palantir.

Palantir's early customers were intelligence agencies, which meant they had a problem no product team had faced: they legally could not describe their own work. No discovery calls, no requirements docs, no user interviews. So Palantir did the only thing left and moved engineers into the customer's building, where they could watch the real work and build whatever the mission needed, in place, on live data. The company's own shorthand for the split is still the cleanest definition around: a product engineer builds one capability for many customers, while a forward deployed engineer builds many capabilities for one customer.

Wall Street hated it. The standard knock on Palantir for a decade was that it was a consulting shop wearing a software costume, with margins to match, and the fact that Palantir at one point reportedly employed more forward deployed engineers than product engineers read as proof. The grading rubric was the SaaS playbook, where the product is finished and the job is distribution.

Then AI arrived and quietly turned every enterprise buyer into an intelligence agency. Nobody can spec what they need. The requirements change monthly. The value hides somewhere inside the actual workflow, discoverable only from the inside. This summer Microsoft, Amazon, OpenAI, and Anthropic all invested insane amounts of money to copy this playbook.

From a distance the two roles blur: technical people, customer-facing, living in other companies' stacks. Up close they are opposites, and the axis is ownership.

A solutions engineer owns adoption. The mission is getting your team to use their product as well as it can be used for the solution you bought. They run the demo, build the proof of concept, sketch the integration on the whiteboard, and hand off to implementation once the deal closes. Success is your team using the product the way it was designed to be used, and for most mature software that is exactly the right thing to own, because the product already does a known thing and using it well is the outcome. A CRM your reps actually update is a CRM that is working.

A forward deployed engineer owns the outcome. The mission is the result you bought the software for: fraud caught, tickets resolved, claims processed, pipeline routed. Their product is one input; your data, your legacy systems, your permissions, and a pile of glue code are the others. The FDE writes production code inside your environment, stays through go-live, and picks up the phone when it breaks in week six.

You can see the ownership split in the plumbing of the two jobs. The labor-analytics site Bloomberry analyzed a thousand forward deployed engineer postings last fall; roughly a fifth of FDEs turned out to be former solutions engineers, so these are often literally the same people. Yet the roles are built differently. SE compensation hangs off deals closing, while exactly zero of the thousand FDE postings carried a quota. One sits in the sales org and is measured on the deal; the other sits in engineering and is measured on whether the thing works. Comp plans are strategy in miniature: companies pay for what they want owned.

The sharpest test is what happens when the product can't do the thing you need. The solutions engineer's honest moves are a workaround, a roadmap promise, or a polite note that it's out of scope, because their job ends at the edge of the product. The forward deployed engineer's move is to build it. At Palantir, whatever kept getting built across customers hardened into product for everyone (insiders called it turning gravel roads into paved highways), which means the custom work doubled as product discovery. The edge of the product is exactly where the FDE's job begins.

I watched this split from the vendor side at Copy.ai. The demo was the easy part of an enterprise deal; models are charming on stage. The hard months started after the signature, when the buyer's real workflow met our product's assumptions, and what happened in that gap decided whether the logo renewed. The deals that worked had somebody acting like an FDE before I knew the term. The deals that struggled had a beautifully executed handoff into nobody.

For twenty years of SaaS you could ignore all of this, because adoption and outcome sat close enough together to be the same thing. Software did a defined job, and a team that adopted it got the job done. Pricing, org charts, and the solutions engineer role itself were all built on that closeness.

AI pulled the two apart. You can adopt an AI product beautifully (seats provisioned, workshops attended, dashboards green) and get nothing, because the distance between "the model works" and "our workflow works" is where the value actually lives. IDC puts the share of AI pilots that never reach production at 88%. Those pilots die in the gap between adoption and outcome, and an adoption-owner, by design, stops at the near edge of that gap.

The $3.5 billion Microsoft and AWS just committed is those companies concluding that outcomes need an owner with a keyboard inside the customer, and that eating deployment costs up front is worth it because a workflow that actually works becomes consumption that compounds for years. They are trading services margin today for usage they can bill against tomorrow. The risk they inherit is the one Palantir carried for a decade: a16z's warning to the copycats is that without a strong product spine, the model collapses into "Accenture for X with a nicer front-end." That one is the vendor's problem. Yours is making sure the ownership lands on your deal.

Ask every AI vendor one question before you sign: after the ink dries, who owns our outcome, and what is that person paid on?

Then listen to the shape of the answer. You are hoping to hear about a named engineer who will write code in your environment, stay through go-live, and carry no quota. You will often hear instead about an adoption journey, a customer success manager, and a training portal. Both are useful answers, as long as you get them before signing. A vendor who fields real FDEs needs your deployment to work almost as badly as you do, which is the most alignment you will ever get in a software deal; negotiate the embed into the contract instead of accepting it as a perk.

Then ask the same question about your own org chart, because the distinction applies internally too. The most common first AI hire is an internal solutions engineer in spirit: an enablement lead who runs lunch-and-learns, curates the prompt library, and owns adoption of the tools. In a board deck, tool adoption is the metric that looks best while the pilots quietly die. The hire that works is an internal FDE: one technical operator embedded in one function (claims, support, sales ops, whichever is ugliest), owning one outcome metric, building whatever glue the outcome needs, and feeding what works into a playbook the next function can reuse. A fifth of the industry's FDEs converted over from solutions engineering, so the path exists; your best ops analyst who writes Python is halfway there already.

The forward deployed engineer is a bet, priced in billions, that AI outcomes have to be somebody's actual job. The bet extends to your side of the table. Every contract you sign and every AI hire you make settles the question, whether or not you ask it out loud.

Who owns the outcome?