TLDR
- Enterprise AI diffusion is stuck at the deployment layer. The models are ready. The enterprise's data, ontology and workflows are where projects die.
- Capital is funding forward deployed engineering as if it were a shortcut to diffusion, and backing product founders whose instincts come from self-serve SaaS and consumer apps. They build excellent harnesses and staff them with engineers who lack workflow depth.
- The result is point solutions: six-week SOWs, one use case live, reported as ARR that is padded to look like software growth.
- The incumbents (Infosys, Accenture and peers) understand data and integration at scale, and have the cash to act. They build for a customer of one and have no platform to carry abstractions back to.
- The real FDE job has three steps. Understand the data. Build the ontology. Abstract the build back to the mothership and roll it across a cohort. Solve deeply for three enterprises in a vertical and the next seven become a high-margin rollout.
Where Moative fits. Moative is built for that cohort curve. It works in midmarket B2B verticals (energy, healthcare, construction, logistics) and pairs forward deployed engineers with vertical IP the firm owns, so each engagement feeds a reusable platform. Clients share in the upside the build creates. The firm measures progress by how much of client four was already built for client one.
Capital, ARR tricks, and Sparkling Sales Engineers are killing AI adoption
The models got good enough a while ago. What stalls enterprise AI now lives inside the enterprise: data spread across a dozen systems, definitions that change by department, approvals buried in someone's inbox, exceptions that stays in people’s heads.
Palantir CTO Shyam Sankar made the sharpest version of this point to Ben Thompson last week. The labs' product strategy assumes the atomic unit of the enterprise is the knowledge worker. Sankar's experience says the atomic unit is the workflow. Make one supply chain analyst faster and the company sees no incremental return. The value shows up only when the whole supply chain workflow gets measurably better.
That makes diffusion a deployment problem. It is also, quietly, a product problem. Two groups have rushed in to own it. Neither is doing a good job.
The product founders arrive
The best founders of the last decade built for the self-serve buyer. Collaboration suites, video, ad products, consumer-grade SaaS. Their instincts are sharp. Ship fast, instrument usage, make the interface a pleasure, let the product sell itself. Those instincts built great companies.
They are now in the diffusion business, and capital has followed them in. The pitch is clean. Palantir proved forward deployed engineering works. The labs have adopted the model. Pair a strong harness with engineers who sit inside the customer, and there is a straight line to the holy grail of enterprise AI.
The harness is real. These teams build excellent agent frameworks, evaluation tooling and orchestration. The weak link is the person they send in.
An FDE inside a midmarket logistics company or a home health agency has to read a claims ledger. They have to work out why dispatch and billing disagree on what a "job" is, and find the screen the operations manager actually lives in. That person is part hacker, part analyst, part data modeller. Most product-led FDE firms hire strong generalist engineers and PMs and hope the domain rubs off within the SOW. The second SOW, the third, and the sixth is where the ontology begins to get shaped. No one has the patience for slow burn. The person missing from that room is often an industry veteran who knows why the workflow exists at all, the role we called the Forward Deployed Executive.
What the clown show looks like
I have spoken with half a dozen well-known FDE companies over the last few months. The pattern repeats.
A six-week statement of work. One use case live: a summariser, a document extractor, a triage agent. Then a logo, a case study and a conversation about use case number two.
None of it touches the messy, connected workflows that define a small cohort of large enterprises in a vertical. Take a health system's revenue cycle. Eligibility, prior authorisation, coding, claims, denials, appeals, collections. Each step makes a respectable point solution. The value sits in the connections, where a denial pattern should change how intake captures data three steps upstream.
Solve that end to end for three health systems and you own an asset. The next seven clients become a high-margin, high-revenue rollout, because the ontology, the integrations and the exception handling already exist. Solve one isolated step for one customer and you own a project.
Sankar describes the same economics from inside Palantir. When the hardest version of a problem sits with a small number of customers on a power law, the work has to run from specific to general. You go from one customer to two to three, and only then have you earned enough surface area to see the general form of the solution. Engineers hate it because it feels like wasted work. It is the only route to a product that fits the whole cohort.
Point solutions are rational for the firm selling them. They scope fast, price easily and demo well. They do very little for diffusion.
They pad up the ARR.
The abominable ARR metric
The market values FDE firms like software companies, so they report like software companies. Bookings get pulled into the measurement window. Multi-year services contracts get annualised. Pilot fees get called recurring. The chart looks like a SaaS company in its best year.
The chart cannot tell you whether anything compounds. A firm earning 80% of revenue from bespoke builds and a firm earning 80% from a reused platform can post identical ARR. Only one of them gets cheaper to serve at customer number ten. If deployment two does not cost less than deployment one, nothing is being reused, a test we set out in Don’t shortsell your know-how to AI vendors.
Capital is fickle. ARR is gamed. Point solutions get built. And the ontology whimpers in a greasy corner next to the enterprise's generator room.
The sleeping giants
Infosys, Accenture and their peers understand this problem better than anyone. They have spent three decades inside enterprise data. They know the ERP customisations, the mainframe batch jobs, the middleware nobody dares touch. Their delivery teams model ontologies every day, even if the artefact is called a data dictionary or a solution design document.
Their weakness is abstraction. They build for a customer of one, because the model pays for hours delivered against a bespoke scope. There is no operating system to carry the abstraction back to. What engagement 400 learned stays in engagement 400, written up in a deck and maintained by a team that rotates off.
That model produced enormous free cash flow and decades of cash reserves. It also trained these firms out of productising. AI threatens the core of their business, and they hold the balance sheet to respond. So far the response has mostly been partnerships, centres of excellence and rebranded accelerators.
The market therefore holds two halves of the answer. Product founders have the harness and the instinct to abstract, and lack workflow depth. Incumbents have workflow depth and cash, and lack the instinct and the platform to abstract into.
What the job actually is
Sankar treats forward deployed engineering as a product strategy first, with the role sitting well downstream of it. FDEs report into product, and the go-to-market team has no claim on them. Their real output is an earned opinion on where the abstraction should sit in the stack: which parts generalise across the fleet and which stay specific to one customer. An end-to-end build for one client is overfit by definition. Firms that put smart engineers next to customers with no way to metabolise that pain into product are, in his words, doing "sparkling sales engineering."
He adds that perhaps five people in Palantir's history understand the strategy well enough to rebuild it elsewhere. Hiring an ex-Palantir FDE buys a résumé. The method stays behind.
The people matter as much as the structure. Sankar describes a tension between two caricatures of engineer. The hacker gets a thrill from making one thing work in the field and has a knack for finding the problems worth solving. The artist cares how beautifully the thing is built and turns a field fix into something general. Each believes they did most of the work, and the balance between them has to be managed. Product-led FDE firms are full of artists and short of hackers who can walk a claims ledger. The hackers should be the FDEs but they should stay on to build the ontology. At the abstraction they should handover to the artists.
The job has three verbs.
- Understand the data. Sit with the systems of record until you know where the truth lives, where it is duplicated and where it is wrong.
- Build the ontology. Model the objects, relationships and actions the business runs on: patients, visits, authorisations, claims; or loads, lanes, carriers, invoices. The ontology is the asset. Agents act on it and workflows run through it.
- Abstract to the mothership. Carry what was built for one client back into a shared platform, so the next client in the cohort starts most of the way there.
This is also why the job resists automation.
What the market mostly has today are engineers and PMs who can vibe code a six-week SOW. Disconnected vibe-coded apps become attritional software: you either kill them or carry the debt. The ontology is what keeps that entropy governable.
Where diffusion goes from here
Enterprise AI will diffuse vertically, cohort by cohort. A small set of large companies in a vertical share the same systems, the same regulators and the same failure modes. The firm that earns the right to model three of them deeply will own the rollout to the rest.
In its early years the AI FDE firm will resemble neither a classic SaaS company nor a classic systems integrator. Revenue will be lumpy and services-heavy at first. Gross margin will climb with each client in the cohort. It will track reused ontology objects and time to production for client number four, and treat ARR as a lagging indicator.
Capital that wants diffusion should fund that curve, and back the engineers willing to walk into the generator room and pull the ontology out of its misery. The reward will be a cash flow machine, a decade from now.
But do we have patient capital or even patient founders? Heck, do we have patient adopters?
Frequently asked questions
What is sparkling sales engineering?
Sparkling sales engineering is Palantir CTO Shyam Sankar’s name for firms that put smart engineers next to customers with no way to turn what they learn into product. The engineers deliver a build for one client, but nothing carries forward to the next. In his view, forward deployed engineering is a product strategy first, and FDEs should report into product, not go-to-market.
What is an ontology in enterprise AI?
An ontology models the objects, relationships and actions a business runs on. In healthcare that means patients, visits, authorizations and claims. In logistics it means loads, lanes, carriers and invoices. The ontology is the asset: agents act on it and workflows run through it.
Why is enterprise AI adoption stalling?
The models have been good enough for a while. What stalls enterprise AI lives inside the enterprise: data spread across a dozen systems, definitions that change by department, approvals buried in inboxes, and exceptions that live in people’s heads. The value shows up only when a whole workflow gets measurably better, not when one knowledge worker gets faster.
Why is ARR misleading for forward deployed engineering companies?FDE firms are valued like software companies, so they report like them. Bookings get pulled into the measurement window, multi-year services contracts get annualized and pilot fees get called recurring. A firm earning most of its revenue from bespoke builds can post the same ARR as one earning it from a reused platform, but only the second gets cheaper to serve at customer number ten.
What does a forward deployed engineer actually do?
The job has three steps. First, understand the data by sitting with the systems of record until you know where the truth lives. Second, build the ontology the business runs on. Third, abstract that build back into a shared platform, so the next client in the cohort starts most of the way there.
How do you choose a forward deployed engineering partner?
Look past six-week statements of work that put one use case live. Ask whether the firm has solved a connected workflow end to end for a few companies in your vertical, and how much of that work it reuses for the next client. Useful signs are reused ontology objects and time to production for client number four, with ARR treated as a lagging indicator.
