The Deployment Layer: What Actually Works

What these companies are, and why the category is opaque

Start with the thing everyone gets wrong: a frontier model is not a product. You cannot buy Claude, point it at your company, and get a result — any more than you can buy a brilliant new hire and get value on day one before they know where anything is. Someone has to plug the model into your systems, teach it your specific mess, aim it at real work, check that it did the work right, and figure out how to charge for it. The companies that do that — the “deployment layer” — are where an enterprise's AI budget actually turns into anything useful. That's the whole job.

Every player in this report, from a two-year-old startup to Accenture, runs the same core loop:

Now, this category is genuinely hard to analyze, for three reasons — and those three reasons are why this report is written the way it is:

• Almost every “what works” claim is marketing. The case studies are written by the people selling the thing, and the most impressive numbers always seem to belong to private customers who never have to back them up. Convenient.
• Nobody publishes prices. Pricing, margins, unit economics — essentially all of it is inferred, never disclosed. Wherever we're guessing, we tell you we're guessing.
• The good evidence gets scrubbed. This is the strange one: even when a public company confirms in its own audited filing that AI saved it real money, the filing almost never names the vendor that did it (Section 7 is the whole autopsy). The proof exists; the fingerprints get wiped.

How to read the confidence labels

So here's the one habit that runs through the entire report: every real number gets a confidence label, so you always know how much weight it can bear. There are four:

And when the only source is the vendor's own material, we call it Confirmed-as-claimed — meaning the company definitely said it, but nobody independent checked it. “They said so” and “it's true” are different things, and that difference is the whole game here.

Twenty-two companies, five strategic axes

This is the map of the whole report — everything after it is just the walkthrough. Every company is scored on the five choices that define a deployment strategy. A note on who's here: OpenAI and Anthropic are now on the map, not just next to it. They used to be pure model suppliers — you rented the brains, someone else did the deploying. But in 2026 both stood up real deployment arms (OpenAI literally launched an "OpenAI Deployment Company" and bought a 150-person forward-deployed team; Anthropic built its "Applied AI" org and a $100M partner network of embedded engineers). So the arms dealers are now also fighting the war — which is a big enough deal that we score them and unpack it in the callout below. Scale, Mercor, and Turing are still left out on purpose; they're in the data-and-evaluation business next door, not the deployment business.

The five axes — and how to read the matrix

The big table below packs a lot into each cell, so here's the key. Each company is scored on five choices; these are the terms you'll see in the cells and what they actually mean:

All matrix placements are evidence-backed in Sections 3–8. Cell confidence ranges from Confirmed (Palantir/Distyl architecture, Cohere model ownership, Factory routing, disclosed revenues) to Estimated (most pricing/delivery cells for private companies). Sources §.

Ontology-first vs. workflow-first — and why the fork is quietly collapsing

This is the central architectural fork of the category and the deepest section of the report. Two opposite bets, same go-to-market motion: model the whole enterprise first (Palantir), or attack one workflow first (Distyl). The investor's prior was that these two might not actually be that different. We were mandated to disprove the fork before asserting it — and the disprove-first hunt landed the report's most important finding.

Palantir (the ontology pole), mapped at architecture depth

Palantir's differentiation is architectural, not merely go-to-market. Foundry's Ontology is a largely deterministic, governed model of an enterprise — Palantir frames it as representing the enterprise's decisions, not merely its data.[1] It has two first-class halves:

• Semantic elements — object types, objects, properties, and typed link types (Palantir insists links be "semantically meaningful," not shared foreign keys). Interfaces provide polymorphism so "a single workflow covers all implementing types."[1] Confirmed
• Kinetic elements — Action types (governed writes committed as a single transaction) and Functions (business logic, computation, model calls, ontology edits).[2] Confirmed

Here's how the AI actually touches all this, in plain terms. It never gets handed the company's raw database. Instead it works through five guardrails: (1) only the relevant facts get pulled into its view on each message, never the whole schema; (2) it can walk the connections between objects — Order → Shipment → Carrier → hub — which ordinary keyword search simply can't do; (3) it can run the company's actual business logic; (4) when it wants to change something, that change goes through a controlled, optionally human-approved “Action” rather than a raw database write; and (5) the whole thing is governed, so the agent only ever acts through the sanctioned boundary.[5] Palantir's own phrase for the philosophy: “determinism where possible, autonomy where necessary, constraint everywhere.” The key point for an investor: the valuable part is not the model — Palantir just rents whichever model is best — it's this governed layer that turns the reckless version (“hand the AI your database password”) into the safe version (“let the AI act only through a controlled interface”).[5] Estimated-Inferred

Distyl (the workflow pole), and its 2026 convergence

In June our verified map of Distyl was the pure workflow-first archetype: a Standard Operating Procedure auto-decomposed into "Routines" — discrete, auditable tasks with logged inputs/outputs/tool-calls — a thin, local semantic layer per workflow.[16] That is still true at the execution layer. But Distyl's own 2026 technology pages describe a four-layer platform whose foundation is now a persistent semantic layer Confirmed-as-claimed:

• Context Mesh — "an AI-native data foundation. It reads from your existing data systems… and writes back what every agent decides. Your data stays where it is. No migration required." "When an agent makes a decision, that output flows back into the mesh, semantically indexed… Each new use case inherits everything Context Mesh already knows." Agents are "first-class citizens" with "explicit, auditable permissions."[3]
• Context Views — explicitly "the semantic layer… a foundation of human-understandable objects: business entities, relationships, and constraints… your agents can reason from." SME "Directed Review" edits become "a reusable update to the schema itself."[4]

Distyl's own NVIDIA-integration post describes moving "past the concept of the flat, static retrieval index" to build "a living, traversable graph… encompass[ing] episodic memory, tacit and explicit knowledge, policies, workflows, and domain logic," where agents "write back state that persists long after the session ends."[6] A third-party analysis states it plainly: "Distyl is applying [Palantir's ontology] thesis natively to LLM agents."[17] Reported

Head-to-head: same destination, different construction method

Disprove-first: the null hypothesis is strongly supported

Evidence Distyl is moving toward Palantir: Context Mesh is a write-back knowledge graph; Context Views is an explicit "semantic layer"; the ex-Palantir founders (Arjun Prakash + Derek Ho) make the ontology DNA intentional.[3][4] Evidence Palantir is moving toward Distyl: the AIP Bootcamp promises "zero to use case in 5 days or less," with "at least one production-ready workflow by day five" — Palantir attacking the fast per-workflow motion.[7] Confirmed-as-claimed

The compounding-vs-ceiling stress-test

The thesis under test: workflow-first converts to production faster but ceilings into 40 disconnected point-solutions; ontology-first is slower-to-value but compounds because every new workflow inherits the object model.

• For compounding: Palantir documents the mechanism (interfaces + canonical objects → workflow reuse).[8] And the strongest single data point in this leg: Distyl's own pivot is revealed-preference evidence the ceiling is real. A workflow-first company at a ~$1.8B valuation chose to spend engineering building Context Mesh — whose entire pitch is escaping "add a second agent, then a tenth, and each operates from its own blind spot… No compounding. Just isolated automation, multiplied." Distyl is describing the exact ceiling the thesis predicts, and building to escape it.[3]
• Against / complicating: "Slower-to-value" for ontology-first is now weakly false — a first workflow ships fast on either pole (AIP Bootcamp, ≤5 days). And Palantir itself warns compounding only holds if teams converge on shared concepts; duplicated object types can accrete redundancy instead of value.[8] Ontology-first does not automatically compound — it compounds if governed well.

Open vs. closed, by use case — and the one company that owns its models

The pattern here is refreshingly clear for once: 13 of the 14 independents just use the big frontier models as-is — they don't train their own. The deployment layer sits on top of the model, not inside it. So the only real choices are which models, how easily you can swap between them, and whether you bother fine-tuning one for a specific domain.

• Model-agnostic routing is becoming table stakes. Factory explicitly routes Claude/GPT/Gemini per task to avoid lock-in and control cost[24] Confirmed; Glean routes across Bedrock/Vertex/Azure OpenAI[28]; Palantir and Sierra broker multiple providers.
• Closed frontier dominates the reasoning core; open-weight appears where the environment demands it — regulated, on-prem, air-gapped, or cost-sensitive. Cohere's entire pitch is private deployment ("GPU in a closet")[29]; Distyl runs open Nemotron via NVIDIA NIM alongside closed frontier for its deterministic pipeline.[6]
• Cohere is the lone model owner — and it ships open weights. It trains its own Command/Embed/Rerank family and releases open weights under Apache-2.0 for self-host, selling private, in-VPC, “GPU-in-a-closet” deployment — a fundamentally different business (model vendor, not deployment layer) that happens to sit adjacent.[29] Confirmed
• Domain fine-tuning is the exception, concentrated where accuracy is legally load-bearing: Harvey layers legal case-law fine-tunes and has shipped its own open-weight post-trained model (“Tenet”)[26], Cresta runs contact-center models fine-tuned on client conversation data[27], and Happy Robot [60] builds proprietary in-house voice/end-of-turn models for latency.[22] Reported The pattern is instructive: owned/open weights appear in exactly two places — regulated/air-gapped (Cohere) and domain adaptation where accuracy is legally load-bearing (Harvey’s Tenet, Cresta) — never in the generic orchestration core.

The single most-cited enterprise-spend datapoint of 2026: Anthropic leads enterprise LLM spend at 40%, having "unseated OpenAI" (Menlo Ventures).[30] Reported — a market-model estimate from a VC with portfolio exposure, directionally strong but not audited. Distyl, Cognition, and Harvey all skew Anthropic-heavy in their orchestration, consistent with that leadership.

Where designs converge — and the one component everyone builds

Strip the marketing away and the orchestration stacks rhyme: ingestion/connectors → a semantic or context layer → a planner/executor split (an orchestrator model directing task models) → tool and action calls → a verification layer → human-in-the-loop checkpoints → memory/state. The interesting question is where they converge vs. genuinely differ.

The universal building block: the verification layer

The academic literature corroborates why this layer is non-negotiable: single-run benchmark success does not predict production reliability, and agent failures are frequently silent — hallucination, misinterpreted instructions, and reasoning drift that propagate without throwing any runtime exception (MAS-FIRE; ReliabilityBench; IBM's CUGA deployment paper).[34][33][35] Reported A verifier is the only thing standing between "the demo worked" and "the deployment silently corrupted a workflow."

Where designs genuinely differ

• The semantic layer — persistent enterprise ontology (Palantir, Distyl-2026, Claritype [56]) vs. a knowledge-graph substrate that grounds retrieval (Glean's Enterprise Graph) vs. thin per-workflow context (CX/coding agents). This is the Section-3 fork.
• Determinism placement — Happy Robot puts deterministic rule-guards on high-stakes outputs (a freight rate, a booking number) so the LLM cannot bypass validation[22]; Palantir puts determinism in the Action transaction; Distyl runs a deterministic deep-research pipeline where "the code lays the tracks, the model reasons over results."[6]
• Substrate ownership — own it (Palantir, Distyl), rent it (Northslope [59] rents Palantir's AIP/Foundry), or skip it (pure per-workflow agents).

The planner/executor pattern (an orchestrator model decomposing work and directing task models) is now near-universal in the agentic players — Factory's coordinator assigning role-scoped Droids[25], Cognition's long-horizon task decomposition[18], Palantir's AIP Logic. It is converging into a commodity pattern; the differentiation has moved to the context layer beneath it and the verification layer above it.

FDEs are dying at the edges; outcome pricing is rare and CX-shaped

Delivery: forward-deployed engineering survives only where the substrate is complex

Forward-deployed engineering — the Palantir-invented playbook that started this category — is expensive, and across the 14 independents only four still really run it: Distyl, Northslope, Harvey (literally described as “a services business with software margins”), and 8090 (delivered through EY).[26] Reported Everywhere the job is cleaner and more self-contained — writing code (Factory, Cognition), search (Glean), support tickets (Decagon, Sierra), voice (Happy Robot) — companies skipped the embedded-engineer model and just shipped a product you can buy yourself. Factory sells off the shelf with no seat minimums[24]; Glean lands on seats and grows into agents.[28]

Commercial: outcome pricing is rarer than the narrative claims

“We only get paid when you get a result” is the category's favorite line. In practice, genuine pay-for-outcome billing is rare, and almost entirely a customer-service thing. Only Sierra truly bills per-resolution. Decagon [58] offers it as an option but says most customers still pick per-conversation because it's predictable. Cresta talks “outcome-led” but actually invoices per-seat plus usage (its own rate card: 125K chats/yr for $150K).[27] Confirmed (rate card) Coding, legal, and search bill the old-fashioned way — seats and usage.

The reason is simple once you see it: to bill per outcome, you need an outcome you can count — a “resolved ticket.” That clean unit exists in customer service and almost nowhere else. You can't invoice “per transformed supply chain.” So wherever you hear “own the outcome” outside of CX (Distyl, 8090), it's marketing language wrapped around what is really a services contract, not a meter that ticks per result. Estimated-Inferred — no rate cards exist; the pricing structure is our inference.

The hard data: mostly, it does not exist — and that is the finding

Everyone wants the same thing here: hard proof of what actually converts a pilot into production and moves the P&L — not another testimonial. We looked three ways: at what the big deployment aggregators show across thousands of projects, at the customer-side filings behind specific wins, and at the academic literature. The honest headline: the gold-standard proof barely exists in public, and the statistic everyone quotes is the flimsiest one in the pile. But the aggregate data is real and it does say something — so start there.

7.0 — What the aggregators actually show, at scale

Rather than cherry-pick a few flattering case studies, start with the databases that have already collected thousands of real deployments and asked “what shipped, and what held up?” Three are worth knowing, and they agree with each other:

• ZenML's LLMOps database — ~1,200 production deployments catalogued through 2025 — is the most useful because it's specifically about what survives contact with production. Its recurring lesson is almost blunt: simple, narrow workflows beat flashy general-purpose agents, and the systems that work pair retrieval with real evaluation, monitoring, and a human in the loop rather than clever prompting. In their words, “context engineering over prompt engineering” — getting the right data in front of the model matters more than the model.[61] Reported This is the same conclusion the rest of this report reached from the architecture side, arrived at independently from 1,200 shipped systems.
• Evidently AI's database — ~800 production ML/LLM case studies across 150+ companies — is the cleanest “what's actually running” catalog; it deliberately excludes demos and pilots.[55] Reported Useful for texture (which patterns recur, in which industries), useless as a success rate — it only contains the winners.
• AIUseCaseHub — ~3,814 public deployments across ~3,241 companies, filterable by maturity (Production / Scaled Production) and “evidence strength.”[62] Reported Its own fine print is the tell: it warns that its evidence signals describe “what the source supports, not an independent audit that a system is still operational.” Even the aggregator built to track this stuff won't vouch that the deployments still work.

7.1 — Named contract outcomes: exactly one clean triangulation (AIG), and it took the customer choosing to disclose it

So the aggregators can't tell you who won. Can anyone? The gold standard would be a public company saying, in its own audited filing, “this specific vendor produced this specific result.” That beats any case study, because the customer has to answer to auditors. We took the deployco case studies that named public customers and went looking for the number in the customer's own annual reports, 10-Ks, investor days, and earnings calls. Nine worked examples. Here's how many survived:

Tally: 1 CONFIRMED-TRIANGULATED (AIG) · 2 PARTIAL (GE, T-Mobile) · 6 VENDOR-CLAIMED-UNCORROBORATED. The one clean case is AIG → Palantir + Anthropic — the most valuable page in this report. AIG's own 2025 annual report discloses the measured outcomes (Lexington 370,000+ submissions, up ~26% YoY; submit-to-bind up ~35–40%; claims cycle times from hours to minutes; figures REPORTED-from-primary — relayed from AIG-hosted primary docs, as the AIG PDF fetched as raw bytes rather than quoted verbatim), and AIG's own investor day and earnings call name Palantir and Anthropic as the partners and describe reviewing 100% of private/non-profit submissions without adding underwriters, targeting $4B+ new premium by 2030.[40] Two independent AIG-authored channels close the triangle.

The two partials show the more common failure. GE Aerospace's FY2025 10-K independently reports deliveries up 26% and discloses concrete AI-productivity tools (an AI blade-inspection tool halving inspection time; an AI material assistant cutting MRO turnaround) — but a full-text EDGAR search for "Palantir" across all GE filings returns zero hits.[36][37] T-Mobile's own Q4-2025 calls corroborate the ~$3B-savings magnitude of Distyl's claim but never name Distyl (crediting a partner “with OpenAI”).[40] Each confirms an AI-driven gain; each strips or mismatches the vendor.

Investment implication: any deployco pitch resting on "named enterprise + quantified outcome" is, evidentially, vendor-attested marketing — even when the enterprise is real and public. Diligence should treat these as leads, then (a) check EDGAR full-text for the deployco's name in the customer's filings (usually 0 hits) and (b) look for whether the customer independently quantifies any aligned metric. The GE-style partial is the ceiling of available evidence, not the floor. The base rate confirms it: ~90% of the S&P 500 mention AI in 10-Ks[45], yet only ~12% of CEOs cite both cost and revenue benefit, and 56% report no significant financial benefit.[46] Reported

7.2 — Pilot→production: grading the "95%," not parroting it

You've seen the “95% of AI pilots fail” line — it was everywhere. It comes from one source, MIT/NANDA's The GenAI Divide: State of AI in Business 2025, and we read all 26 pages so you don't have to. Here's what's actually behind the number: a look at “over 300 publicly disclosed AI initiatives,” 52 interviews, and a survey of “153 senior leaders collected across four major industry conferences.”[31] That is a conference-hallway survey, not a census — and it gets shakier from there:

Crucially, the 95% refers specifically to custom/task-specific enterprise GenAI tools; generic chatbots (ChatGPT/Copilot) are reported at ~83% adoption and explicitly excluded.[31] Autopsy verdict: a defensible qualitative signal that custom GenAI struggles to reach durable production — but it does NOT support precise quantitative claims. The number's virality outran its rigor. Consensus-but-Unproven Cite the pattern; never the precision.

The defensible benchmarks come from higher-rigor sources, all verified against primary pages:

• ISG State of Enterprise AI Adoption 2025 (n=1,200 defined use cases): 31% reached full production (double 2024); ~$1.3M average spend to date; 1 in 4 initiatives achieving expected ROI on growth; 50% hitting expected efficiency gains — all four figures confirmed verbatim.[32] Confirmed The most defensible public benchmark of pilot→production conversion.
• Ramp AI Index — corporate-card transaction data from 50,000+ businesses (measured spend, not survey): ~4× monthly AI spend growth Feb 2025 → Feb 2026. Ramp underestimates adoption (misses free tools) — the honest direction of bias.[48] Reported The highest-rigor source on the spend question.
• Menlo Ventures — enterprise GenAI spend $37B in 2025, 3.2× YoY; 76% of use cases now purchased vs. built; buyers convert at 47% to production vs. 25% for traditional SaaS.[30] Reported (VC-modeled — flag the book.)

7.3 — The academic corpus: the failure mechanism is real and named

The Valency academic corpus returned 11 on-thesis, real arXiv papers. The consensus is consistent and useful: (1) single-run benchmark success ≠ production reliability (ReliabilityBench introduces consistency/robustness/fault-tolerance metrics)[33]; (2) agent/RAG failures are frequently silent (MAS-FIRE: semantic failures propagate without exceptions)[34]; (3) enterprise-specific gaps recur — domain process knowledge, evolving requirements, role-based data access. IBM's own deployment paper is the most on-thesis case study: "evidence of [generalist agents'] use in production enterprise settings remains limited" — benchmark strength does not equal deployed business value.[35] Reported (arXiv preprints — verify ids before external citation.)

Threat, channel, or roadkill? Mostly channel.

Our June writeup dismissed the consulting firms in two sentences. That was a mistake. Accenture, McKinsey (QuantumBlack), Deloitte, EY, BCG X, and IBM Consulting are the biggest, best-funded sales channels into exactly the giant, cautious enterprise buyers that a startup can't reach on its own. And the important fact is what they did: every one of them chose to partner with or buy the deployment layer rather than try to out-build it. When the incumbents decide to resell you instead of copy you, that tells you where the value is.

The tell is in what they actually did. EY rents 8090's software factory rather than building one[52]; Deloitte put Claude in front of ~470,000 of its own people (Anthropic's largest deployment anywhere) and wraps Palantir's platform[51]; McKinsey and BCG joined OpenAI's Frontier Alliance[50]; Accenture stood up a 2,000-plus-person Palantir unit and simply bought two embedded-engineering shops (RANGR, Decho).[49] Every one of these is a firm admitting it can't out-build the startups — so it resells them instead.

The disclosed numbers frame the stakes. Accenture's $5.9B GenAI bookings and $2.7B advanced-AI revenue[49] Confirmed and IBM's >$12.5B cumulative GenAI book[53] Confirmed prove demand is real and large — but both are single-digit shares of firm revenue and heavily bookings-weighted (i.e., early). EY, McKinsey, Deloitte, and BCG are private and do not disclose GenAI-specific revenue; BCG's ~$3.6B is AI-related (a broader bucket than GenAI-specific), so it is not comparable to Accenture's number.

Where the category converges, where the real forks are, and what remains unknown

Having scored 22 companies across five axes and hunted hard for evidence, the payoff synthesis:

Where the whole category genuinely converges

• The model is not the moat. 13 of 14 independents orchestrate the same frontier models; routing is increasingly automated. Differentiation lives above and below the model.
• Everyone has a verifier. The verification/eval layer is the universal building block — the mechanism that makes probabilistic output billable. It is the most convergent and most load-bearing component in the category.
• The planner/executor pattern is commoditizing. Orchestrator-directs-task-model is now table stakes in the agentic players.
• "Own the outcome" is mostly a framing, not a metered invoice — except in CX, where a resolution is countable.

Where the real strategic forks are

• Depth of the deterministic write-back substrate (the surviving core of the ontology fork). Owning a governed, transactional, systems-of-record write layer is the deepest and hardest-to-copy moat — and the accumulated integration surface behind it is a genuine head-start advantage. This is where Palantir's real daylight over Distyl remains.
• Substrate ownership vs. rental. Own it (Palantir, Distyl) → platform margins and platform valuation. Rent it (Northslope on Palantir) → app-layer margins and dependency risk. This is the single clearest value-capture fork.
• FDE where the substrate is complex; product-led where it is legible. A delivery-model choice dictated by problem structure, not preference — and the frontier of "complex enough to need FDEs" retreats as models improve.
• Outcome pricing where the unit is countable. A durable edge in CX; structurally unavailable for complex transformation.

What the evidence (weakly or strongly) suggests works vs. fails

What remains genuinely unknown — and worth stating plainly

So, the whole thing in a paragraph. The deployment layer is real, big, and growing fast, and underneath the branding everyone is building the same machine: rent a frontier model, feed it the company's data in some organized way, check its work, deliver the result, send an invoice. The parts that are actually hard to copy are the boring ones — the plumbing that lets an agent safely change systems of record, the years of integration wiring, and the verification layer. The exciting-sounding differentiators — which model you use, “we only bill for outcomes,” armies of embedded engineers — are mostly either commoditizing, specific to customer service, or dictated by how messy the problem is rather than by any real strategy. And the secret the category doesn't advertise: almost nothing about “what works” can be proven from public data. Which is the real takeaway. In a market this foggy, being willing to say “we don't actually know, and here's exactly why” isn't a gap in the analysis — it's the most useful thing an investor can be handed.