LLMs Are Playdough. Deployment Builds the House.

A few months ago I got a notification from our Claude admin console: Eugene, our head of recruiting, had burned through his entire $500 monthly token budget. That put him in line with some of our actual software engineers. My first reaction was that I was thrilled -- I want everyone on the team experimenting, pushing the tools, AI-maxxing -- so I raised his budget. My second reaction was to ask what, exactly, he was trying to get done. The answer turned out to be a miniature version of the biggest story in enterprise software right now, and I will come back to it.

First, the big version. On July 2, Microsoft announced a new operating business called Microsoft Frontier Company: $2.5 billion and 6,000 industry and engineering experts whose job is to sit inside customer organizations and make AI deployments work. Two days earlier, AWS committed $1 billion to a dedicated Forward Deployed Engineering organization. In May, OpenAI launched the Deployment Company, a standalone entity backed by more than $4 billion from a TPG-led investor group, and Anthropic stood up an enterprise AI services company with Blackstone, Hellman & Friedman, and Goldman Sachs. In April, Google Cloud and Accenture built a program with the same shape. Five of the biggest names in AI, ten weeks, roughly $9 billion -- all of it spent on the unglamorous work of installation.

That is a strange place for the most advanced technology companies on earth to put their money, and it is the most honest signal the industry has sent in two years. The labs that build the models are telling us, with their capital, that the models alone are not enough.

Here is the way I have started to explain it. A large language model is playdough: the most malleable material ever handed to a business. It can be shaped into a recruiter, an analyst, a translator, a support agent. But malleability is not structure, and nobody lives in a lump of playdough. Between the material and the house there is architecture, engineering, plumbing, inspection -- design decisions the material cannot make about itself. For the past year, most companies have been handing out playdough and expecting houses. Deployment is the function that does the building, and it is being born right now, the way systems integration was born around ERP thirty years ago.

The euphoria, and the number underneath it

The euphoria is real and I do not want to talk anyone out of it. Over the past eighteen months, individual conviction about large language models has become almost religious, and IT departments have finally caught up with their users: nearly every company I talk to has now equipped employees with ChatGPT, Claude, or Microsoft Copilot seats. OpenAI says more than one million businesses have adopted its products. The conventional wisdom that took hold is seductive in its simplicity: the models are so powerful that if you just let your team use tokens, value will appear.

The measured results say otherwise. An MIT-affiliated study of enterprise GenAI programs -- the "GenAI Divide" report -- found that roughly 95% of pilots produced no measurable P&L impact, against an estimated $30 to 40 billion of enterprise investment. (It is a preliminary study of about 300 deployments, not a law of nature, but the direction matches everything else.) BCG's research found 74% of companies struggling to scale AI value in 2024, and by 2025 counted only 5% operating as what it calls future-built value generators. Gartner predicts more than 40% of agentic AI projects will be canceled by the end of 2027, describing most current efforts as, in its words, "early stage experiments or proof of concepts." And underneath all of it sits McKinsey's long-running base rate: fewer than 30% of transformation programs of any kind succeed.

Watching this play out inside our own company and our customers', I see three specific gaps between the seats and the value:

1. Most usage is experimentation. That is healthy -- it is how people learn the material -- but an experiment is not an asset. It ends when the person closes the tab.

2. Most people use AI expensively without knowing it. They ask the model to do a thing, one thing at a time, over and over, instead of building a pipeline that does the thing repeatably and cheaply. The difference is not subtle: engineered patterns like prompt caching and batch processing alone cut API costs by 45 to 80% in a 2026 cross-provider study, and that is before you count redesigning the task itself.

3. Nobody owns the path from prototype to production. A working demo is maybe a tenth of the work. The rest is process mapping, aligning how the workflow runs across a team and then across the organization, connecting the model to systems of record, and deciding what "done" means. In most org charts, that work has no owner.

The shift the deployment wave represents is easiest to see as a change in what is actually being bought:

The result of stopping at column one is the strange steady state most companies are living in: everyone is using AI, everyone believes in AI, and the P&L cannot find it.

Eugene and the $500 token budget

Back to Eugene, with his permission and, frankly, some pride. When we sat down, it turned out he had built something genuinely clever. He was using AI to pull LinkedIn profile data for candidates one at a time, extract each work history, and then re-rank every candidate against all the others for a given role -- every time a new candidate came in. The idea was great. The algorithm was broken. Every new profile triggered a full re-ranking of the entire pool, and every profile was being scraped painstakingly, one by one, by a model pretending to be a browser. Grow the pool from 100 candidates to 1,000 and the cost does not rise tenfold; with the full re-ranking on every arrival, it rises closer to a hundredfold.

So we reworked the process together. The LinkedIn data he was paying a model to scrape profile-by-profile was available from an API that already existed -- one call, structured fields, a fraction of the cost. Each profile needed to be interpreted once, not re-read on every arrival. And the constant re-ranking collapsed into a single batch sort at the end of the aggregation, once, when the pool was complete. Same outcome, a tiny fraction of the tokens, and the model reserved for the part it is actually good at: judgment on ambiguous work histories, not plumbing.

Anyone who has taken an algorithms class will recognize the before-and-after as a complexity problem -- he had accidentally built something quadratic when the task was linear. But that is exactly the point: you cannot expect your head of recruiting to know big-O notation. You also cannot expect him to know which data source has a clean API, which prompt prefix should be cached, when a batch job beats a chat loop, or where the output should land in the recruiting system. Expecting that would be like handing a buyer an ERP sandbox and asking them to reinvent MRP. It is not his job, and it has never been anyone's job on his side of the org chart.

That is the microcosm. Eugene had the material, the motivation, and a genuinely good idea, and he still needed a second set of skills -- data sourcing, pipeline design, cost structure, production ownership -- to turn a clever experiment into a durable system. Multiply him by every enthusiastic operator in every company that just rolled out seats, and you have the entire gap between the euphoria and the 95%. The raw tool without the design work produces heat, not houses. The skill that closes that gap is what the industry has started calling deployment.

Palantir got there fifteen years early

None of this is actually new. Palantir built its whole business on this insight before most of today's AI companies existed. Its Forward Deployed Engineers -- internally nicknamed "Deltas" -- wrote production code inside customer environments, and its Deployment Strategists ("Echos") did the process discovery and stakeholder alignment around them. Palantir's engineering culture drew the distinction crisply: a product developer builds one capability for many customers; a Delta builds many capabilities for one customer. The company reportedly sent about 120 engineers into JPMorgan as early as 2009 to stand up a threat-detection system, and for years -- until around 2016 -- it employed more forward deployed engineers than conventional software engineers. For a decade the market read this as a consulting business wearing a software costume. It turned out to be the operating manual for the AI era.

The proof is in the hiring pages. OpenAI now recruits for the exact title Forward Deployed Engineer -- discovery, scoping, system design, build, production rollout, success measured by "production adoption and measurable workflow impact" -- at $162K to $280K plus equity, with up to 50% travel. One tracker counts 224 open FDE roles across 39 AI companies. IBM, characteristically, answered with a branded variant: Forward Deployed Units, six-person human-plus-agent pods it claims do the work of a thirty-person team, already working with Nestlé, Heineken, and Riyadh Air. When every major vendor converges on a job title Palantir coined, the market is telling you where the bottleneck lives.

And now the function has a capital stack:

Read the vendors' own language and the thesis is explicit. OpenAI says its FDEs will "redesign organizational infrastructure and critical workflows." Microsoft Frontier promises to "co-design, co-innovate, deploy and continuously improve." AWS says embedded engineers compress deployments "from months to days." Google and Accenture put it most plainly: "AI is simple to try and hard to scale." Anthropic's CFO Krishna Rao gave the demand-side version: "Enterprise demand for Claude is significantly outpacing any single delivery model." These are the companies with the best visibility into real enterprise usage on the planet, and they all bought the same answer within ten weeks of each other.

We have run this movie before

If the pattern feels familiar, it should. When enterprise software last went through a platform shift -- ERP in the 1990s, cloud and "digital transformation" in the 2010s -- the licenses were never the expensive part. In the ERP era, software was typically 20 to 40% of total project cost; the rule of thumb was that implementation ran one to three times the first-year software cost, and five-year cost of ownership landed at three to five times the license. That delta is what built the third-party systems-integration industry -- Accenture, Deloitte, IBM Global Services, Capgemini -- a market Grand View Research sizes at $421 billion in 2025, heading toward $1.2 trillion by 2033. The software was the playdough then, too. The integrators built the houses.

The deeper precedent is a century older. The economist Paul David famously studied why electrification took decades to show up in productivity statistics: factories that simply swapped a steam engine for an electric dynamo saw almost nothing, because the entire building had been designed around a central power shaft. The gains arrived only when engineers redesigned the factory itself -- distributed motors, reorganized floor plans, new workflows. The technology was necessary; the redesign was the value. Swapping "steam engine" for "SaaS seat" and "dynamo" for "LLM" costs the sentence nothing. Handing an organization chat seats is installing a dynamo in a steam-era building and waiting.

There is a fair counterargument, and it deserves a real hearing. Maybe deployment is a transitional business: models keep getting easier to use, agent platforms absorb the integration work, and the bespoke engineering gets productized -- Gartner, even while predicting the 40% cancellation rate, expects a third of enterprise software to embed agentic AI by 2028. Vendor-owned deployment arms also carry an obvious conflict: OpenAI's deployment company exists, in part, to pull more usage onto OpenAI's models, and Axios framed the cynical read sharply -- legacy consultancies helping fund their own disintermediation. And the incumbents are not asleep: Accenture is inside Google's program, invested in OpenAI's, and co-launched ServiceNow's. The honest version of the future is probably deployment companies and systems integrators, competing and blurring. But none of that dissolves the function itself. The demo layer gets cheaper every quarter; the production layer still has to cross data permissions, org charts, incentives, exception handling, and cost controls. As the demo gets cheaper, the budget moves toward whoever can make the workflow survive contact with the organization.

What this means if you run a company

The practical takeaway is not "hire a deployment company." For most mid-sized organizations it is to build a small version of the function yourself, and the job description writes itself from the failure modes:

1. Inventory the experiments. Your Eugenes are already building things. Find them, celebrate them, and triage which experiments deserve to become systems. The best first candidates share a profile: high frequency, measurable waste, accessible data, a clear owner, and a sane exception path.

2. Put an engineer next to the operator. Not a ticket queue -- a working session. Every durable AI system I have seen came from pairing someone who owns the process with someone who thinks in pipelines, caching, and batch jobs. That pairing is the entire Palantir insight, miniaturized.

3. Fund pipelines, not prompts. An expensive first pass is fine -- that is how the idea gets proven. The production version should then take the repeated work away from the model: shared context, cached prefixes, batch execution, an eval gate. That is the boring machinery that cuts cost by half or more and, more importantly, makes the output repeatable.

4. Define production. A prototype becomes an asset when it has an owner, an SLA, a cost line, and a place in the org's actual process map. If nobody can say who owns the workflow when its builder goes on vacation, it is still an experiment.

One second-order effect worth watching as this function matures: software pricing. Per-seat pricing weakens when an AI system does work on behalf of a department -- an agent that reads 500 supplier quotes and updates 30 decision records does not map to 30 human seats. Expect more pricing built around workflows, usage, and outcomes, and start asking vendors now how they charge for work done rather than doors opened.

I have written before about the right order of operations for AI adoption -- fluency first, then automation -- and about which jobs AI actually changes; this essay is the organizational chapter of the same argument. My colleague Kieran Bradford has written about what the sales AI boom and bust teaches -- the same euphoria-to-discipline cycle, one function over -- and my colleague Aparna Keswani has mapped where AI delivers stage by stage in sourcing. The through-line in all of it: the value never lives in the seat. It lives in the redesigned workflow.

That is also, candidly, the bet LightSource is built on. Our customers are challenger manufacturers whose sourcing teams do not have forward deployed engineers and should not need them. So the deployment thinking is in the product: agentic AI embedded in the procurement workflow itself -- bids normalized as they arrive, a re-quote that turns an old PDF into live data, cost intelligence surfaced where the decision gets made -- rather than a chat window next to it. Domain software is, in effect, pre-built deployment: someone already did the process mapping for one vertical, so a twelve-person sourcing team gets the house, not the playdough. It is the same reason I have argued make-versus-buy tilts toward professional software once a workflow is mission-critical, and why my colleague Mason Morgan calls the unmanaged alternative the sourcing bottleneck.

Ten weeks and nine billion dollars say the industry has stopped pretending the models deploy themselves. The open question is where the function ultimately lives: in the labs' new deployment companies, in the old integrators wearing new titles, in a product you buy, or in a role you hire two doors down from IT. My guess is all four, sorted by how repeatable the workflow is. What I am sure of is the material analogy. The playdough is genuinely magical, and it is everywhere now. The houses still have to be built, one process map at a time -- and the companies that treat that as a function rather than an afterthought are the ones whose AI spend will eventually show up somewhere more interesting than the expense report.

Sources

• Microsoft -- Microsoft Frontier Company announcement -- $2.5B, 6,000 experts, Rodrigo Kede Lima as president; "co-design, co-innovate, deploy and continuously improve."

• TechCrunch -- Microsoft launches its own AI deployment company -- framing of Microsoft following Amazon, OpenAI, and Anthropic.

• OpenAI -- OpenAI launches the Deployment Company -- >$4B TPG-led investment, Tomoro acquisition (~150 FDEs), "redesign organizational infrastructure and critical workflows," 1M+ business customers.

• Anthropic -- Building a new enterprise AI services company -- the Blackstone / Hellman & Friedman / Goldman Sachs venture; Krishna Rao quote. ($1.5B valuation per TechCrunch, citing WSJ.)

• AWS -- $1B Forward Deployed Engineering organization -- "from months to days"; NFL, BMW, Lyft examples.

• Google Cloud + Accenture -- Gemini Enterprise Acceleration Program -- "AI is simple to try and hard to scale."

• ServiceNow + Accenture -- forward deployed engineering program -- 300+ prebuilt agent skills.

• IBM -- Forward Deployed Units -- six-person human+agent pods; Nestlé, Heineken, Riyadh Air.

• Fortune -- MIT report: 95% of generative AI pilots failing -- the NANDA "GenAI Divide" finding and $30-40B context.

• Gartner -- 40%+ of agentic AI projects canceled by end-2027 -- "early stage experiments or proof of concepts."

• BCG -- AI adoption research -- 74% struggle to scale value; 5% future-built (2025 update).

• McKinsey -- Unlocking success in digital transformations -- <30% transformation success rate.

• OpenAI -- Forward Deployed Engineer role -- responsibilities and $162K-280K compensation.

• OpenAI -- prompt caching and Batch API -- 50% discounts; arXiv 2601.06007 -- 45-80% cost reduction from caching across providers.

• Grand View Research -- system integration market -- $421.4B (2025) to $1.23T (2033).

• Paul David -- The Dynamo and the Computer -- electrification and the productivity paradox.

• Axios -- OpenAI DeployCo and private equity -- deal structure and the disintermediation critique.

Frequently Asked Questions

What is an AI deployment company?

An AI deployment company is an organization -- either a standalone venture like OpenAI's Deployment Company or an operating unit like Microsoft Frontier Company -- that embeds engineers inside enterprise customers to turn foundation models into production systems. The work includes selecting high-value workflows, redesigning processes, integrating models with company data and systems of record, and owning the rollout. It is the AI-era equivalent of the systems-integration firms that implemented ERP and led digital transformation programs.

What is a forward deployed engineer (FDE)?

A forward deployed engineer is a software engineer who works inside a customer's environment rather than on a vendor's product, building and shipping production systems for that one customer. Palantir popularized the role (internally nicknaming these engineers "Deltas") and for years employed more of them than conventional developers. In 2026 the title has become one of the most in-demand jobs in AI, with OpenAI, Anthropic, Google, AWS, and dozens of startups hiring FDEs.

Why do most enterprise AI pilots fail to show ROI?

The dominant causes are not model quality. Most usage stays experimental and ends with the session; individual users run expensive one-off prompts instead of engineered pipelines (caching and batch processing alone cut costs 45-80%); and no one owns the path from prototype to production -- process mapping, workflow alignment, integration with systems of record. The MIT-affiliated "GenAI Divide" report found roughly 95% of pilots deliver no measurable P&L impact, while externally partnered, deeply integrated deployments succeed at roughly twice the rate of internal efforts.

How is an AI deployment company different from a consulting firm or systems integrator?

The deployment companies are majority-owned by, or operate as units of, the model labs and hyperscalers themselves -- so they arrive with direct access to the model roadmap and a commercial incentive to grow usage of their own platform. Traditional integrators like Accenture and IBM are model-neutral but lack that inside access, and they are responding in kind: Accenture is embedded in Google's and ServiceNow's programs and invested in OpenAI's, while IBM launched its own Forward Deployed Units. Most enterprises will likely end up using both.

Should a mid-sized company hire a deployment firm or build the capability internally?

For repeatable, domain-specific workflows, the most economical answer is often neither: buy domain software where the process mapping is already built in. For company-specific workflows, start internally -- pair an engineer with the operator who owns the process, convert proven experiments into pipelines, and define production criteria (owner, cost line, SLA). Bring in outside deployment help when the workflow crosses many systems and teams, which is where embedded-engineer models earn their fees.

What does "LLMs are playdough" mean?

It is a metaphor for the gap between capability and value: a large language model is an extraordinarily malleable raw material that can be shaped into almost any function, but it arrives with no structure of its own. Like playdough, it does not become a house -- a durable, load-bearing system -- without architecture and engineering. That design work, from process mapping to pipeline construction, is what the emerging deployment function exists to do.