An organisation can put “the customer comes first” in every strategy document and still leave a customer waiting because nobody knows what that promise permits them to do.
Someone eventually makes it concrete. They interpret the situation, connect the right people, find an option and take responsibility for it. For a moment, the company’s intention becomes action. The next case may require someone to do that work all over again.
Much of my writing has followed this gap between what we understand and what we can make happen. In The Crystallization Engine, I explored how insight gains reach when it becomes something others can use repeatedly. In Enterprise Architecture Becomes the Compiler, that question moved to the organisation: how can its knowledge of itself shape the work while it happens?
Follow that thought one step further. What if the company could operate through its understanding of the business? Its definitions would help determine which actions exist. Its policies would shape which routes are possible. Its goals would guide the work assembled from them. This is the business model I mean here: the company’s explicit account of what matters, what is possible and what it is prepared to commit to.
The organisation’s knowledge would start doing work.
Consider a hypothetical insurer trying to resolve claims more quickly. It already holds information about customers, coverage, evidence, payments and responsibilities. Much of the practical meaning sits between those records: which evidence is sufficient for this claim, what an unresolved discrepancy prevents, who may authorise the next commitment.
An operational ontology brings business concepts and relationships together with the actions that can change them. A claim is connected to its customer and coverage, but also to operations such as requesting evidence, seeking a decision or arranging a permitted payment. Each operation has conditions and consequences.
This connection already has concrete implementations. Palantir’s action types associate operations with changes to business objects and their relationships. A small open-source reference implementation demonstrates shared action rules, recorded attempts and updates to source systems. It is an educational implementation with explicit limits, including no authentication.
The larger possibility is what intelligence could do through such a model. Given a goal, an agent could inspect the case, identify missing evidence, request it and reconsider the next step when it arrives. A discrepancy might create a task for a specialist. A resolved question might make a payment eligible. The route develops with the situation. The distinction between a prescribed workflow and an agent selecting its next steps is well established in agent architecture.
To make that useful across a company, the rules governing the work have to travel with it.
Everything that is supposed to govern delegated work has to enter its executable operating model: policies, objectives, obligations, authority, exceptions and evidence requirements. Each needs a defined consequence in the work, including when the system must hand a judgment to a person. Leaving it only in a document leaves someone to bridge the gap at the moment it matters.
An exact payment limit becomes a check in code. A requirement to investigate conflicting evidence becomes an obligation the system can recognise, assign and follow through. A policy requiring contextual judgment becomes criteria that an agent can apply within a defined remit. Where that judgment remains uncertain or belongs to a person, execution must reach the right person and wait for the decision.
An objective needs this translation too. “Resolve claims quickly” might guide an agent to choose the earliest feasible next step while preserving required evidence and review. The business must decide how to resolve a conflict between speed and another commitment; the agent needs that priority or a route to someone who can decide.
That is how an organisation becomes executable to different degrees. Deterministic code carries what must be exact. Agents interpret and organise work where the route depends on context. People decide where authority, uncertainty or competing commitments require them. The architecture has to make those contributions work together.
The distinction matters most when a decision takes effect. An agent may interpret evidence and propose a payment; the service making the payment must enforce the applicable limits and authority against the current case. Policy engines such as Open Policy Agent already separate policy decisions from their enforcement. Reading a policy and being subject to it are different capabilities.
This is the sense in which data becomes the program. Structured business knowledge begins to carry more of the organisation’s operating logic. Definitions, conditions, goals and available operations become material that intelligence can interpret to construct action. Code still implements the operations and enforces the boundaries. More of what the company does can be shaped by changing the maintained business model those components use.
That change reaches beyond individual automation. A claims agent, a specialist and a payment service can contribute to the same evolving case. One result changes what another participant can do. My Enterprise Agentic Mesh work explores that coordination across agents, conventional software and people. Shared meanings and dependable handoffs let a capability developed in one part of the company become usable elsewhere.
The organisation begins to resemble an organism: its parts respond through a connected account of the whole. The model is something like organisational DNA, carrying maintained instructions that shape behaviour across many activities. The analogy concerns coordination, not consciousness.
Imagine what that could preserve. A useful piece of judgment no longer has to disappear when the meeting ends. Once understood, tested and incorporated, it becomes available to the next case and the next team. Someone else’s insight becomes part of what the organisation knows how to do.
That is an extraordinary prospect. It is also where the difficulty begins.
The model contains our accumulated understanding, including the assumptions we have stopped noticing. What counts as a successful claim? Which delay deserves attention? Which customer need becomes a field, an objective or a permitted action? Those choices influence what the system looks for and how it responds.
An organisation that executes its knowledge more effectively can also give its assumptions more reach.
Return to our insurer. Suppose its agents remove unnecessary handoffs and help people reach decisions sooner. Processing time falls in this imagined case. The investment is doing what it was meant to do.
Yet customers keep calling.
A claims handler notices something in the conversations. People want to know whether anyone has taken responsibility, what happens next and when they will hear again. Perhaps part of their distress comes from being unable to picture the next few days. Faster processing helps, but it may leave that experience largely untouched.
This is where Rory Sutherland’s work becomes useful. In his conversation about Alchemy, he describes how seeing a car approach changes the experience of waiting for it. Time and uncertainty are different dimensions of an experience. His argument invites us to examine which dimension our chosen problem definition has left out.
The insurance application is our hypothesis. We would have to test it. But notice what has already happened: an observation has changed what a better service might mean.
The company could organise around helping a customer regain a sense of control during a disruption. That might involve a clear explanation, a dependable next update or help arranging an immediate practical response while the claim is assessed. A process previously understood as moving a file towards closure begins to look like part of helping someone recover their footing.
That is a larger imaginative move than improving the claims queue. It asks what the insurer is really there to make possible for the customer.
Now someone has to act before the answer is settled.
They may need to redirect people, spend money and accept that a promising idea could fail. A clearer update might help. It might add noise. Some customers may want a conversation; others may find it intrusive. Good intentions provide a reason to investigate, not a result to announce.
This is where risk-taking enters. An observation becomes an organisational possibility when someone is prepared to put resources and credibility behind finding out whether it matters. A company cannot require every new idea to prove its value entirely through the assumptions that the idea is trying to change. If our proposal must first demonstrate that it shortens processing time, we may never learn whether we have misunderstood the experience of a claim.
AI can help notice patterns, question a framing and generate alternatives. Human responsibility remains in the commitments: whose experience we choose to take seriously, which uncertainty we accept, what we are prepared to spend and how we respond if the attempt harms rather than helps. Imagination needs people who can carry a possibility into the world and answer for what follows.
An explicit model can help them do that. It can expose an assumption that was previously buried in a local process, make competing explanations easier to compare and reveal which behaviour would change. Rigidity is a design failure, not an inevitable consequence of formalisation. The danger arises when the model’s current categories become the only language in which a new idea is allowed to make its case.
Suppose our investigation finds that a dependable next contact makes a meaningful difference for some customers. The organisation now has something worth translating back into how it works.
“Keep the customer informed” becomes a commitment attached to a case: what the customer has been told, when the next contact is due and who owes it. That commitment can trigger work even when the claim itself has not progressed. A missed update can reach a person able to respond. An agent can help explain the current situation while the system preserves the difference between a confirmed fact and an estimate.
The change goes deeper than adding another notification. A pending claim now contains an obligation towards a person waiting for it. The model has acquired something it previously failed to represent, and that changes what the organisation does next.
This is also the practical meaning of changing a policy in an executable enterprise. An approved revision must reach the affected goals, action conditions and delegated judgments. Its effective date and transition rules determine how it applies to ongoing cases and existing commitments. Once applicable, the new understanding has to change the next decision. Otherwise the company has revised its words while continuing to execute the old ones.
The insight can now help someone who will never meet the person who first noticed the problem. That is what executable knowledge makes possible: learning gains a life beyond its original moment.
The leadership responsibility grows with that power. People must remain able to question the objectives, notice something the categories miss and commit to a possibility whose value is still uncertain. The architecture gives what they discover a way into everyday work. Someone still has to be willing to begin.
The company learns to run on what it knows. Its future depends on what it is still willing to imagine.
Original AI-generated editorial illustrations. The insurance example is hypothetical.