The Inverse Pyramid Diagnostic

Walk into a startup, a marketing agency, or the innovation lab of a large bank. Three different worlds. Ask each one what they are working on and you will get three answers that have nothing in common.

On the surface, that is true. And it is true across the whole market, not just those three rooms. Thousands of companies are building right now, each one solving a problem the others have never had to think about. A few of them are rivals. Most are not even in the same world. They have different customers, different rules, different words for what they do. They look like isolated dots scattered across a very large network, with nothing joining them together.

Now strip away the surface and look at the technology underneath. The shape changes. It is not a tree branching out into independence. It is a pyramid standing on its point. It gets narrower as you go down. The startup, the agency, and the bank are not only connected to their own rivals. They are also connected to each other. All three funnel down into the same small set of providers at the bottom: OpenAI, Anthropic, Google, a few others like them, and the handful of cloud firms that host them. Three companies that will never meet in a market are often talking to the same model.

That is the Inverse Pyramid. A normal pyramid is wide at the base. This one is wide at the top and thin at the bottom, because the number of companies is large and the number of things they all sit on is small.

Shared fate

If a mid-sized software company disappears tomorrow, the market barely notices. If a foundational provider changes its prices, tightens its rate limits, or ships a model that reasons much better, then thousands of companies across completely different industries feel it on the same day.

That is what shared fate means. Not that everyone is hurt in the same way, or by the same amount. A price rise might be a rounding error for the bank and the end of the road for a small startup. A better model might do for free what one company charges for, while giving another company a product it could not build before. The sizes are different. The direction is different. But the event is the same event, and nobody gets to sit it out. When the bottom of the pyramid moves, everything standing on it moves too.

Borrowed brilliance

When a better model ships, hundreds of products might get smarter overnight, and eventually that shows up in growth, retention and revenue. But those companies did not get better. Their supplier got better.

I call it borrowed brilliance. Borrowed, because the company never owned the thing that made it smarter. It rented it. The intelligence sits at the bottom of the pyramid, not inside the product, and it can be repriced, restricted, or handed to a competitor on the same afternoon.

The Inverse Pyramid explains the shape. The next question is what to do with it.

The diagnostic starts from one simple idea. If the foundation underneath you got better and you did not, then something inside your own company ate the improvement.

Finding that something takes three steps.

Step 1: Find the trigger

A trigger is a specific change at the bottom of the pyramid.

Kind	Example
Good	Your provider ships a model that reasons 40% better at the same price
Bad	Your provider doubles what it charges per million tokens
Neutral	Your provider retires an older model

Step 2: Measure the gap

Say the foundation got 40% better at reasoning. Company A’s product got 40% better at the tasks its users care about. Company B managed 5%. Company C did not move at all. The distance between what the foundation handed out and what each company actually delivered is the gap.

Step 3: Run the absorption audit

For every company that did not capture the full trigger, the question is not whether the foundation improved. We already know it did. The question is much narrower.

An absorber is anything that eats an improvement before it reaches the customer. Five of them show up often enough that you should check for them every time.

Picture the improvement travelling up from the foundation towards your customer. Each absorber is a tap on the side of the pipe.

Wrong tool for the job

Some tasks are simple enough that a big model and a mid-size model give you the same answer. Copying numbers out of a form, for example, or sorting messages into three buckets. Both models do the job fine, so a better model has nothing left to improve. When the big model gets smarter, the task runs exactly as it did before. The only thing that goes up is the bill. The absorber here is the mismatch between the model and the task, which left no room for the improvement to land.

Broken plumbing

Is the system feeding the model actually working? The model may have got much sharper. But if your search is handing it the wrong documents, or your cache is broken, or your code leaks memory, the model never gets a fair shot. The absorber here is the infrastructure around the model, which spoils the input before the model ever works on it.

The wrong skill improved

Did the upgrade improve something your work depends on? If the new model is better at mathematics and your team uses it to write brand copy, the upgrade is not for you. The absorber here is the mismatch between what improved and what you use, so nothing arrives even though something genuinely got better.

Nobody notices

Was the old version already good enough? Going from 95% accuracy to 99.9% is real engineering. But if no customer can tell the difference, then the market absorbed the improvement through apathy. On their side, nothing changes. No jump in usage. No rise in renewals. Everything stays exactly where it was.

Too much red tape

Are people or process blocking the output?

The customer never waits on the model. They wait on everything between the model and them. A support reply the model writes in seconds still waits for a human to check it. A claim decision it reaches instantly still waits for someone to sign off. A marketing page it drafts in minutes still waits for legal and brand. In every case the model got faster and the queue behind it did not.

Take the engineering version. The model writes a fix in ten minutes instead of a day. It still waits for review, and then it waits for Thursday, because Thursday is when you ship. The customer gets it on Thursday, exactly as they always did. From where they stand, nothing happened at all.

People do the same thing more quietly. If staff are measured on hours logged rather than work finished, a tool that saves four hours makes their numbers look worse, so they stop using it or fill the saved time with something else. Either way the work leaves the building on the same schedule it always did. The absorber here is the workflow and the people inside it, neither of which changed when the model did.

This list is not the whole list. Your own data, your testing setup, your integrations and your customers’ own processes can all absorb improvements too. These five are where to start looking, not where to stop.

A company buys the best AI tool on the market. Six months later the executives are angry. We bought the most capable thing available, so why did nothing happen?

The framework does not argue about the tool. It runs the audit, one absorber at a time.

• Are people using a frontier reasoning model to pull invoice numbers out of PDFs, when a small extraction script would give the same result?
• Does the internal system time out, or hand the model the wrong file?
• Did this particular upgrade improve something the company’s daily work depends on?
• Was the old output already passing review without changes?
• Do managers require five rounds of approval on anything the system drafts?

Not one of those questions is about the model. Every one of them is about the company. And when the audit is run, two or three usually come back yes.

The conversation changes. It moves from “AI is overhyped” to “our approval process is the bottleneck.” The argument was never really about the technology. It was about which part of the company was swallowing it.

Most companies compare themselves to rivals by looking at what those rivals shipped. Better product, faster releases, features you do not have. The usual conclusion is that they found something you did not.

The pyramid makes that harder to believe. If you and your competitor sit on the same provider, the foundation moved the same amount for both of you. It was the same models, the same prices, the same release dates. Whatever they got, you were handed too.

So when they ship something you cannot match, there are only two explanations. They are using a different foundation, which is usually not hard to find out. Or they are getting more of the same foundation through to their customers than you are.

That second answer is the useful one, because you can do something about it. You cannot buy a better foundation than the one your rival is using. You can find out which of your absorbers is bigger than theirs.

For decades, business intelligence has looked inward. Supply chains, sales, finance, headcount. It measures what a company does.

When everyone sits on the same few foundations, that is only half the picture. The other half is what a company leans on, and how much trouble it is in when that thing moves.

Call the second one dependency intelligence. It maps the pyramid underneath a company and works out how exposed that company is when a trigger fires.

This is not a new idea. Financial regulators have been building it for years, under the name concentration risk. The Financial Stability Board has flagged that relying on a small set of cloud services and pre-trained models creates third-party dependencies in a market that is already highly concentrated. The Bank of England has made provider concentration a main line of work. The IMF has asked central banks to map these dependencies across the whole system and plan for outages that hit everyone at once.

But all of that is pointed at one question: will the financial system hold up? Nobody is pointing it at the ordinary company that just wants to know why its upgrade did nothing.

Two things follow from taking the inverse pyramid seriously.

The first is about how we keep score. Right now we praise companies that plugged into the right provider at the right moment, and we file that under innovation. Telling borrowed brilliance apart from earned brilliance is the first step to judging anything fairly.

The second is bigger. Almost every company is waiting for the next model. Better reasoning, longer context, cheaper tokens. But if the gain that already arrived is being eaten by wrong tools, broken plumbing and red tape, then a better model does not fix anything. It just gives the absorbers more to eat.