Bolt-on acquisitions are one of the most common tactics in the private equity value creation playbook. Nearly every thesis includes it.
It starts with a slide deck that has a phrase like this: “highly fragmented market with significant consolidation opportunity”. There are thousands of small operators, aging founders, and limited institutional involvement. Buy a mid-size one at 6x, bolt–on half-a-dozen smaller ones at 4-5x, sell at 12x.
Half-way through the deck, everyone in the room is doing the mental-math on the carry. It gets approved in under 10 minutes.
Lately, there’s another item that’s become just as common: the slide tracking AI opportunities and initiatives across the portfolio. As the hype cycle crests, reality is beginning to set in for many: the pilot that was supposed to be live by now is stalled. The platform is asking for additional budget. The problem is that they have four ticketing systems, three invoicing systems, and multiple conflicting records of who their customers are. The data schema is a mess.
Smart operators are starting to connect the dots between these two.
The rapid bolt-on playbook that has been the workhorse of multiple-expansion for a generation is making it difficult to take advantage of the AI technology that promises to be the workhorse of value creation for the next generation.
Because of that, an entirely new playbook is starting to emerge, which is what I want to discuss.
Roll-up Logic
Let’s begin with item one, the roll-up.
The roll-up works. It has worked for decades, across dozens of fragmented service verticals, and it will keep working. Buy a set of small companies at 5-6x earnings, assemble them into a platform that trades at 10-12x, and the multiple arbitrage is real, regardless of how deeply the underlying operations were ever stitched together. Competition may be increasing the original acquisition multiples and compressing returns, but the underlying concept still works.
Integration is the expensive part. It's slow, it carries real execution risk, and it has to take place against a finite hold period. So the rational move, deal by deal, is to consolidate what's cheap to consolidate (the P&L, the brand, purchasing, maybe finance) and to leave the operating systems where they are.
Unify the story. Defer the plumbing.
And every owner in the chain makes the same call, for the same good reasons. Which is how a platform on its third sponsor can be eleven years and nine acquisitions deep with the integration still described as "planned" in every deck. Nobody in that ownership chain was wrong. Each of them optimized correctly for the clock they were running against.
Integration Logic
The logic behind item two is the one I’ve been addressing over the last several issues.
Some decisions lay the foundation of a company and then resist being changed; the way its systems are wired is one of them (Systems Design and Incumbent Disadvantage). Value that compounds sits on something the company actually owns and controls, while value built on a rented surface decays quietly underneath (The Altman Test and the Karp Test). No intelligence layer can stand on a company it can't read (Legibility Is the Prerequisite for AI Initiative Success). And the thing customers actually leave you over is rarely a bad quarter; it's inconsistency, the service that was excellent in March and unrecognizable in June (Variance Will Fire You First).
If you put all those ideas together, you can start to develop a working theory of AI-native logic: AI-driven value compounds best on a unified data substrate. An agent that resolves a ticket needs one version of the customer, one resolution history, one service catalog, one escalation path. The capability has to be built underneath the workflow, not attached to the outside of it. A platform assembled from nine companies has nine of everything. Whatever gets built on top inherits all nine.
Where the Ideas Meet
Where do these two ideas (roll-up logic, integration logic) meet?
The bolted-together platform is not a failure of discipline. It's not the outcome of lazy operators or a deferred to-do list. It is the output of value-creation logic working exactly as designed. Deferring integration produces the mess, but for sound financial reasons.
Which means "our AI pilots keep stalling" is almost never a vendor problem or a talent problem. It’s the tension between the playbook of the last 30 years and the playbook of the next 30 years.
The vocabulary itself is part of the tell. The industry calls the acquisition motion a "bolt-on," and the word describes exactly what it produces: something attached to the surface rather than built into the structure. Something bolted on, by definition, is not deeply integrated.
Then the AI gets bolted onto the bolt-ons, one point solution per silo, each sitting on its own private version of the truth, and the intelligence layer can end up multiplying the very illegibility it was bought to cure.
What It Looks Like On The Ground
Here’s a hybrid version of a few platforms I’ve worked with. Call the operating partner John, brought in by the third sponsor to run a managed-services platform: roughly eighty-five million in revenue, eight acquisitions over eleven years, three PSA and ticketing systems still in production, two invoicing conventions, and a customer record that exists in four different shapes depending on which acquired company originally got the sale.
John did everything right by the playbook he'd been handed.
The value creation plan called for AI-enabled operations, so he funded a pilot: an agent to triage inbound tickets and draft first responses across the platform. It had a good vendor and clear scope, which are usually good conditions for success.
The pilot reached the point where the agent needed a given customer's resolution history and discovered that the customer had four histories. The pilot didn't fail catastrophically. It just quietly narrowed until it was running inside the one acquired company whose systems were already clean, which happened to be the company that had needed it the least, because their people-process-technology loop was already dialed in.
John didn’t make a bad decision. He'd made a good decision on a bad assumption.
Why It's Starting to Cost Something
None of this is new. The analysis and debate about how much to integrate versus what to defer is as old as the roll-up.
What's new is that it's starting to get priced.
For twenty years integrating the deferral work was largely free at exit. The next buyer underwrote the same assembly logic the seller did, so the missing integration didn’t lead to multiple compression. Nobody priced systems integration that every serious bidder also decided to defer. That is the part that I see changing, and it's changing from two directions at once.
The first is diligence. AI-readiness is becoming a line item in the diligence process in a way it never was before. Buyers have started asking, in some structured form, whether a platform can actually deploy the AI its own plan assumes, and a data layer that can't answer that question is beginning to read the way aging on-premise IT started to read once cloud-native competitors existed: as a retrofit bill the buyer will price into the offer, rather than a footnote everyone politely ignores.
The second is competition. There is now a new class of buyers assembling service businesses AI-first, on a unified data substrate, by design from the first acquisition. In managed services, Titan MSP built its platform around automating a large share of routine MSP work and then acquired into that foundation rather than trying to stitch things together after four acquisitions. In property management, Dwelly rolled up a handful of agencies onto one operating layer and roughly doubled EBITDA margins. Similar moves are underway in accounting and in legal services.
These are not better-run roll-ups. They are roll-ups running a new playbook: substrate first, acquisitions second. It is slower initially, but it accelerates rapidly once the foundation is laid.
That means the un-integrated platform is now exposed in two ways: the buyer is learning to check for the substrate during diligence, and a growing class of competitors already have one.
The pricing shift is early, and it's uneven across sectors. I've seen more of it in diligence conversations than in actual closed comps. But the direction is unambiguous, and it runs the wrong way for any platform whose story leans on “AI opportunities” it can't effectively stand up.
The Crossover Point
In some cases, the deferral is still the correct call.
Integration is a multi-year program with a real failure rate. Hold periods run four to six years. A sponsor who spends years two and three unifying ticketing systems or ERPs may well post a worse return than the one who simply does two more add-ons and lets the next owner inherit the disconnected plumbing, even after a slight discount at exit.
Some platforms genuinely should keep assembling and hand the integration bill down the chain. 10.5x on $100M in revenue is better than 12x on $80M in revenue.
But the arithmetic has a crossover point, and the crossover moves with how heavily the exit story leans on “AI opportunities.”
A platform whose CIM claims AI-enabled operations is claiming an integrated substrate, whether it states that clearly or not. Claiming that substrate is cheaper than building it, right up until diligence learns to check. And diligence is learning. The operator's job isn't to integrate everything. It's to know, explicitly and in advance, which side of the crossover the platform sits on, and to stop treating the answer as automatic.
Minimum Viable Integration
The logical conclusion of this is not "integrate everything." Integrating everything is how transformations die: the budget gets expanded every six months as the real work reveals itself, the project runs three years long, and the return goes with it.
The better move is usually narrower.
Pick the one substrate that AI-native logic prices highest, which in almost every services platform is the unified customer and service record, and integrate that spine deliberately, even while the operating systems underneath stay plural.
Assembly logic can keep running on top of a single source of truth; the two stop being in conflict the moment the data spine exists. One record, integrated on purpose, moves the platform from "nine companies sharing a P&L" toward "one company carrying nine histories." That is the difference between an AI initiative that inherits nine messes and one that stands on something. I believe it belongs in the value creation plan as a funded line, next to the add-ons, not underneath them.
Three questions for the platform
These are aimed at the structure, not at execution hygiene:
- How many of everything does your platform actually run: customer records, service catalogs, resolution histories? Not the org-chart answer. The systems answer.
- Does your current value creation plan carry both logics at once (bolt-on, AI)? Which line items assume assembly, which assume unification, and were the two funded as though they were compatible?
- If your exit story mentions AI, which buyer question does it not survive: "show me the substrate it runs on," or "show me what happens to it when the next add-on closes"?
So far, we’ve looked at the forces that shape a company over time: what becomes difficult to reverse, what compounds, what decays, what has to be made legible before intelligence can do useful work, and what customers punish you for. This week was about what happens when two rational strategies collide inside the same company.
These aren't five separate problems. I see them as stages of one climb, and solving them out of order can be costly and time-consuming. Next week I'll lay out my version of the map you can use to solve them in the correct order.