Every headline about the Tomoro acquisition used the word "consultancy."
That word is wrong. Not technically wrong. Tomoro did consulting work. But wrong in the way that calling Palantir a "data analytics firm" is wrong. Technically accurate, completely misses the point.
The word that matters is Forward Deployed Engineer.
Palantir built one of the most defensible enterprise businesses in the history of software with a single structural decision: stop selling software licenses, start embedding engineers inside client organisations. Not to install software. To redesign work from the inside, until the switching cost stopped being a contract and became the institutional memory of your own team.
On 11 May 2026, OpenAI launched its Deployment Company and agreed to acquire Tomoro. I think this is the smartest enterprise move OpenAI has made. Here is why.
Table of Contents#
- The Palantir playbook, explained in three sentences
- What Tomoro actually is
- The mapping
- Why this is brilliant
- What it means for everyone else
- FAQ
The Palantir playbook, explained in three sentences#
Palantir sends engineers to live inside your organisation. Those engineers do not install software. They diagnose your workflows, rebuild them around Palantir's platform, and train your people to operate the new system. By the time the engagement matures, the Palantir engineers know more about how your organisation actually works than most of your own senior staff.
That is the playbook. Three sentences. It sounds simple. It is extraordinarily difficult to operationalise and nearly impossible to compete with once it has been running for eighteen months inside a customer.
The switching cost is not what it costs to cancel a software contract. It is what it costs to rebuild the institutional knowledge that walked out the door with the Palantir team, retrain your people on a new system, and redo the workflow redesign work from scratch. Most enterprises never pay that cost. They renew instead.
Palantir has used this model to build a business with gross margins that have consistently run above 80% and a client retention profile that most SaaS companies would trade their entire product roadmap for. The embedded engineer is not a services cost. It is a moat.
What made the FDSE model financially viable rather than a loss-leader is that it scaled with revenue. Palantir grew FDSE headcount in proportion to contract value, which meant the service cost tracked the revenue it generated. The embedded engineers were not a subsidy for software sales. They were the product that justified the contract size.
That is the structural detail that most commentary on the acquisition misses. OpenAI is not buying a consulting arm to offset model revenue with billable hours. It is buying a delivery model where the engineers and the platform are inseparable. The engagement only works if the platform does. The platform only sticks if the engineers make it work. When that loop closes inside a customer, it is extremely difficult to unwind.
What Tomoro actually is#
Tomoro was incorporated in the UK in October 2023, "born in alliance with OpenAI," as its own materials put it. By the time OpenAI agreed to acquire it, it had around 150 people and had grown monthly global revenue more than tenfold in the prior year. It had offices in London, Edinburgh, Manchester and Singapore.
What it was not: a consulting firm with a slide deck and a partner who calls you twice a year.
What it was: a four-role operating pod built for one specific purpose, moving enterprise AI from demo to production in weeks rather than years.
The pod has four roles.
The Applied AI Solutions Engineer designs and builds the actual systems: LLM-based agents, retrieval pipelines, tool-calling architectures, agentic workflows. They work in small mixed teams with client engineers. They own the build.
The AI Delivery Lead connects Tomoro's engineers to the customer organisation. They own multiple accounts simultaneously, steward the project timeline, and translate between what the AI system can do and what the business actually needs.
The AI Experience Designer shapes what the system feels like to use, not just aesthetically, but in terms of trust. For a brand-sensitive deployment like Virgin Atlantic's customer concierge, this is not a nice-to-have. It is what makes the difference between a system customers interact with and one they ignore.
The AI Adoption Specialist is the role most traditional consultancies forget entirely. Their job is to make usage stick. They redesign workflows, run enablement programmes, and embed with client teams until AI is part of how the org actually operates, not just a tool that exists on the intranet.
The pod's public commitment: custom solutions typically in production in less than twelve weeks. Strategic roadmap work starts in as little as two weeks. Tomoro's published case study has the numbers.
The mapping#
Here is what makes the Tomoro acquisition click once you see it.
Palantir FDSE to Tomoro FDE. The title changed. The function is identical: a cross-functional team embedded inside a client organisation, owned end-to-end by the vendor, with a mandate to make the platform work in real workflows rather than just in demos.
Palantir Gotham to OpenAI's Stateful Runtime and Codex. Palantir built Gotham as the platform its FDSEs configured and deployed inside clients. OpenAI is building its own enterprise runtime layer, a Stateful Runtime Environment that lets agents keep context, remember prior work, and operate across tools and data. Codex is the coding agent surface. Tomoro's engineers already spoke this language. They built on OpenAI models, evaluated OpenAI safeguard models before release, and described MCP, Claude Code, and Codex as standard tools in their adoption specialist role. The acquisition captures a team that was already fluent in OpenAI's platform roadmap.
Early government contracts to Tesco, Virgin Atlantic, Supercell. Palantir's early credibility came from deploying inside clients where the stakes were high enough to make the embedded model feel justified: intelligence agencies, defence departments, institutional finance. Tomoro's early credibility came from retail (Tesco's colleague AI assistant, embedded in the Tesco app), travel (Virgin Atlantic's multimodal concierge, built in partnership with Tomoro, covering flight planning, holiday queries, and Flying Club via voice, image, and text), and gaming at scale (Supercell's in-game support agent handling 40,000 tickets per day at peak, with a 90% reduction in ticket handling cost and 20% CSAT increase).
These are not pilot programmes. They are production systems with disclosed operational metrics.
Diagnostic to deploy cadence: identical. OpenAI's own description of how Deployment Company engagements work mirrors Tomoro's playbook almost word for word: start with a focused diagnostic to identify where AI creates most value, select a small set of priority workflows, then work inside the organisation to design, build, test and deploy production systems. Tomoro said the same thing on its services page. OpenAI did not invent this methodology. It acquired it.
Why this is brilliant#
OpenAI said in April 2026 that enterprise accounts for more than 40% of its revenue, that over one million businesses use its products and APIs, and that the next constraint is no longer model capability alone but deployment into messy real workflows. That framing is unusually honest for a frontier lab. It is also the setup for why the Tomoro acquisition makes complete sense.
The capability overhang is real. Most enterprises are not limited by what AI can do. They are limited by their ability to connect AI to the workflows, data, permissions, and people that make those capabilities useful. The gap between what a frontier model can do in a demo and what it can do reliably inside a real enterprise system is not primarily a technical problem. It is a people, workflow, and change management problem. Tomoro was built specifically to close that gap. The acquisition puts that capability inside OpenAI.
Workflow-level lock-in beats model-level lock-in. If an enterprise switches from OpenAI to Anthropic at the model layer, that is a painful API migration. If an enterprise switches from OpenAI's Deployment Company after eighteen months of embedded FDE work, workflow redesigns, custom evaluation suites, adoption programmes, institutional knowledge now living partly inside Tomoro's delivery leads, the switching cost is an entirely different order of magnitude. OpenAI is not just selling access to GPT-5. It is embedding people who know how your business actually works.
The feedback loop is the hidden prize. OpenAI says the Deployment Company will remain closely connected to research, product, and in-house deployment teams. FDEs who are embedded inside real enterprise workflows will see failure modes that no API log captures: where the model hallucinates in a domain-specific context, where the retrieval pipeline breaks on a particular document type, where the permissions model creates edge cases that the product team never anticipated. That is better product telemetry than any beta programme, because the FDEs are paid to make the system work, not just to report that it failed.
I wrote earlier this year about the harness layer commoditising and why the workflow is where enterprise AI differentiation actually lives. See Your Agent Moat Was Never the Orchestrator and OpenAI's Harness Engineering Explained. The Tomoro acquisition is OpenAI acting on exactly that logic, one level up. The moat is not the model, and it is not the harness either. It is the workflow knowledge the embedded team accumulates over time.
What it means for everyone else#
For enterprises considering a Deployment Company engagement: You are getting something real. A team structured around delivery, design, and adoption, not just engineering, that is committed to production in weeks rather than quarters. The Tesco, Virgin Atlantic, and Supercell work is evidence of what that looks like in practice. The thing to price in is the dependency. Not a hostile dependency, not a trap in the malicious sense, but a structural one. After eighteen months of embedded FDE work, the people who understand your AI workflows most deeply may be OpenAI's. Plan for knowledge transfer from the beginning, not as an afterthought.
For Accenture, McKinsey, BCG, and the systems integrators: You have alliances with OpenAI. Your names are on the Deployment Company's investor and partner list. That is not the same as being the embedded team. The Palantir playbook works because the embedded engineers are yours, their career, their institutional knowledge, their relationship with the client. A partner arrangement where the FDEs are nominally "co-delivering" with your team is not the same thing. OpenAI knows this. The channel conflict question, which work stays with external partners and which gets pulled into DeployCo's own teams, is real and not yet publicly answered.
For Anthropic and other frontier labs: Reuters reported in May 2026 that Anthropic is pursuing a similar PE-backed structure to acquire services businesses and bring engineers closer to customers. The Palantir playbook only works if you move first and embed deep. At most enterprise clients, there is room for one embedded AI team in any given workflow. Second movers are consultants. The window is not closed, but it is closing. See also Building Multi-Agent Systems for Production for context on where the technical complexity actually lives in these deployments.
For anyone building AI services businesses: The Palantir model has now been validated twice, once in data and defence, once in frontier AI. That is the clearest signal yet that the most defensible position in enterprise AI is not a SaaS product and not a model. It is a team of people who know how to make AI work inside real organisations, delivered as a service by the same company that controls the underlying model. If you are building in this space, your differentiation cannot be "we also embed engineers." It has to be a niche, a vertical, a workflow category, or a vendor relationship that OpenAI cannot absorb without creating a conflict it does not want.
FAQ#
Is this a good deal for enterprises signing up with OpenAI's Deployment Company?
Yes, with one caveat. The operating model, engineer plus delivery lead plus designer plus adoption specialist, targeting production in under twelve weeks, is genuinely differentiated from what most large consultancies deliver. The case studies are real. The caveat is dependency: the more embedded the team becomes, the higher the switching cost. That is not a reason to avoid the engagement. It is a reason to be deliberate about knowledge transfer and documentation from day one.
What does this mean for system integrators like Accenture and McKinsey?
They are on the Deployment Company's partner and investor list, which creates a channel arrangement. But a channel arrangement is not the same as owning the embedded team. The work that flows to external partners versus the work that flows to DeployCo's own teams is the open question. Historically in the Palantir model, the most strategically valuable client relationships eventually consolidated under Palantir's own FDSEs rather than under the partner.
Will Tomoro's culture survive inside OpenAI?
This is the largest execution risk. Tomoro described itself as "flat on purpose" with small expert teams. That culture produced the delivery cadence and client trust that made the acquisition attractive. Once inside a much larger organisation, retention of senior builders and preservation of that delivery culture is not guaranteed. The people concentration risk is real: the public value of Tomoro is almost entirely in the people and their methods, not in a proprietary software platform.
Is Anthropic doing the same thing?
Reuters reported in May 2026 that Anthropic is pursuing a similar PE-backed structure to acquire services businesses and embed engineers closer to customers. The broad shape of the strategy is the same. The execution is earlier-stage than OpenAI's already-announced and staffed Deployment Company. Competition at the deployment layer between frontier labs will intensify.
What is the difference between an FDE engagement and a traditional consultancy engagement?
A traditional consultancy engagement typically produces a strategy document, a technology recommendation, and a proof-of-concept. An FDE engagement produces a production system. Tomoro's public commitment, less than twelve weeks to production, is the operational expression of that difference. The FDE team does not hand off to your internal engineering team. It works inside your engineering team until the system is live and the adoption has happened.
Does this make OpenAI's model pricing more or less important?
Less important over time, for the clients DeployCo works with. When the switching cost is embedded institutional knowledge rather than a per-token price differential, customers stop optimising primarily on price. This is exactly the dynamic Palantir engineered in its own market. It does not mean model pricing is irrelevant. It means that for DeployCo clients, the pricing conversation shifts toward the total engagement cost, and OpenAI's model pricing becomes one line item among several rather than the primary buying decision.
The race to own enterprise AI is not about which model wins.
It is about whose engineers are already inside the building.