Why AI programs at PE portfolio companies stall at the same organizational seam, and what to do about it.
Blake Aber · Predicate Ventures · 2026
There's a failure mode I've watched play out at enough portfolio companies that I've given it a name: the ownership dyad.
It goes like this. The AI program is running. The product manager owns the roadmap (what the AI should do). Engineering owns the deployment (how it does it). Both parties are competent. Both are aligned on the goal. And the AI initiative quietly stalls anyway, usually somewhere between the promising pilot and the production system that was supposed to follow.
The mechanism is diffuse accountability at the decision layer.
What the dyad looks like in practice
In the average portco planning meeting, the PM and the engineering lead sit across from each other. The PM has a change request: "The model is producing summaries that miss the key clause in contracts above a certain length. We should fix this."
Engineering hears this and wants to know: is this a prompt change or a model change? Either requires scoping, and scoping requires the PM's input on acceptable behavior. So engineering asks the PM. The PM says "whatever's best technically." Engineering ships a prompt change. The next month, the same issue appears in a different context. The PM brings it back.
Neither person is wrong. Neither person is slacking. The problem is structural: there's no single person who can describe (precisely and completely) what the AI should produce, evaluate whether it's producing it correctly, and approve a change to the system without requiring the other party's sign-off.
The dyad looks like shared ownership. It functions as diffuse accountability. No one is in charge of the model's behavior.
The failure mode at month nine
Most portco AI programs that make it through a successful pilot still die quietly around month nine of production. The most common reason is not that the model got worse. It's that the harness around the model was never properly built: the observability, the eval layer, the rollback mechanism, the silent-failure detection.
The ownership dyad is the organizational reason the harness doesn't get built. Harness work requires someone who understands both the technical requirements (what needs to be monitored) and the business requirements (what "correctly functioning" means). In a dyad, that's a consensus decision. Consensus decisions take time. Harness work gets deprioritized.
By month nine, the model's input distribution has shifted. No one is monitoring it systematically. An edge case emerges. The AI program goes into a steering committee meeting as a cautionary tale.
What right looks like
The fix is not a committee. It's a single named person who can:
- Write a specification for what the AI should produce without referencing the technical implementation
- Evaluate model output against that specification without asking engineering
- Approve or reject a change to the model's behavior without a sign-off cycle
At a portco with 30-150 employees, this is usually a domain expert who has been trained on what the AI is doing. Not a technical founder or an ML engineer. This is the same reason handing the AI program to a junior IC engineer fails: building the model and owning its behavior in the org are different jobs. Often the owner is a senior analyst, an experienced operations manager, or a director-level individual who owns the workflow the AI is embedded in.
They don't need to understand the model. They need to understand the output.
One sentence: name one person who can approve a model behavior change without committee sign-off. That person is your AI product owner.
At the portcos I've worked with, the single clearest predictor of whether an AI program makes it from pilot to production isn't the quality of the model. It's whether that person exists. It's also a pattern a GP team learns to spot only after building AI internally before pushing it to the portfolio, where the same accountability gap shows up in their own workflows first.
