How to scale AI across a private equity portfolio

The dependable way to scale AI across a private equity portfolio is to build one workflow properly inside one company, then separate what you built into a shared core and a company-specific layer. The core travels to the next company, and the layer is rebuilt there with the person who will own the work.

If you are an operating partner with one company where something is working, you already know how the next conversation goes. The board asks when the other five will have it. The second company turns out to run a different ERP, call its customers something else, and have nobody with a free afternoon. The demo from company one does not run on company two's documents, and the quarter ends with a pilot that is still a pilot.

What do the surveys say about how sponsors are scaling?

Most of the operating partners surveyed are past the pilot stage, and the largest single group is scaling without a playbook. Accordion and Wakefield Research surveyed 150 AI, data, and technology operating partners in May 2026. The largest group, 41%, described themselves as deploying AI across multiple companies with no operational playbook, against 22% still piloting, 21% systematizing, and 8% leading. On deployment approach, 47% reported a combination or tool-by-tool approach, 28% ERP-embedded AI, 14% dedicated point solutions, 7% implementation partner-led work, and 4% custom builds. A dedicated AI center of excellence was reported by 9%, and 63% reported informal guidance only.

One answer to this is to start with the platform, licensing one product for every company and letting adoption follow. The sponsors that Bain profiled took other routes. In its 2025 Global Private Equity Report, Bain describes Vista requiring each portfolio company to submit goals and quantified benefits from generative AI initiatives as part of annual planning, Apollo running a center of excellence whose workshops ask each company to identify three to five near-term use cases, and Hg relying on its companies sharing ideas with one another. Each of those is a way of organizing people and decisions, and the article describes none of them as a single mandated product.

What carries over between companies, and what never does?

The portable part of an AI build is the shape of the workflow. Everything that makes the output correct for one particular company stays behind.

Carries to the next company	Rebuilt at every company
The sequence of steps	The source documents and where they live
The review checkpoints and what a reviewer looks for	The chart of accounts, contract forms, and CRM fields
The output template	The company's vocabulary and naming conventions
The instructions that tell the AI how to do the job	The connections to that company's systems
The test cases, as a pattern	The person who owns the work, and their judgment about what good looks like

Take a monthly variance commentary as an illustrative example. The steps are the same anywhere: pull actuals against budget, flag the lines that moved past a threshold, draft an explanation for each, and route the draft to the controller. That sequence travels. The account mapping, the threshold the CFO cares about, and the phrasing the board is used to reading belong to one company only.

Bain makes a related point about Hg, where sharing ideas is easier because its companies tend to face the same problems, so a solution that works for one often works for another. The more alike two companies' work is, the larger the portable share.

Build it once, inside one company, against real work

A shared core written in the abstract tends to be a slide. The version worth carrying is one that a named person at a real company already runs every week, because weekly use is the best evidence that the steps and the review points are right.

So the first build should be done the slow way: inside the company, on its real invoices, contracts, or tickets, with the owner correcting drafts until they trust the output. We wrote separately about choosing that first workflow at a portfolio company and about designing the human review step, which is the part most worth carrying forward.

BCG's survey of 100 senior PE investors adds a caution for sponsors who bring in outside help for this. It found that 70% of successful firms tap specialized digital boutiques, while only 45% systematically ensure knowledge transfer from external partners to internal teams. If the method lives only in the partner's head, there is nothing to carry to company two.

How do you package the portable part?

Agent Skills give the shared core a physical form. Anthropic describes skills as organized folders of instructions, scripts, and resources that an agent can discover and load when a task calls for them, and compares building one to putting together an onboarding guide for a new hire. The same post notes that Agent Skills were published as an open standard for cross-platform portability in December 2025. Our plain guide to Claude skills covers the mechanics.

For a portfolio, the useful property is that a skill is a folder. It can sit in a Git repository, be reviewed line by line, and be copied into another company's environment. A practical way to organize each skill is in two parts:

• The core: the SKILL.md instructions, the step order, the review checklist, the blank output template, and any scripts that must behave identically everywhere.
• The company layer: a reference file per company holding its account mapping, field names, glossary, example outputs, and the rules its owner has added.

The core is maintained once. The layer is written fresh at each company and stays there.

Constraints the documentation states plainly

Three details from Anthropic's documentation affect how a sponsor plans this.

First, custom skills do not sync across surfaces. A skill uploaded to claude.ai is not available through the API, and Claude Code skills are separate from both. The same page describes sharing scope as individual on claude.ai, workspace-wide on the API, and personal or project-based in Claude Code. Sharing options change, so confirm what your plan allows with each company's administrator before planning distribution around it.

Second, Anthropic's enterprise guidance recommends keeping skill source files in Git as the single source of truth, pinning production skills to specific versions, and running the full evaluation suite before promoting a new version. It warns that if a version is not pinned, a new upload by anyone in the workspace immediately changes what production agents run.

Third, the same guidance says never to deploy skills from untrusted sources without a full audit and to treat installation with the same rigor as installing software on production systems. A skill passed from one portfolio company to another deserves that review too, and each company's own security lead should be the one to sign off on it.

The company-specific layer needs an owner before it needs anything else

At the second company, nearly all of the time goes into the layer: finding where the documents live, mapping the fields, collecting the vocabulary, and running the workflow on that company's own cases until the owner trusts it. The owner matters most. A workflow with nobody accountable for its output goes unused, whatever was installed.

This is also where training happens. The owner learns the workflow by correcting it on their own work, which is why we argue that training comes before tools at a portfolio company.

Who can change the shared core?

Someone at the sponsor has to own the library, and changes to the core should go through review. Anthropic's enterprise guidance recommends separation of duties, so that skill authors are not their own reviewers, and an internal registry that records each skill's purpose, owner, and version. It also advises starting with narrow, workflow-specific skills and consolidating into role-based bundles only when evaluations confirm equivalent performance.

A workable arrangement is small. One person at the sponsor approves changes to the core. Each company's owner can change their own layer freely and can propose a change to the core when they find something every company would benefit from. Improvements then flow back from the companies, which is the peer sharing Bain describes, with a record of who approved what.

Keeping each company's data and ownership separate

Portfolio companies are typically separate legal entities with their own customers, contracts, and confidentiality obligations. The shared library should therefore hold methods and templates only. Sample documents, customer names, and real figures belong in the company layer and should be checked for before any contribution to the core is accepted. What each company is permitted to share is a question for its own counsel or compliance lead.

Each company should also hold its own complete copy of what it runs, core included, in its own environment. A build that depends on a sponsor-hosted library is at risk on the day the company is sold. How rights to the shared core are documented, and what a buyer receives, are questions for deal counsel to settle before the library is shared.

Which company goes next, and what should the sponsor measure?

Choose the next company by similarity of work and by the presence of an owner. A company that runs the same kind of process as the first, and has a person who wants it, will reuse most of the core. A company with a different business model will reuse less, and it is better treated as a new first build.

On measurement, Accordion's survey found that 18% of operating partners are not yet measuring AI impact systematically. A sponsor can track a short list across the portfolio without much apparatus:

1. How many companies have the workflow running in real work, with a named owner.
2. How often it ran last month, taken from the work product itself.
3. How much of the core each company kept unchanged, which shows whether the core is really shared.
4. How many improvements were proposed back to the core, and how many were accepted.

Our article on measuring AI adoption without counting logins goes further on the second item. If you have one company working and want help separating the core from the layer, get in touch.

Common questions

Can the same AI workflow be reused across different portfolio companies?

Part of it can. The steps, the review checkpoints, the output template, and the instructions that tell the AI how to do the job usually carry over when two companies do similar work. The company's own documents, system fields, vocabulary, and the person who owns the work do not, and that layer has to be rebuilt each time.

Should a PE firm mandate one AI platform across the portfolio?

A common platform can simplify licensing and security review, but it does not decide whether a team uses the workflow. In Bain's profile of Vista, Apollo, and Hg, the three sponsors use a planning requirement, a center of excellence, and peer sharing, and the article describes none of them as mandating a single product. We would settle the method and the ownership first and let the platform follow.

Does a sponsor need an AI center of excellence?

It needs someone who owns the shared library and reviews changes to it, and that can be one or two people. In Accordion's May 2026 survey of 150 operating partners, 9% reported a dedicated AI center of excellence and 63% reported informal guidance only. A named owner with a review process covers the essential job at a smaller scale.

Who owns an AI build when a portfolio company is sold?

We recommend that each company hold its own complete copy of every skill and template it runs, installed in its own environment, so that the build keeps working when the company leaves the portfolio. Who holds the rights to the shared core is a legal question, and deal counsel should settle it in writing before the library is shared.

How do you keep one portfolio company's data out of another's tools?

Keep the shared library limited to methods, templates, and instructions, and review every contribution for company data before it is accepted. Each company runs its copy in its own AI workspace against its own files. Sample documents, customer names, and real figures stay in the company-specific layer and are never promoted to the shared core.