Every Portfolio Company Carries an Onboarding Tax. Most Operating Partners Never See the Bill.

Diligence measures the asset. Integration inherits the debt.

Technical diligence is good at pricing what's visible: code quality scores, test coverage, architecture diagrams, the state of the infrastructure. It is not built to price Cognitive Debt: the gap between what a system actually is and what the people now responsible for it understand it to be. That gap doesn't show up in a code scan. It shows up three weeks into integration, when the new technical lead asks why a core service was built around a specific vendor, or why two systems that should talk to each other don't, and the answer is a shrug.

Every operating partner I've talked to has lived some version of this. The diligence report said the codebase was sound. Sound and explainable are different claims, and only one of them gets tested before close.

I've watched this exact dynamic play out from the inside

I spent two decades inside a holding company advising agencies that got reconfigured constantly… new client, new scope, new team, sometimes a new reporting line, many times inheriting systems built by whoever was there before. Structurally, that's the same problem a portfolio company faces every time ownership changes hands or a new operating partner gets assigned: the org chart resets, the reporting lines reset, and the system underneath is expected to just keep explaining itself. It doesn't. Someone has to reconstruct the reasoning from scratch, and it's almost always the person least equipped to do it: the new hire, or the executive who just inherited a team they didn't build.

That reconstruction cost is the onboarding tax. It's real, it's payable in the highest-leverage weeks of the deal, and it's currently invoiced to nobody's budget.

The tax just went up

Add a layer that didn't exist three years ago. A growing share of the code moving through engineering teams now, including teams inside portfolio companies, is agent-written, and a visible slice of developer commentary right now is arguing you shouldn't bother reading it at all. Test the output, trust the pipeline, move on. Some teams have taken this to its endpoint: fully autonomous dark factory pipelines where agents plan, write, test, and ship code with no human reviewing the pull request at any stage.

I understand the appeal - a passing test suite feels like proof. But a test suite validates behavior, not intent. It tells you the code does what the tests checked for. It tells you nothing about why this approach was chosen over three others, what tradeoff was accepted to ship it, or what breaks if the requirement shifts six months from now. When a human wrote every line, that reasoning was recoverable even if it was never written down: you could still find the engineer and ask. When the code was generated by an agent, reviewed by another agent, and merged without a person in the loop, there's no one left to ask. Not even the model. It never externalized a rationale in the first place, and the version that wrote the code may not be the version running today, or even available to run any longer.

For a portfolio company, this compounds the integration timeline directly. The new technical leadership isn't just inheriting undocumented human decisions anymore. It's inheriting decisions that were never articulated by anyone, human or otherwise, at exactly the moment the deal needs that system explained fastest.

The obvious fix doesn't survive a live deal

The instinct is to add a step: more thorough technical diligence, a documentation requirement in the first 90 days, a mandate to slow down and review agent output before merge. Every one of these relies on someone taking one or more extra steps, under deal-timeline pressure, consistently, for months. That's the same bet that culture-based fixes always lose. It's not a diligence-checklist problem. It's an architecture problem: the rationale capture has to happen inside the workflow that's already running, or it doesn't survive contact with the next sprint, the next reporting deadline, the next thing that's actually being measured.

What this changes for operating partners

Two things I'd put in front of any operating partner managing a platform-heavy portfolio company right now:

• Treat decision-log completeness as a diligence line item, not an engineering nice-to-have. Ask what percentage of architectural and integration decisions in the target's codebase have a recorded rationale — not a code quality score, a rationale coverage number. It's a better predictor of first-100-days cost than almost anything else in a standard technical diligence packet.

• Treat agent-authored code as a distinct risk category, regardless of test coverage. If a meaningful share of a target's codebase was generated with limited or no human review, that's not a quality question — it's an unrecoverable-rationale question, and it should be underwritten differently than human-written legacy code, which at minimum has a person who could still explain it if you found them.

Neither of these requires slowing engineering down. Both require deciding, at the ownership level, that the reasoning behind a system is an asset worth pricing - before the invoice for not having it lands on someone's first 100 days.

Want to know what your portfolio company's onboarding tax actually looks like? I help operating partners size this before it shows up as a missed integration milestone. Start with the Enterprise Platform Blueprint.