Forward-Deployed Engineers: The Missing Piece of AI Adoption

A forward-deployed engineer is a software builder who works inside your company — in your meetings, your data, your tools — and ships AI that runs in your real workflows instead of a demo environment. It's the model behind Microsoft Frontier Company, the unit Microsoft launched in July 2026 with a $2.5 billion commitment and 6,000 engineers placed directly inside enterprise customers, and it's how Palantir and OpenAI have run their enterprise motions for years. Here's the part that matters if you're not an enterprise: you don't need 6,000 engineers. You need one embedded builder, a few days a week, pointed at one workflow.

Why the biggest AI companies send people, not licenses

Palantir built its business on forward-deployed engineers before the term was fashionable. OpenAI staffs them on its largest accounts. And on July 2, 2026, Microsoft made the biggest bet yet on the same embedded principle, officially launching Microsoft Frontier Company — a $2.5 billion, 6,000-person unit led by Rodrigo Kede Lima whose job is to sit inside enterprise customers and make AI actually work there (TechCrunch has the details). Microsoft is careful to frame the unit as going beyond forward-deployed engineering as the industry has practiced it, but the core wager is the same one. Three companies with every incentive to sell software at pure margin keep choosing to sell software plus a human who installs it into the customer's reality.

They're not doing this out of generosity. They're doing it because enterprise AI adoption keeps failing at the same spot: the last mile between a capable model and a messy, specific, undocumented workflow. The model can draft the contract summary. It cannot know that legal wants exceptions flagged in a particular format, that the source documents live in three systems, or that one person in ops is the only one who knows which contracts are actually active. A license doesn't close that gap. A builder sitting next to that person does.

What a forward-deployed engineer actually does

Strip the title away and the job is simple to describe: ship production software while sitting inside the customer's context instead of the vendor's.

The day-to-day

A typical week for an embedded AI engineer looks nothing like consulting and nothing like product engineering:

• They attend your operational meetings, not vendor check-ins. The goal is to watch how work actually happens — including the parts nobody thinks to mention, like the spreadsheet that gets exported from the CRM every Monday and re-keyed into billing.
• They pick targets by pain, not ambition. The best FDEs hunt for high-frequency, low-glamour steps: intake triage, quote assembly, report generation, first-draft support replies.
• They ship thin. A working integration against real data by Thursday beats an architecture diagram by month two. Prompts, small evals, one connector, one user.
• They watch usage and iterate in days. If the ops team routes around the tool, that's data — and it gets fixed the same week, not logged as a change request.

The feedback loop is the whole product

This is the mechanism that makes the model work. A software vendor's feedback loop runs in quarters. Traditional consulting's loop runs report, recommendation, handoff, then someone else implements while the findings drift. An embedded builder's loop runs in hours: watch the failure, fix it, watch again. Everything else about the role — the desk inside your office or your Slack, the standing invite to your meetings — exists to shorten that loop.

Why embedded beats buying tools

If you've spent a couple of years buying AI tools, you likely recognize the shape of the problem: a stack of subscriptions, none of them wrong exactly, most of them underused — because tools solve generic problems and your margin lives in specific ones. The generic 80% of a workflow was never the expensive part; the specific 20% — your data shape, your approval chain, your edge cases — is where the hours go, and no off-the-shelf product ships knowing it. We've made the full version of this argument in The AI Last Mile: Why Buying Tools Isn't Adopting Them, so we won't re-argue it here. The point for this article is that an embedded builder starts exactly where the tools stop: inside the specific 20%.

Why traditional consulting doesn't fix it either

Consulting attacks the specificity problem but with the wrong deliverable. The output is a document, the incentive is billable discovery, and implementation is someone else's job. We've watched companies pay for AI roadmaps that were directionally right and still changed nothing, because a roadmap can't answer the question that decides adoption: does the thing work on Tuesday when the real data shows up?

The forward-deployed model inverts both. The deliverable is running software. The incentive is adoption, because an embedded engineer who ships things nobody uses gets found out in weeks, not at contract renewal.

The honest trade-offs

The model isn't free of downsides, and pretending otherwise is how bad engagements get sold. Embedded engineering is expensive per hour compared to a license. It carries key-person risk: the engineer accumulates context that walks out the door unless you force documentation as part of the engagement. And it demands real access — sandboxed data, system credentials, a seat in meetings. Companies that can't grant that access shouldn't start; the engagement will stall on permissions and everyone will conclude AI doesn't work.

The fractional FDE playbook

Microsoft can fund thousands of full-time embedded engineers. A 30-person agency or a mid-size services firm cannot — and doesn't need to. The same model works at one to three days a week, because the constraint was never headcount. It was context and loop speed, and a fractional engineer who is genuinely embedded on their days in has both.

Step 1: pick one workflow, not an AI strategy

Choose the first target by the filters we lay out in AI Won't Fix a Broken Process: Audit Your Workflow First: high frequency, real manual cost, and low stakes if the first version is imperfect. Intake triage and internal report assembly usually qualify. Anything customer-facing or compliance-adjacent usually doesn't. Start where failure is cheap.

Step 2: structure the engagement around shipped software

Put three things in writing before day one. First, a weekly demo of working software in your stack — not slides, not findings. Second, access delivered on day one: sandbox data, tool accounts, and a named internal owner who spends real hours with the engineer. Third, a hard milestone: the first automation live with real users inside 30 days. Any prospective partner who resists these terms in favor of a discovery phase is selling you consulting with a newer label.

Step 3: measure adoption, not activity

Track whether the people who own the workflow actually use what shipped, and what it saves them. Demos, commits, and meetings are activity; usage is the metric. If nobody touches the tool by week six, kill it without ceremony and point the engineer at the next workflow. The cheap kill is a feature of this model — you learn in six weeks what a tool purchase would have hidden for a year in unused seats.

What to look for when you hire one

Good signs: a portfolio of shipped internal tools rather than platforms, questions about your data before questions about your budget, visible comfort with ambiguity, and willingness to sit in your operational meetings. Red flags: leading with a proprietary framework, proposing a long discovery phase, or being unable to commit to a weekly demo. Plenty of firms selling AI help to smaller companies are the second kind, which is exactly why the embedded model is worth insisting on.

Mistakes we see

1. Treating the engineer as staff augmentation. If they get absorbed into your existing sprint backlog, you've hired a contractor, not an FDE. Protect their mandate: workflows, not tickets.
2. No internal owner. Embedded means embedded with someone. An engineer nobody makes time for produces demos, not adoption.
3. Starting with the hardest problem to prove value. The flagship workflow is where trust goes to die. Earn the right to touch it with two small wins first.
4. Buying tools first, then asking the engineer to justify them. Sequence it the other way: let the workflow pick the tools.

Where to start

If you're weighing this against another round of licenses, run a cheap test first: list the three workflows your team complains about most, estimate the weekly hours each one burns, and ask what a builder sitting inside that workflow could ship in 30 days. That one-page exercise tells you more than a quarter of tool trials. And if you want a second set of eyes on the list — or FDE-style embedded engineering without the enterprise price tag — that's exactly the work we do at Startupp.