AI Facilitators are your Forward Deployed Facilitators
TL;DR
- OpenAI just put $4B behind embedding engineers in client teams.
- AI's real gains come from redesigning whole workflows, not speeding up single tasks. That's people-and-permission work, not engineering.
- You need a Forward Deployed Facilitator beside the engineer — and you're better off building that capability in-house than renting it.
OpenAI just put $4 billion behind a simple idea: stop building AI from a distance.
Their new consulting arm — DeployCo — is staffing up on Forward Deployed Engineers. Instead of shipping software at a client from a remote HQ, the engineer embeds inside the operation. Sits with the team. Learns the real workflow. Builds in context. Bain, McKinsey and Capgemini have all signed on, and OpenAI bought 150 of these engineers from a boutique called Tomoro just to start with talent on day one.
It's one of the better ideas to come out of Silicon Valley in years.
Why OpenAI did this
A few things are happening at once.
Enterprise revenue. API revenue from developers and startups has limits. The big AI budgets sit inside enterprises — and those enterprises don't want a model, they want a working deployed solution. Standard SaaS selling doesn't bridge that gap. DeployCo is a wedge into the transformation budgets historically going to McKinsey, Bain, and Accenture.
The Palantir playbook. Palantir built one of the most valuable enterprise software companies in history on exactly this model — Forward Deployed Engineers embedded inside customer operations. High revenue per customer, deep lock-in, strong margins. The Tomoro acquisition signals OpenAI is explicitly copying the model.
The competitive pressure. Anthropic has been winning the early enterprise wins — Bain partnerships, dedicated enterprise products, serious deployments. OpenAI needed an answer beyond "here's our API."
Demonstrating ROI. Enterprise AI ROI has been hard to prove at scale, which puts OpenAI's growth story at risk every quarter. Embedded engineers make value visible inside the customer's books — and a customer who can point to a working AI system renews and expands. The engineering team is also a real-time filter: they kill fantasy use cases before they consume budget.
So why is this a good idea from Silicon Valley?
It closes the demo-to-deployment gap. Most enterprise AI pilots die between proof-of-concept and production. The gap is rarely the model itself — it's integration, data plumbing, edge cases, legacy constraints, and the unwritten parts of the workflow. An engineer sitting inside the operation closes that gap.
It compresses iteration cycles. Build → test → adjust takes weeks remote. Hours when the engineer is next to the operator. That speed compounds.
It surfaces real problems. Engineers beside the work see what SOPs hide — the workarounds, the exceptions, the legacy system constraints. Information that never makes it into a Slack channel back to HQ.
AI especially needs it. Traditional software is deterministic. AI isn't. It guesses based on context, and the further the engineer sits from the actual work, the worse the guesses get. Embedded engineers are a near-perfect fit for the technology's actual nature.
All of which is real, and well-evidenced. But it won't be enough, and something is missing. That gap will hinder the impact the FDE model proposed by OpenAI (and an increasing number of consultancies) can deliver.
The gap: the task gets faster, the workflow stays the same
We assume that making a task faster makes the workflow faster. It doesn't. A 40% gain on one task does not make the whole process 40% more efficient. The improvement stays local. It never reaches the level that matters — how long the whole thing takes to produce a result, end to end.
Speeding up a task doesn't remove the bottleneck. It moves it.
Take the claims operation of a large insurer. The workflow has several stages: the customer reports the incident, a handler documents it, a specialist identifies the claim parts, the case is reported, investigated and resolved.
The expensive stage is the third. Identifying claim parts means reading messy, free-text notes and working out which parts of the policy a claim touches — across 77 lines of business, each needing specialist knowledge. Handlers catch only about 70% of the parts actually there. The missed 30% is direct financial loss.
The obvious fix: use AI at that stage. AI reads every claim and identifies the parts across all 77 lines. The miss rate drops sharply. On that task alone, AI delivers a massive win.
But overall nothing changes. Identification fed the stages after it — reporting, escalation, investigation, resolution — and those still run at human speed, with the same headcount. Investigators who used to get a trickle of processed claims now face a flood they cannot handle. The bottleneck simply shifted downstream.
The only way to get a real gain is to redesign the whole workflow from the ground up — starting from the business outcome you want, built around what AI can do and what humans can't. End-to-end throughput is the measure that counts.
Why FDEs are not enough
A great engineer takes a defined problem and builds a flawless solution. That's the job, and they're brilliant at it.
What they're not trained to do is ask whether the workflow should exist at all.
Redesigning a workflow for AI isn't an engineering task.
Most enterprise processes were built around human limits that AI doesn't have — one thing at a time, limited memory, ten approvals because no single person could be trusted with the whole picture.
And the process on paper is never the process that runs. The real workflow lives in what no one wrote down — the judgment a senior handler applies without thinking, the workaround someone built years ago, the spreadsheet everyone trusts more than the official system, who actually signs off and who only appears to. It holds together on tacit knowledge, quiet shortcuts, and a tangle of ownership and politics — the things that actually make a workflow work. Automate the documented version and you automate a fiction, faithfully and at scale. You have to surface the real one before you can touch it.
Redesigning around all of that means deciding which steps disappear, which approvals were only ceremony, and what humans should still own once the machine can do the rest.
That's not engineering.
Who could actually do this work?
So what does redesigning the workflow actually take?
It's a people problem before it's a technology one.
It means going to the people who hold the pieces. The handler who knows which parts get missed, and why. The investigator about to inherit the flood. Operations, IT, legal, compliance — each holding part of the picture, none holding all of it. You pull the tacit knowledge out of them, redesign the service across all of them, and win enough buy-in that the new way actually gets used. And you need an executive with the authority to retire the old steps and protect the people who move to the new ones.
A workflow is really a settlement between departments, budgets, and risk owners. You don't re-engineer a settlement. You facilitate one.
Now look at who'd have to do all of that. A researcher, to surface how the work really happens. A service designer, to rebuild it. Part politician, to move the organization. Fluent enough in AI to know what's actually buildable. One person, holding all of it. That person barely exists — and definitely that is not the FDE.
The role you actually need
So you stop looking for the unicorn.
Instead, look for AI Facilitators.
Think of them as Forward Deployed Facilitators — embedded in the real work like the engineer, but working the people and the decision instead of the code.
They get the right cross-functional group in the room, surface how the work actually happens, challenge the rituals, and move the group to a redesign they'll stand behind. They keep the executive sponsor close, because without someone willing to retire the old workflow, nothing ships.
They don't have to be the domain expert, the service designer, and the politician all at once, because their approach plugs in the right expertise when needed. The role is real, the seat exists, and the methods to do the work already exist.
At Design Sprint Academy we have built and battle-tested two of them:
AI Problem Framing is how the cross-functional group identifies the opportunities and the business value at stake.
AI Workflow Sprint is how the group redesigns the workflow. In a few days they map how the work happens today, rebuild the workflow from the outcome backwards, prototype it, and test whether people would actually use it.
The FDE makes the new workflow real.
The FDF (the AI Facilitator) makes sure it's the right one — and that the organization will actually adopt it.
Pair the FDF with the FDE
The two roles belong together. If you're a consulting firm, you send them as a pair: the Forward Deployed Facilitator to surface the right workflow from the people who live it, the Forward Deployed Engineer to build it at the edge of what the models can do. Neither is enough alone.
Without the facilitator, the engineer builds the wrong thing flawlessly. Without the engineer, the redesign never leaves the whiteboard. The facilitator surfaces what to build. The engineer builds it.
The engineer you can rent. The facilitator you should own.
But here's the part the $4 billion misses.
An embedded expert is a person, and people leave when the engagement ends. The redesign freezes the day they walk out — and the work isn't one-and-done. Every time the models take another step forward, the workflow has to be redesigned again. Rent the capability and you're back looking for another unicorn every six months.
The engineer, you can rent. The facilitator, you should own.
Build the facilitators inside your own organization and the capability to redesign workflows never leaves. You run it again every time the technology shifts, without buying a new hero each round.
That's the bet at DSA. We train your people to facilitate the redesigns — AI Problem Framing to choose the right opportunity, the AI Workflow Sprint to rebuild the workflow around it — and we leave behind a method they can run without us. From day one, the goal is to make ourselves unnecessary.
The engineers are worth every penny. They're just half the team. The other half shouldn't be a hire. It should be a muscle you own.
Book a 30-minute call with Design Sprint Academy to walk through what building Forward Deployed Facilitator capability in-house would look like for your organization — and how to pair it with the engineers already shipping the work.
