the ai transformation market: players, business models, and open questions

NYC, July 26th 2026

AI transformation services are valuable for clients. Clients will absolutely win, especially with so much competition in the market. The more competition there is, the better the outcomes clients can demand. Competition, thanks to capitalism, serves clients very well.

The long-term business scale of the firms offering this, though, depends on whether they can turn bespoke delivery into a repeatable software/agent factory.

Preamble

Services companies are uniquely positioned in this moment in time to make the most of the knowledge arbitrage about AI in the market. There is a massive gap between AI practitioners and adopters- from consumer adopters to enterprise adopters. From what I see in the market, adoption moves through three stages:

• Stage 1- basic use cases. Chatbots that crawl your CRMs and systems of record to answer questions. Low risk, low stakes. ChatGPT, Copilot, Glean, Claude Chat.
• Stage 2- human-prompted actions. An AI agent sends an email, sets an appointment, or initiates a wire transfer, but only when a human asks it to. The human is still in the loop. Claude Cowork and similar.
• Stage 3- autonomous decision-making. This is the last frontier: agents that approve actions independently, without a human clicking "yes." I have seen agents move into regulated workflows: approvals, exceptions, reconciliations, claims, and other decisions where mistakes have real financial consequences. Openclaw-like setups push this further- the agent gets its own portal and tools.

Stage 3 means fully end-to-end independent workflows. Two hard problems sit underneath it.

• How do you automate something that is not fully documented? Stage 3 workflows live in orgs that run on tacit knowledge, not written standard operating procedures (SOPs). There are two schools of thought on how to handle this:
  • SOP-first school of thought. SOPs need to marry SME expertise. You sit with SMEs, extract what they actually know, and encode it as SOPs that the agent follows.
  • Edra school of thought. SOPs are, by definition, incomplete. SMEs act organically based on experience, not on SOPs- their behaviour diverges from the written page, and when you lean on SOPs alone you end up asking these people to keep backfilling context that was never captured. Flip the problem upside down: look at how people actually do the work, infer SOPs from prod, and build agents that behave like the SMEs behave.
• How do you prove the agent is right? Stage 3 agents need to be heavily evaluated. The agent needs to be right, and you need to prove it. Traditional data labeling companies (Scale AI, Surge, etc.) were built for annotating images and text, not for evaluating multi-step agent traces. Foundation model companies focus on training base models, not on evaluating deployed agents. Evaluation of Stage 3 agents is still an open space. I have seen teams build this in house, and I see Micro1 starting to focus on this too.

So what does this mean? What is worth building, and what does Forward Deployed actually mean?

Forward Deployed is an over-used word. There are two main flavours:

• Product.
  • A product that already exists, and the forward-deployed motion is just to drive user adoption- see Harvey, Rogo, Glean.
  • A product that already exists, but you need engineers to configure it for the user to get value- see Sierra.
  • A product company where the forward-deployed motion is also a model-feedback loop- see OAI via The Deployment Company and Ode with Anthropic. These are essentially FDEs coming back to the mothership with real-world use cases. From my perspective, this is OAI/Anthropic getting paid by clients to develop new RL environments: instead of only paying seven- or eight-figure contracts to RL-environment startups, the lab deploys AI at high quality for the client, learns the client's workflows, and feeds that back to model and research teams so the next iteration can perform better, faster, and closer to one-shot on useful real-world tasks, without each use case needing a team of 5-10 FDEs forever.
• Services. Not a product-motion, but a problem-motion. Ideal for two kinds of businesses:
  • Those that have no clue about AI and also carry technical debt. Services here are bespoke software (e.g., analytics and tracking on their own data) plus the agentic workflows that run on top.
  • Those that are massive enterprises already heavy on software and vendors, but have no AI plan and a big AI budget to spend. Services here are mostly an AI transformation: re-imagining a whole department, a whole decision-making loop.

The AI transformation landscape

Market map

Part of the confusion is that the same phrase- AI consulting, AI transformation, forward deployed AI- is being used for very different businesses. Some are agencies. Some are venture-backed product/service hybrids. Some are roll-ups. Some are the labs themselves deciding that the best way to sell more intelligence is to send people into the building.

Note: this is not an apples-to-apples financing chart. For labs and roll-ups, the x-axis is the publicly disclosed capital committed behind the motion; for startups, it is disclosed funding raised. If a round is not public, I would rather mark it as undisclosed than pretend to know.

The thing here is that the math works out for different reasons in each bucket.

The labs: the math works out. They have a strong incentive to drive token usage. Each forward deployed team also becomes a real-world feedback loop inside a client, "deploying" AI for them, but also bringing back real workflows, real edge cases, real evals, and real RL environments. In the best version of this, the lab is getting paid to improve its own models with production use cases. The role of the FDE is not only to make the client successful; it is also to come back to the mothership and improve the mothership's actual product.

Some say that clients working with OpenAI's Deployment Company or Ode with Anthropic may be paying twice: once with money, and a second time through workflow data and feedback that can help improve the lab's models. Another critique in the space, which pushes a different way of thinking, comes from Alex Karp and the actual ROI of token spend. In this interview, he says something along the lines of: if I can make you a billion dollars, wouldn't I want to charge you 30%? Why charge for tokens, if the value is so high? Meaning: why not charge through outcome-based pricing, which Sierra is pioneering and pushing as an industry standard for AI agents? The argument is essentially that if ROI is still hard to prove, token spend can be easier to price than outcomes, because outcome-based pricing makes the target much more explicit.

The roll-ups: the math also works out. They own an old business and want to own the upside of the AI value-add. Thrive Holdings can buy accounting firms through Current, formerly Crete, and IT services firms through Shield, then use AI to improve the operating model while keeping the upside. Long Lake can buy service businesses and install AI inside the actual asset, including the announced Amex GBT acquisition with General Catalyst and Alpha Wave support that is reflected in the market map. Modus looks like a version of this in audit: capital plus technology plus operating control.

The bootstrapped services firms: the math works because they get paid like a high-luxury agency and hire like one. These are incredible businesses: bootstrapped, profitable from day one, and reshaping the economy from inception. An awesome example is Tenex.

The VC-backed transformation firms: this is the bucket I keep staring at. Percepta, Poetic, Distyl, Brain Co., Sola- where does this go? Most of these companies are not only developing a boxed product. They are offering AI transformation services, which often means ad-hoc AI deployments, workflow redesign, and bespoke software work.

Does that matter for the client? Not at all. Clients will absolutely win here. They get Harvard/MIT/top-notch teams forward deployed into their industries, and those teams do a spotless job. The value to the customer is real, but the scalability aspect is unclear.

A product company whose output is a service is different

One thing to bear in mind: a product company offering a service is very different. See Crosby. They have a product, and they offer the service of the lawyer. The lawyer is still doing the service, but accelerated because of the product. There is no bespoke software built for every customer. There is no bespoke product or workflow built from scratch every time. The service is offered bespoke, and that scales through the product that was built once.

This is a product company whose output is a service. That is not the same as the cluster above, where the company is often an agency whose output is a bespoke piece of software. That can only scale as a function of hiring more FDEs, more delivery managers, and more people- unless the internal platform becomes strong enough that the repeatable parts disappear into software.

If you are a client, what should you actually buy?

For clients, what matters is much simpler: if you need help with deployment, or if you need help coming up with an AI plan, the difference between these companies is price tag, flexibility, and bespokeness.

The more bespoke, the more expensive. The less bespoke, the less expensive. The right choice depends on technical debt, internal talent, budget, and whether you need strategy, implementation, or both.

If the work is narrow, buy the narrow thing. If your data is in spreadsheets, your SOPs are imaginary, and nobody agrees on what "good" looks like, you are not buying a tool. You are buying transformation work, and you should expect it to be more expensive, more human-heavy, and more bespoke.

Two things worth noting:

• A lot of businesses that ask for an AI transformation actually need a software transformation underneath it. For less tech-heavy businesses, I see this as technical debt: data living in spreadsheets instead of a proper database. For these businesses, an AI transformation requires a software transformation first.
  • Deal flow for these clients often comes through PE firms wanting to AI-transform portcos- a holistic revamp usually bundled with a software revamp.
  • Solar panels analogy: you can't install solar panels on a broken roof- the roof needs prep first. AI is the same. You can't drop agents onto spreadsheets and broken data- you fix the foundation first, and only then does the AI layer sit on top.
  • I have seen services firms that focus on these kind of deals bet on an acquisition by a holdco, so they can keep doing the same work across all portcos.
• For tech-forward businesses (say, they have an IT department or a CTO), the AI transformation needs less bespoke software. Here the focus can straight be workflow automations/integrations etc. And a UI becomes more of a control panel to manage these new fleet of agents, rather than the main goal.
  • A big chunk of deal flow for these comes through the labs themselves. OAI, Anthropic, Google all want to drive API adoption, and seven- to eight-figure deals led by the labs are common. Publicly reported examples include enterprise deployments like the T-Mobile work implemented in collaboration with OAI.
  • Client-led deals are model-agnostic- you pick the best model (or a council of them) per task.
  • Lab-led deals tend to benefit the lab that led them: they lean on the side of maximizing API usage and can lead to model lock-in for the client.
  • I have seen services firms that focus on this kind of deal bet on an acquisition by a lab, because labs may not want to spend years figuring out the services-heavy work that drives adoption and stickiness- see OpenAI's recent acquisition of Tomoro.

The factory question

The Forward Deployed motion pulls hard from the services angle- a large enterprise contract is much more attractive than a $20/month subscription. The issue is that historically services firms have had to assemble these contracts through heavy custom work: each engagement is one-off, hard to reuse, hard to scale, and often highly bespoke. If servicing 10 more clients requires 10 more teams, that does not feel very AI-native. Sequoia's recent hot take is that the next billion-dollar company is a services company- possible if there is a factory of software, services, and agents as the internal product, with the bespoke client ask flowing out of that factory. The primitives of that bespoke output are the product.

Today the primitives for agents are: skills, .md files, harnesses. Yesterday there were only system prompts, user prompts, contexts. Tomorrow there will be a safe Openclaw setup so clients can interact with their portals remotely from a phone, 24/7. The day after tomorrow, who knows. The primitives for agents are changing fast. The primitives of software don't. They are still FE (frontend) + FE deployment, BE (backend) + BE deployment, a DB (database), the API endpoints to interact with that DB, RBAC, etc. Once these are packaged in a quickly repeatable way, with strong agent primitives on top: what is this if not an oiled factory of services? And what separates it from a product company? Why wouldn't a business like this scale non-linearly in people?

The agency question

This is the core business-model question underneath the market: is AI consulting mostly a services business, or can it become something more product-like?

I mean it as a business-model question, not a value judgment. There is nothing inherently bad or good, right or wrong, in any of these axes or directions. I just see a lot of confusion around the word services, and I think the confusion matters for investors new to the space, for talent deciding where to spend the next few years, and for clients trying to figure out what kind of help they actually need.

In conversations with Palantirians and other operators in the space, I often hear a version of this: sometimes the platform can feel like a formality- a product placeholder, there for the sake of having a platform and a higher multiple. The question I keep coming back to: what about a high-craft, high-quality internal product that 100x's the delivery of these projects?

The internal platform1 needs to be that Surge for the Palantir-style services motion. Surge's internal tooling let a handful of people out-deliver thousands of employees at Scale. The internal tooling needs to do the same for the AI transformation motion: let a small FDE team ship high-value bespoke software/agent bundles with much less manual reinvention, because the repeatable parts are absorbed by the platform. Success looks like the same caliber of contract delivered by a much smaller team. The bespoke stays bespoke to the client; the repeatable disappears into the product.

On delivery

As long as delivery stays human and white-glove, clients paying 6, to 7 to 8 figures don't care how something is done- they care how they are treated. It needs to be human-first, white-glove- clients paying so much like to feel special and feel like their problem is your priority. Distyl did this part really well. I saw it first-hand: operators inside client orgs vouching for us, thanking us, and sometimes becoming friends. Delivery done right feels like Unreasonable Hospitality for enterprise AI: the book is about turning ordinary service into memorable, intentional experiences. The best version is not only the AI company working hard; it is the AI company and the client becoming one team around one hard problem.

It is important to note one thing though: clients don't care whether Percepta, Poetic, Brain Co., Distyl, Ciridae, Sola, 8090, Tenex, Tribe AI, Eliza, Scale AI, Thrive Holdings, Long Lake, Modus, OpenAI Deployment Company, or Ode with Anthropic got their thing done bespoke or via a cookie cutter. They do not care how you do it- the how matters to you more than to them. They care that it feels bespoke to them, that they get a white-glove service, and that it works. This is where services-heavy companies face the core scaling question: great delivery is not enough if the work never becomes repeatable. Their services can be as expensive as a Birkin and feel like Hermès- but the bag still needs a shape. Hermès scaled on the repeatability of the Birkin and the Kelly. The line between a small boutique and a Hermès is not delivery- both feel luxury. The line is repeatability. That is what unlocks the Surge of the services era.

What would make this more than an agency/services business model?

This is the part that is worth separating from any one company. The question is not "what should this specific platform build?" The question is: what would make the whole category product-like?

The answer is probably an internal factory first, and an external platform only later.

• Internal factory. Every bespoke contract should bring back primitives that make the next contract easier: OCR, eval harnesses, data connectors, deployment templates, SME feedback workflows, industry-specific playbooks.
• External platform. Only after that internal factory works should it become something a medium-technical operator can use out of the box to build, ship, and run AI-FDE work without reinventing the primitives every time.

The first product is not necessarily what the customer sees. The first product might be the operating system that lets the services team stop rebuilding the same scaffolding: monorepo setup, RBAC, FE and BE deployment, data layer, agent runtime, evals, feedback ingestion, and repo hygiene. That is boring, but boring is where repeatability starts.

Companies that I see embodying this really well are 8090 and Ciridae.

Internal factory

Ultimately, Claude Code is a harness. The recent leak of its code gave us an insight into it, see here and here. The AI-services company needs its own version of that: not a chatbot, not a demo, not a thin codegen wrapper, but the scaffolding inside which an AI-FDE gets work done end-to-end- context, tools, evals, deployment, feedback, skills, agents- all wired together and sharp out of the box.

Software is not enough

Lovable, v0, and Replit are coding agents. They help you build software. But the hard part in this category is not only building software. The hard part is building the agents that live inside that software, proving they work, deploying them safely, and continuing to improve them after the first version ships.

Vertical primitives

The other primitive this kind of company can productize is the vertical itself. You can easily have primitives per industry.

It would essentially be about figuring out the pain-points and use-cases per industry, and turning them into repeatable primitives. The first handful of agriculture clients will most likely give you a good blueprint of the issues in their industry. Once you make those primitives reusable, similar contracts after that become easier and easier to execute.

Like a "verticalization," but of skills, evals, workflows, pages, connectors, and playbooks. Not a separate product per industry; a growing library of industry-shaped primitives that every future engagement in that vertical starts from, instead of from scratch.

Avoca is a good example of this in a narrower, cleaner wedge: voice for the trades. They did not start by saying "AI transformation for every business." They productized a very specific vertical workflow: the AI front office for home services. Calls, texts, chats, booking jobs 24/7, speed-to-lead, ServiceTitan integration, call coaching, HVAC/plumbing/electrical vocabulary- all of that becomes the product. This is what I mean by the vertical becoming the primitive.

Feedback loops as the recursive primitive

I wrote about feedback loops as a product philosophy- prompts/harnesses/roadmaps should be self-healing from production signal. For an AI-services company trying to become product-like, the same philosophy has to operate at two levels.

Level 1- the internal factory itself. Every customer interaction, support thread, and sales conversation is signal. That signal flows into a queue that proposes new primitives automatically. No single PM hand-editing a single linear ticket.

Level 2- every client project the factory supports. When a project starts, the feedback sources for that client's own product (support tickets, Slack channels) get wired in on day one. That signal becomes Linear-style tickets and feature suggestions sitting inside the client's dashboard. The client's PM no longer decides from their own head; they decide from the weighted signal of all the places their product meets the world.

This is more than self-healing bugs. The agents suggest new features, pulled from the relevant feedback sources of that product. The company becomes both the factory and the factory-upgrader, at both levels.

Agent factory

Depending on the kind of contracts a company wants to take on, parts of this may not be needed.

For lighter-touch engagements, the software factory may be enough: standing up UI/BE plus light agent work for businesses that need an accessible AI-native setup.

But $10M yearly contracts from heavy-services players are a different category. These are not "build a product for a client." They are re-architecture of a line of business to be fully or mostly AI-automated- a whole department, a whole decision-making loop re-imagined (what I categorised as 'stage 3' above). The bottleneck is not the code. The bottleneck is the bespokeness of the business problem- and the human work of sourcing ground truth from the client, running the agent through it, and labeling every reasoning trace to prove it's ready for prod. Evals at this stage are not an afterthought- they are the gate.

So far, most companies in this category have focused on the agent factory: versioning of system prompts, user prompts, and harness per agent; versioned evals per agent; versioned human SME feedback attached to each eval run. GitHub, but for agent harnesses. That made sense for 2025, the year of agents. Everyone was trying to make agents work, prove they worked, and make them production-safe.

But 2026 feels like it may become the year of services. As models get better, workflows that used to take 10 brittle steps become more and more one-shottable at every model release. That changes what the factory needs to optimize for. The hard part becomes less "can we make an agent complete this one trace?" and more "can we package the delivery motion so the next client does not restart from zero?"

That is why the agent factory is necessary but not sufficient. For lighter-touch AI transformations for smaller clients, the software factory may be enough. For heavy-services re-architecture contracts, the agent-factory primitive is probably non-negotiable- but the more interesting 2026 question is whether the company can also build the services factory around it, so the re-architecture work is not redone from scratch for every client.

Moat decay (?)

In today's new world, it feels like any platform/product moat decays exponentially at every new Claude feature drop. Today's Claude Design drop is a good example- Figma was never threatened, now it is. I still believe Figma stays to Claude Design as Adobe Studio stays to Facetune: there is a product richness and density that experts will keep leaning on for the deeper product (Figma, Adobe Studio). But with new products competing, users get stratified more and more: if there is an easier version (Claude Design, Facetune), why not use that? But then also, if Claude already has all the integrations under the sun, why use Glean?

It is important to note that if a company decides to turn the internal factory into a public subscription product, which seems like something 8090 might do soon- see their roadmap and their docs- it would face the pressure of keeping up with Claude's product shipping rate, which is really fast. Examples of primitives it would need to support today:

• A safe Openclaw setup3 for each monorepo, so any user gets a 24/7 hosted agent (or orchestration of them) to interact with their newly built product.
• A skills/cowork-feeling cron job for any task created inside the monorepo. Cowork lets you set up a daily task that is done and handed back to you- something equivalent has to exist here, otherwise users get more value from Claude Cowork than from a bespoke thing lacking these features/capabilities.

Tomorrow, there will be new things. If framed as a product competing with Claude, yes- the decay of its moat is exponential at every feature drop. Glean is a useful example: imo, its moat looks more pressured now that Claude/Cowork is moving into integrations. Integrations are now a commodity. The moat of a platform of this kind though is not the uniqueness or originality of features relative to Claude. It is:

• For the internal services motion: the ability to keep up as fast as possible, so that internal FDE teams get more primitives in hand and rebuild the least possible. → To enable a Surge (internal tools that compound knowledge) instead of a Scale (brute force from scratch every delivery).
• For a possible platform motion: the ability to give any other services-client or small business a one-stop shop for everything cutting-edge in AI, so they don't have to think about it.

Therefore, the decision on whether to productize this to the outer world (like Profound) or whether to keep this in-house (like Surge) needs to be threaded carefully.

Closing thoughts: on narrative

Are AI transformations a race to the bottom, or to the top?

Enterprises and PE holdcos feel downward pressure from the top to cut costs. Take any large service business with an expensive back-office review team: many skilled people spend their days moving repetitive approvals through legacy systems. The obvious spreadsheet ROI is to automate the workflow and reduce payroll. What is the ROI of token and API spend, if not a decrease in operating costs?

The issue is that this is short-term thinking, and ignores the fact that these people carry all the alpha of the org. They are the only ones who know what "good" looks like. While agents are being built and evaluated before being left roaming free in prod, these are the only people who can get the agents ready for prod in the first place.

The second issue is that these people will almost certainly add value in unexpected ways. Ikea repurposed 9k employees into a completely new business unit. Instead of treating automation as a layoff machine, why not move domain experts into higher-leverage work: customer success, preventative support, QA, expansion, or new service lines? That can have a domino effect on the business: fewer downstream issues, better customer outcomes, and new revenue surfaces.

The question is: how can execs at the top be advised by the builders and AI execs into thinking about a larger pie, instead of slicing smaller pieces of the same pie? Does god-like AI really only allow us to cut costs, or can god-like AI help us grow revenue? That is Thrive Holdings' ethos for their portcos: 10x revenue per AI-transformed acquired business, not decimate costs only.

Because of this, regardless of speed of execution or sophistication of a product, I think that ai-services companies should serve not just as implementation partners but also as thought partners.

The goal should be to feel so aligned with the transformation you deliver that you'd want to keep the business yourself. Holdings structures get this alignment by definition, because of their overlapping economic incentives. Aiming for similar alignment in a services company is both capitalistically beneficial for the client and consistent with a narrative of abundance for the wider society.

— —

subscribe

long-form writing on AI and Tech trends, sent when it is ready.

follow on substack →