The Rollup Multiple Is Broken. AI Is the New Buy-and-Build Arbitrage.

Start with a worked example, because that is what an investment committee will ask for anyway.

Take a hypothetical industrial distributor: $80M revenue, 3% EBITDA margin, so $2.4M EBITDA. It's the third add-on in a regional rollup, acquired at 6x. Run it through an AI readiness assessment and the base-case scenario finds a 1.2% of revenue reduction in operating cost — not from cutting the warehouse crew, but from the coordination layer around them: order-exception handling, dispatch rescheduling, invoice matching, customer status updates, back-office reconciliation.

That 1.2% of revenue is $960K. On a $2.4M EBITDA base, it is a 40% increase in EBITDA. At a constant 6x exit multiple, it is roughly $5.8M of additional exit equity value from one add-on — before any multiple expansion for the platform being demonstrably more automated than its peers.

That is the shape of the opportunity. The rest of this piece is about why it exists, why it is specific to low-margin rollups, and how to underwrite it with numbers you can defend rather than numbers you were told.

The old arbitrage is compressing

The classic buy-and-build model created value through multiple arbitrage: buy add-ons at 5–6x, assemble scale, exit the platform at 9–11x. That spread has been narrowing for years — more PE capital chasing the same fragmented industries has bid up entry multiples on quality add-ons, and exit markets increasingly demand proof of operational integration, not just aggregated revenue.

When the entry/exit spread compresses, the only durable source of return left is operational: the platform has to be genuinely more profitable than the sum of its parts. Historically that meant procurement synergies, shared back office, and cross-sell — real, but well-understood and largely priced in.

There is a lever that is not yet priced in, and it lives disproportionately in the lowest-margin businesses.

Why the thinnest margins hold the biggest lever

Rollup targets are usually rollup targets because they are low-margin: distributors, field-service operators, staffing firms, logistics carriers, facilities managers. Commoditized service, no pricing power, labor-heavy cost structure. The market sets their price; cost is the only variable they control.

The arithmetic of thin margins cuts both ways. A 30%-margin software company that trims operating cost by one point of revenue improves earnings by about 3%. A 3%-margin distributor that does the same improves earnings by about 33%. Same operational work, an order of magnitude difference in earnings impact — and in a deal underwritten on an EBITDA multiple, that earnings impact converts directly into exit value.

Inside that cost structure, the most addressable target is not the frontline labor itself but the coordination work around it: scheduling, dispatching, approvals, exception handling, status chasing, reconciliation. In labor-heavy businesses this administrative layer is a meaningful, measurable share of the wage bill. It exists because human work is variable and someone has to route, check, and re-plan it — which is precisely the category of work that agent-based systems handle well, because it is high-volume, rule-adjacent, and lives in systems that already have APIs.

A methodology note, because our stats rule requires one: the 1.2%-of-revenue figure in the opening example is a modeled base-case output for a hypothetical company, not a client result. We are in beta and pre-revenue; we do not have fifty case studies, and we will not pretend to. What we can show you is the machinery that produces the number — and let you run it on your own target.

Why this compounds in a rollup (and doesn't in a single company)

Here is the part of the thesis that is specific to buy-and-build, and it is the reason we built MigrateForce around a portfolio rather than a single deployment.

Applied to one company, AI-driven coordination savings are a one-time margin reset. Applied across a rollup, the work of achieving them gets cheaper with every add-on, because add-ons in the same industry fail in the same ways:

• The evidence repeats. Management interviews at the third HVAC-services add-on surface the same workflow bottlenecks as the first two. Discovery that took weeks at portco #1 becomes validation at portco #5.
• The integration patterns repeat. The same handful of field-service, ERP, and dispatch systems appear across the industry. Once an interface to a system of record has been generated once, producing it for the next add-on is pattern reuse rather than a from-scratch build — the engineering cost is paid per system, not per company. Deploying and operating what's generated remains your team's work at each portco.
• The playbooks repeat. An intervention that worked — its preconditions, its approval gates, its measured outcome — becomes a documented, reusable pattern rather than institutional memory in one operating partner's head.

In our platform these accumulate as a Skills catalog: assessment evidence and executed migrations are distilled into structured, agent-consumable playbooks that the next engagement starts from. To be honest about the moat: this compounding requires cycles of real portfolio data to fully materialize — it is a trajectory we are building toward, not an asset we can hand you today. But the direction of the curve is the point. Traditional integration cost is roughly linear in the number of add-ons. Pattern-based integration cost bends downward, and in a 10–15 add-on rollup, the difference between those two curves is a material fraction of the deal's operational alpha.

The adoption objection — and why the architecture answers it

The standard objection is the right one: these are exactly the workforces least likely to adopt new software. A dispatcher with twenty years of tenure is not going to open a new AI tool, and a rollout that depends on them doing so will fail quietly over six months.

So don't depend on it. The deployments that work put agents behind the existing workflow rather than in front of the employee: if payables run through the ERP, email, and PDFs, the agent runs across the ERP, email, and PDFs — extracting, matching, flagging exceptions, and pulling a human in only where judgment is required. The employee's experience is that a category of work stopped arriving, not that a tool appeared.

Two things have to be true for a PE owner to sign off on that, and they are design requirements, not features:

1. Governance before autonomy. Migration runs retain status, messages, and tool activity, and qualifying execution work can stop for an explicit approval decision. Active runs cannot currently be paused and resumed. Deployment responsibility depends on the supported migration path and the approved plan; do not infer that every system or action is covered by the same control.
2. The systems of record stay in charge. The billing, ERP, CRM, and compliance systems each portfolio company already runs continue to own the transactions of record. The orchestration layer generates governed interfaces into those systems — it does not replace them, and financial outputs from scenario models are decision support for underwriting, not accounting.

How to underwrite it: mechanism, not adjectives

If a number cannot survive an IC memo, it should not be in the deck. This is how we compute the ones above.

The assessment engine scores a target across six readiness dimensions using eight deterministic scoring engines — deterministic meaning the same inputs always produce the same scores, so the methodology can be audited line by line rather than taken on faith. Industry context comes from a library of 20 industries and 78 segments, each with typical tech stacks and workflow patterns. Discovery evidence comes from structured management interviews — either self-serve with an executive or consultant-configured across departments — with per-dimension confidence scoring, so the model tells you how much to trust each input, not just what it concluded.

The financial output is three scenarios — conservative, base, aggressive — built on DCF cash flows with IRR solved via Newton-Raphson and adoption modeled as an S-curve rather than an instant step, because no deployment captures full value on day one. Every scenario shows its assumptions — and its simplifications: the modeled series is acquisition price out, ramped net savings in, exit value in. Year-one integration spend is not a modeled line item yet, so carry it in your own fund model. If you disagree with an adoption ramp or a cost baseline, change it and re-run.

That is the honest version of this thesis: not "AI transformed our clients' margins" — we cannot claim that yet — but "here is an auditable machine for estimating what it would do to yours, and a governed pipeline that carries an approved plan to generated, inspectable code your team deploys — then measures projected versus actual."

The screening heuristic

For operating partners evaluating where this applies in an existing portfolio or an active thesis, the profile is consistent:

• EBITDA margin under ~10% — the arithmetic leverage lives here
• Labor cost above ~20% of revenue, with visible supervisory and back-office headcount around the frontline work
• Commoditized service — cost reduction banks as margin instead of leaking into price, at least until competitors catch up, which is exactly the early-mover window
• Fragmented industry with repeatable operations — the precondition for pattern reuse across add-ons
• Aging systems with APIs — the raw material for generated, governed integrations

Multiple arbitrage rewarded whoever could buy cheapest. This rewards whoever can integrate cheapest, prove it with audited numbers, and repeat it across ten companies. Different game — and it favors preparation over auction discipline.

---

Run a free AI readiness assessment on one target. MigrateForce is free for teams evaluating the beta. The scenario outputs are decision support with visible assumptions; bring them to your IC and stress-test those assumptions.