Nine papers, one argument:
where the value is, how to get it, who builds it, how to write it down, how to govern the workforce that runs it, who carries the risk of the build — and which mind makes each decision.
Enterprise AI adoption is nearly universal; enterprise AI impact is rare. These papers set out why, what to do instead, what it takes to deliver it inside a timeline that survives contact with an organisation, how a company of 50 to 500 people should write the strategy down — generally, and inside a professional practice — how to buy the result rather than the effort, what an autonomous workforce must be able to answer once it runs, why hiring developers to build is a risk decision, not a staffing one — and why most of the decisions an agentic system makes never needed a frontier model.
Establishes the problem and where value actually concentrates: not in better models, but at level five of the maturity ladder, where the workflow itself is re-engineered around governed intelligence.
Read paper No. 1 →Every legacy process is a fossil of constraints that governed intelligence removes. This paper sets out how to re-derive a process from its outcome rather than renovating it on top of the old limitations.
Read paper No. 2 →Method without a machine dies of its own timeline. This paper answers the question the first two leave open: execution — and why the constraint that kills level five is the time between the design and the cutover.
Read paper No. 3 →It should be a list of operations.
How a 50-to-500-person company writes an AI strategy that changes how it runs: the unit is an operation, not a use case; the first act is a constraint inventory, not a vendor evaluation; and governance is a property of the build, not a policy document.
Read paper No. 4 →cannot buy back time.
The method applied to the accounting and advisory practice: what to re-derive first, why a language model must never be the last word on a figure a client relies on, and what happens to the billable hour when the close takes five days instead of fifteen.
Read paper No. 5 →You paid for the effort.
Why outcome-based pricing usually fails: most vendors change only the invoice, so they carry a risk they cannot control and hedge it. The delivery model that makes an operational outcome contractable, the commercial model that follows from it, and the four questions that expose the difference.
Read paper No. 6 →Where is the decision?
Sovereign compute is necessary and not sufficient. What an autonomous workforce still has to answer once the data centre is certified — where each number came from, which rule applied, who signed, and how much autonomy that decision has earned — and six questions for any vendor that claims one.
Read paper No. 7 →You needed an owner.
Coding agents made code cheap, so enterprises hire developers to build. The decision looks like staffing; it is risk allocation. The seven risks an in-house build takes on, how to tell a software factory that equips your developers from one that delivers to your business, and the role worth building in-house instead — with six questions to ask before approving the hire.
Read paper No. 8 →Most were never a frontier problem.
An agentic system is mostly small, bounded decisions — routing, triage, gating — and most stacks send every one to a frontier model. The case for a decision layer: rules first, a small model the enterprise owns, a frontier model only for what the cheaper minds doubt. With the economics, the risks, five tests for a delivery model and a six-phase path that starts with one decision.
Read paper No. 9 →Every paper’s argument is readable in full on this site. Papers one, four, five, six, seven, eight and nine download as a formatted PDF straight away; papers two and three are sent by email.
How they fit together
Paper one is diagnostic: three independent research programmes agree that the constraint is not model quality but the failure to change how work is done, and value concentrates only at level five of the maturity ladder. Paper two is the method — deliberately public, because any capable team can run it: inventory the fossil constraints, re-derive the process from the outcome, place every decision, and stage autonomy by reversibility. Paper three is what the method cannot supply on its own: speed. A redesign that takes eighteen months re-creates every failure the method exists to avoid, so the third paper describes the delivery machine — the Two Minds runtime, the Software Factory and the OS series. Papers four and five bring it back to the reader’s own desk: the fourth is how a company of 50 to 500 people writes the strategy down — an ordered list of operations, each with a baseline and an owner — and the fifth runs that method through a single sector, the accounting and advisory practice, where the product is the hour and the risk is the wrong number. Paper six separates the commercial model from the delivery model that makes an outcome contractable. Paper seven describes the workforce that does the routine work once the strategy is written — and why, once the compute is sovereign, the decision still has to be. Paper eight addresses the decision underneath all of them: who builds, and who carries the risk — and why the capability worth building in-house is the owner of the requirement and the adoption, not the coder. Paper nine turns to the smallest unit inside all of them: the individual decision, and which mind — a rule, a small model the enterprise owns, or a rented frontier model — should make it.
