Written for Machines
When agents do the work, governance written for people governs no one, and the operating model has to become an operating system the machines can read and run.
A firm writes its AI policy, approves it, and puts it in the deck. It is a good policy, careful about what the models may touch, clear on where a human must sign off, precise on the lines nobody may cross. And it governs almost nothing, because the things now doing the work cannot read it. An agent acting at machine speed at three in the morning does not open a PDF, and it does not wait for the risk committee to sit on Tuesday. The policy binds the people who read it, and in a firm where agents act, the people are no longer the only ones acting.
It is not only policy. A target-state diagram is advice a person may choose to follow; it governs nothing an agent generates. A standard on a wiki changes no behaviour a model was never told to check. If the rules are to bind the thing doing the work, they have to be something the thing can read: policy as code, architecture as tests, standards that run. Do that across the disciplines and the operating model stops being a description of how the firm should work and becomes an operating system it runs on. Teams still build it, one use case at a time, but what they leave behind is no longer a document the organisation can quietly ignore; it is running code it cannot.
1. Governance written for people governs only people
In a firm where agents act, and act at machine speed, a policy that lives in a PDF and is read once a quarter is not a control, it is a record of good intentions. To bind an agent, a rule has to be code the agent is subject to, checked as it acts, not a paragraph it will never open. Architecture works the same way. What governs an AI build is not the diagram on the wall but the architecture test that runs against every application and every skill and fails the build when the design drifts. The move, everywhere, is from advice a human may follow to a constraint a machine must satisfy. Governance written only for people governs only people, and people are no longer the only ones acting.
2. Nine disciplines, each built into a skill
The operating model we build is nine disciplines, grouped in three domains. Organise is how the firm is arranged, staffed and funded: Structure, Talent, Finance. Build is how systems are designed and built, and on what material: Architecture, Engineering, Data. Assure is how the firm stays safe and provable while it moves fast: Risk, Security, Ethics. Making any one of them executable is not a one-off translation, it is a capability the firm has to hold, so behind each of the nine sits a skill: a packaged, versioned unit carrying that discipline’s standards, its checks, its guardrails and its worked examples, which your own people use to author and adapt it to your estate. A team making a policy executable reaches for the Risk skill and writes the rule, traced to the regulation, in a form that runs; to enforce a design constraint it reaches for the Architecture skill and writes the test; to get its data ready to answer and honest enough to refuse, the Data skill. The discipline stops being a body of advice and becomes a tool your staff wield, which is what lets the operating model be built and kept current in-house rather than handed down and left to rot.
3. The operating model becomes an operating system
Because these skills are legible to machines, the agents use them too. An agent asked to build or change something need not be briefed on how your firm works; it reads the skills and assembles a solution that already fits, calling the right checks, applying the current policy, staying inside the architecture, because all of it is now code it can consult. At that point the operating model has stopped being a description and become an operating system: a live substrate the firm’s agents run on, that its people keep authoring, and that shifts as the disciplines shift. The model that used to live in slides and induction decks now runs, and the things doing the work are inside it rather than alongside it.
4. It is built one team at a time
None of this is installed from the centre by decree, it is built by a team running a real use case, because that is the only place a slice of the model gets written and proven at once. A team carrying a use case puts the operating model under load across its three domains, Organise, Build and Assure, and where it meets resistance it writes the missing piece: a new executable policy, a new architecture test, a new skill. Each turn ships value and leaves behind a machine-legible slice of the model that the next team and every agent inherits. The team is the engine; the running model is what the engine leaves behind. Change spreads as it always has, by one team proving the thing works and the next believing it can, only now what the first team leaves is not a slide but code the whole firm can build on.
5. The part that is only yours
The model you bought is on sale to everyone; any competitor can license the same frontier system by Friday. What no one can buy is the executable, agent-run operating model your teams have written into your own estate: the accumulated policy-as-code, the enforced architecture, the library of skills, each bound to how your firm actually works and denser every time a team ships. It is made in place, by your people, and it cannot be lifted out and copied, because it is not a document to be taken but a system to be run. That is the return AI pays, and it is the only part of the stack that is yours.
Try this
An organisational prompt is a small provocation you act on this week, not a theory to file away. Here is one: take the AI policy your firm is proudest of, the one in the deck, and ask whether one of your agents could read it and be bound by it right now, or whether only a person can. If only a person can, it is not governing the things that do the work, and you have found where the next use case should press.
Further Reading
AI transformation is a workforce transformation, BCG
The 2025 State of AI-assisted Software Development, DORA
Open Policy Agent, CNCF
Building Evolutionary Architectures, Thoughtworks