Choosing an AI partner for your portfolio

In the first week of May, the market for putting AI to work inside private equity portfolios changed shape. OpenAI launched the OpenAI Deployment Company with more than 4 billion dollars of initial investment from 19 firms, led by TPG with Advent, Bain Capital and Brookfield, valued at 10 billion dollars and majority-owned by OpenAI. It embeds forward-deployed engineers inside organizations to redesign workflows around AI. The same week, Anthropic announced a venture with Blackstone, Hellman & Friedman and Goldman Sachs, valued at 1.5 billion dollars and backed by a consortium that includes General Atlantic, Leonard Green, Apollo, GIC and Sequoia. It launched in July as Ode, embedding engineers in mid-sized companies and drawing its first customers from the consortium's portfolios.

They joined a field that was already crowded: strategy consultancies with AI practices, systems integrators, platform companies that bring their own engineering teams, and the funds that have built large capabilities in-house. An operating partner choosing how to deploy AI across a portfolio now has more options than at any point in the last three years, and they are more different from one another than their marketing suggests.

This is a guide to telling them apart. We are one of the options, and we say so below, but the questions are the ones we would want asked of us.

Five kinds of partner

Lab-owned deployment firms. The two new ventures above. Their strength is depth: engineers who know one lab's models and roadmap intimately, and early access to what that lab ships next. They are built to deploy their parent's models, which is a fact of ownership rather than a criticism.

Strategy consultancies. Strong at framing the opportunity for a board, prioritizing across a portfolio and managing change. The traditional deliverable is a plan, with implementation priced separately or handed to someone else, although several now build as well.

Systems integrators. Strong at large integration work across ERP, CRM and data platforms, and at staffing big programs. Typically engaged by project, with the capability living in the integrator's people.

Platform-plus-team partners. A platform the company keeps, with a team that builds and deploys on it and then hands it over. This is where Fig sits.

Building in-house. The route the largest AI-forward funds have taken. Hg's value creation team of more than a hundred AI specialists is the clearest example of it working at scale. It requires a commitment most funds cannot make, but where it is made it compounds.

Question one: whose models, and can that change?

A private equity hold now averages about seven years. In AI, seven years is several generations of models, and the order of the frontier changes far faster than that. As of this summer, the lab leading on coding benchmarks was not the one leading on scientific reasoning, and neither led on computer use. Prices move just as quickly: one index of frontier model prices was about 84 percent below its March 2023 level by September.

For a portfolio company, the model is a critical input, and a seven-year commitment to a single source for a critical input is a concentration risk. No investment committee would accept it for a key raw material or a sole manufacturing partner without a plan to switch. The same logic applies here, for three reasons.

Quality. Different work is done best by different models, and which one is best changes. A company that can only use one will be using the second-best model for much of its work much of the time.

Cost. AI products and workflows carry an inference cost on every unit. A company that cannot move has handed its gross margin to one provider's price list.

Continuity. Models are retired. A system built tightly around one model's behavior has to be rebuilt when that model goes away.

The question to ask any partner is concrete: could the systems you build for us run on a different lab's model next quarter without being rebuilt? We built Model Hub and auto routing because we think the answer should be yes, and because routing each task to the model that does it best is itself a source of quality and margin. We have made the fuller case in should I train my own model.

Question two: who owns what gets built?

An AI deployment produces more than software. It produces definitions of the company's core objects, the rules and exceptions its people apply, the precedent behind past decisions, evaluation sets that prove the system works, integrations, and the prompts and skills that encode how the work is done. Together these are the company's proprietary layer, and at exit they are what the buyer inherits.

If that layer lives inside a partner's proprietary environment, the company does not own an asset; it holds a contract. A buyer will price the difference. The terms to ask for are specific:

• Ownership of what is built on the company's data, including rules, evaluations and integrations, assigned to the company.
• Data portability in standard formats, within a defined period, on termination.
• Notice before a model is retired, with support for migration.
• Exit assistance: a defined obligation to help transition to another provider.
• No termination on change of control, so the capability survives the sale it was built to support.

The principle behind these terms is the one we set out in the sovereign AI operating playbook: the company should be able to leave, with everything it built, in a form that works somewhere else. It is also why we treat the company's ontology as its asset rather than ours, as described in what an ontology is for.

Question three: who runs it after the engineers leave?

Talent is the largest constraint on scaling AI in portfolios; in FTI's 2026 survey it was cited by 35 percent of fund and operating leaders, ahead of budget and technology. Embedded engineers solve that problem for the length of the engagement. The question is what happens after.

Ask how the engagement ends. The answer should include a named owner inside the company, a trained team that can change rules and handle exceptions without an engineer, and a monthly record of quality, cost and volume that the owner reviews. If the honest answer is that the partner's engineers stay indefinitely, that is a staffing model, and it should be priced and evaluated as one. We have written at length about what forward-deployed work should leave behind in what forward deployed means.

Question four: how do the incentives line up?

Every partner has incentives; the useful exercise is to lay them out.

For the partner. Is the fee tied to hours, to deliverables or to measured outcomes? Does the partner earn more when the company uses more of a particular model or product? Neither is disqualifying, but both should be visible to the company's board.

For the sponsor. This one is newer. When a fund is an investor in a deployment venture and also the owner of the companies that venture sells to, the arrangement raises questions portfolio company boards now need to consider. A Foley & Lardner analysis published in May identified several. The tools these ventures deploy can compress the pricing and addressable market of the same sponsors' own software holdings. Sales from a sponsor-affiliated venture to its portfolio companies are related-party transactions; under Delaware's SB 21, the safe harbor for such transactions depends on approval by independent directors or a majority of minority holders. Antitrust regulators are looking more closely at overlapping holdings and board service, and revised merger-notification rules require more disclosure of them. Press reports that OpenAI guaranteed its venture's backers a fixed annual return add a further term for boards to understand.

None of this means a sponsor-affiliated partner is the wrong choice. It means the choice should be made the way any related-party decision is made: by people without the conflict, on terms they would accept from an unrelated provider, with the minority holders and the eventual buyer in mind.

Where Fig fits, and where it does not

We are a platform-plus-team partner. The company keeps the platform and the layer built on it: its objects, rules, precedent and evaluations. Work is routed across models from several labs, and when post-training a smaller model on the company's own data pays, we do that too. Our engineers build alongside the company's people and hand over running software, a trained team and numbers the company can audit, which is how our transformation engagements are designed to end.

That is not the right fit for everyone. A company that has decided to standardize on one lab for the long term will get real depth from that lab's own deployment firm. A company that needs a board-level strategy across a dozen business lines before anything is built may want a strategy firm first. A fund prepared to build a large in-house team can do what Hg has done. The mistake is not choosing any of these. It is choosing without asking the four questions, and signing terms that decide the answers by default.

Key takeaways

• The market now includes lab-owned deployment firms, consultancies, integrators, platform partners and in-house teams. They differ more than their positioning suggests.
• Over a seven-year hold, single-lab dependence is a concentration risk on quality, cost and continuity. Ask whether the system can move to another model without a rebuild.
• What gets built on a company's data is its exit asset. Secure ownership, portability, model-retirement notice, exit assistance and survival through a change of control in the contract.
• Ask how every engagement ends: a named owner, a trained team and a monthly record, or a permanent dependency.
• Where a sponsor has invested in the partner it recommends, treat the decision as a related-party decision, made by people without the conflict.

The partner a company chooses matters less than whether it can still change its mind in year five.