A keystone is the central stone at the top of an arch. It is the last stone set, and it is the one that locks every other stone in place. Take it away and the arch does not weaken slowly or sag at the edges. It collapses. Every other stone was depending on it.
I have come to think this is the most useful way to describe what an operating model actually rests on. The human is the keystone. People are the element the whole structure depends on, and the operating model is the arch built around them. AI is what gives that arch its reach, allowing it to span further and carry more than it could before. A continuously adaptive design is what lets the arch flex as the load changes, rather than cracking the first time conditions shift.
Thanks for reading The Operating Model Dispatch! Subscribe for free to receive new posts and support my work.
I have started calling this the Keystone Framework, and it is the approach to operating model design I now bring to organisations adopting AI.
Regular readers will recognise the foundations of it. I have argued here before that the operating models worth building now are human-centric and AI-enabled, designed around people with AI applied in service of them rather than the other way around. The Keystone Framework is the structured form of that argument. It rests on three principles. The operating model should be human-centric, placing people at the centre of where organisational value actually comes from. It should be AI-enabled, applying AI deliberately to amplify what people can do and to solve structural problems that were previously too costly or too hard to fix. And it should be continuously adaptive, built to keep changing as technology and markets change, without requiring a fresh transformation programme every time.
So far this could be read as three sensible design values listed side by side. That reading would miss the entire point.
The central claim of the framework is that these three principles only work as a system. They interlock. Each one depends on the others, and each one protects the others. Adopt one or two without the third and the model does not simply underperform. It fails, and it fails in a way you can predict in advance.
Consider what happens when you take them apart.
An operating model that is AI-enabled but not human-centric collapses back into something else entirely: AI-first design, where the technology sits at the centre and people are arranged around it as users, risks, and costs to be reduced. Once people are no longer the point, there is no principled reason to stop automating. The model optimises for how much human activity it can remove, mistakes the cost it strips out for value it has created, and quietly destroys the judgement, relationships, and undocumented knowledge that were the actual source of the organisation’s worth. The discipline of applying AI deliberately rather than maximally only holds if people remain the reason you are doing any of it.
An operating model that is human-centric but not AI-enabled has the opposite problem. The commitment to people is real, but it has no mechanism behind it. Wanting people to do their best, most valuable work is an aspiration until something actually removes the low-value work that fills their days and frees the capacity for it. AI-enablement is what turns the human-centric intent into something an organisation can deliver rather than merely state.
An operating model that is human-centric and AI-enabled but not continuously adaptive cannot survive the pace of change it now faces. There is no stable business-as-usual to design towards and settle into, because the conditions keep moving. A model built for a single moment, however well, starts ageing the day it goes live. Continuous adaptability is also the principle that keeps the organisation’s options open, and that matters more than it first appears. Committing fully to one fixed configuration is a bet that you already know where AI is going. Nobody knows that. If the bet is right, you save some cost. If it is wrong, and you need human capability back, rebuilding it is slow and expensive, and a number of organisations are already discovering exactly how hard that is to reverse. The downside is far larger than the upside, and the principle that preserves optionality is what protects you from it.
Running underneath all three is a single question I keep returning to: how can AI enable this person, this role, this team to do better work, more of it, and to contribute to their fullest potential? An operating model designed around that question produces something maximal automation never can, which is people doing better work in an organisation that is stronger for it rather than hollowed out. Fixing the structure and enabling the people stop being competing uses of AI. Done well, they are the same use.
This is why the three hold together. Each principle answers a failure that the other two cannot. Put them together and they reinforce each other into something more durable than any of them alone. That is what makes Keystone a framework rather than a list of good intentions.
There is one more thing the metaphor makes clear, and it is the reason I never start with design.
A design framework follows diagnosis. You cannot redesign a foundation you have never seen. With AI in the picture the stakes of that are higher than they used to be, because AI applied to an operating model nobody has properly examined cannot tell a load-bearing element from a removable cost. The relationships, the judgement, and the knowledge that hold an organisation together rarely show up on an org chart or a process map. From a distance they look like overhead, which is to say they look exactly like the work AI was brought in to remove. Diagnosis is how an organisation finds its keystone before it designs around it, and before it automates away the very thing the structure depends on.
That is the work the framework is built to do. Over the coming issues I will take each of the three principles in turn and set out what it asks of an operating model in practice. If you want to understand where your own model stands before any of this becomes a design question, drop me a note here or at sarah@sheffronadvisory.com.