The hidden capability gap in your AI stack
A product plan can look stable while its core assumptions are moving underneath it. The dangerous assumption is not that the model is good enough today. It is that access, price, and capability will keep moving in your favor.
One reason is the growing possibility that the best systems inside a lab are not the ones a team can buy. Ethan Mollick argues that the gap between internal models and released models may widen because labs have safety reasons to hold models back and research reasons to keep stronger systems for themselves, as Mollick wrote. He also argues that if that gap grows, it may become tempting for OpenAI and Anthropic to enter markets directly, especially finance and biotech, as the same post notes.
That does not mean a lab will enter your market next. It means dependency review becomes a human planning task before that question is even settled. If your roadmap assumes one provider will keep offering the right model at the right price and with the right availability, then part of your product strategy is already outside your control.
The pricing side is not theoretical. The Information, via Techmeme, reported that Replit shifted most of its AI spending from Anthropic to OpenAI after OpenAI offered a discount of more than 30 percent and Anthropic ended its discount, according to Techmeme’s report link. A stack that looked sensible under one commercial arrangement can look different under another.
Capacity is another moving part. Andy Jassy said AWS capacity for 2027 is largely sold out and that a good chunk of 2028 capacity is also sold, according to Techmeme’s report on his remarks. Even if your chosen model stays available in principle, the surrounding infrastructure can still tighten. In practice, that can change latency, access, cost, and what commitments are realistic.
The loss here is not abstract. When nobody owns these dependencies, authorship of the plan drifts away from the team that must answer for it. The roadmap starts to reflect a provider’s release choices, discount choices, and capacity constraints more than the company’s own decisions.
Who owns the decision?
A prepared team still controls one important thing: it can name its dependencies before strategy hardens around them. That work is mundane, but it is the part that remains decisively human. Someone has to notice where the business has quietly promised customers that one external model will stay available, affordable, and good enough.
Map dependencies this week
Start with an inventory, not a forecast. List every workflow, feature, or customer promise that depends on one provider. For each one, note which assumption is carrying the plan:
- access to a specific model or API
- a price level that makes the unit economics work
- a quality threshold that keeps the feature credible
- enough capacity to serve peak demand
Then add one fallback for each dependency. The fallback can be another provider, a smaller scope, a human review step, a delayed feature, or a version of the workflow that does less but remains reliable. The point is to stop treating favorable conditions as if they will continue unchanged.
This is not a prediction exercise. It is a boundary-setting exercise. You cannot control what labs release, what they keep internal, what they discount, or where they deploy their own capabilities. You can still decide where your product plans rely on those choices and where they need alternatives.
If the internal-versus-public gap grows, if provider pricing moves, or if capacity tightens, the teams that fare better will usually be the ones that already know which promises are exposed. Dependency mapping is how you keep the decision seat inside the company, even when the underlying model market does not sit still.
This week, map every workflow or product promise that assumes one model provider will stay available, affordable, and good enough, and note at least one fallback for each.
Human Runtime Core™ is designed for the mental edge you need to survive in an AI-run world.