The Intelligence-Centred Firm

I didn't invent this frame, and I'm wary of anyone who says they did. The economics under it are Coase's; the AI extension is Diamandis and Ismail's. What I'm working is the half they leave thin: what an intelligence-centred firm does to people and institutions, not just to cost curves. I'm building case studies of real New Zealand organisations doing this, and running my own practice on the model.

Where this comes from

It sits on a durable piece of economics, not futurism. Ronald Coase explained why firms exist; Diamandis and Ismail asked what AI does to that. The argument, compressed:

• Why firms exist. Coase won a Nobel for a simple point (1937): companies exist because coordinating work inside a firm was cheaper than contracting it out. Hierarchy was the cheaper option, so firms grew. The layers, managers and meetings are that coordination machinery.
• What AI breaks. AI agents drive the cost of coordination toward zero. Building the thing becomes cheaper than having the meeting about building it, so the logic that built the traditional firm runs backwards.
• The consequence. The organising principle moves from hierarchy to intelligence. Small teams plus AI do what used to need large headcount; firms get smaller and more numerous.
• What survives. Not the org chart, not middle management, not the five-year plan. What survives is judgement and taste, a few people holding it, and a human container that carries the liability for what the intelligence produces. The durable moat is learning faster than anyone else.
• The honest caveat. The thesis is strong on the technology and thin on people, regulation and society. Worth holding those gaps in view rather than waving them away (last section).

1The one shift

The deep change is in the unit economics. The traditional firm exists because coordination inside it was cheaper than contracting out. The whole structure — layers, managers, hand-offs, headcount — is the apparatus of internal coordination. When AI drives coordination cost toward zero, that apparatus becomes the expensive part: execution gets cheap, coordination stays dear. The firm's centre of gravity moves from coordinating people to holding judgement over what the intelligence produces.

The efficiency this releases is captured as margin and capacity, not as lost output. The catch: only if the business model isn't still priced and structured as though human hours are the product.

2What "intelligence at the centre" actually is

The engine is a tight learning loop — modelled on the military OODA loop (Observe, Orient, Decide, Act) — aimed at recursive self-improvement at the workflow level: the system gets better at the work every cycle. Six layers, with a human at the gate of each. Illustrated with a simple signal — a competitor announces same-day delivery:

Where the human sits: at the gate of each layer. The intelligence prepares; people decide and own. Interpretation and Decision are where judgement is irreplaceable and where attention should go. Sensing and Orchestration are where the leverage is — the work that used to consume the middle of the organisation.

That is the shape: deep specialists at the edges, intelligence at the centre, no middle layer — because the middle layer (the people who aggregate, draft, and coordinate) is the intelligence stack now.

3Govern & assure — the wrapper the stack can't run without

Autonomous agents can go wrong, so the stack is bound by a governance harness. This isn't bureaucracy bolted on — it's the part that makes the rest safe to run, and the part most organisations underbuild.

• The human is the fiduciary wedge. The intelligence does the work, but a human organisation still exists to hold the accountability and the liability for what it does. Agents prepare; an accountable person decides and signs. Build this as a hard rule.
• Agent "passports." Every agent carries metadata that strictly bounds what it may do — which systems, which data, which actions — with a liability framework behind it.
• Searchable logs + granular rollback. Every action is recorded, attributable, and reversible. "Show me exactly what produced this and who checked it" must always have an answer.
• Risk-tiered human review. You can't review everything at machine speed, and pretending to is the failure mode. Define which outputs are high-stakes (anything externally committing, anything with real consequence) and gate those hard; let low-stakes internal steps run with sampling and audit.

4The two stacks — what you build on

Why owning it matters: the knowledge bank — the codified judgement and the workflow library that improve every cycle — is the asset. If it lives inside a vendor's platform, you don't own your own moat.

5The shape of the organisation

The traditional pyramid is sized to coordinate and to bill hours: layers of people aggregating upward. The intelligence-centred shape is different:

• A few senior judgement-holders — interpretation, decision, the relationships, the signature.
• The intelligence stack doing what the middle of the pyramid used to do.
• An oversight / assurance function — someone owns the wrapper, the logs, the quality gates. In a small organisation this is a hat, not a head.
• A talent layer as a judgement-codification engine — the point of the people is to turn senior judgement into the templates the stack runs. Codifying the judgement is the work.

6The frontier lab — how you actually get there

You don't transform an existing organisation from the inside. A working organisation has an immune system — it rejects radical change to protect itself — so injecting this into the core gets attacked and killed. The move (Buckminster Fuller; Hagel & Seely Brown on disruption-at-the-edge) is to build a new thing at the edge that makes the old way obsolete, and let it become the centre of gravity. Apple built the Mac with a small team at the edge; Nestlé's Nespresso only worked once it left the main company.

The instrument is a frontier lab — a small autonomous team at the edge, built around the models, whose job is to discover the new way of working and pull the rest of the organisation toward it. Its output is not only software, but also people and practices.

How it runs:

1. Backcast. Write down what the organisation looks like fully intelligence-centred, then plan back from there.
2. Pick one workflow and rebuild it. Take a single, standardised, prescriptive process, fork the data, and rebuild it from scratch with intelligence at the centre.
3. Run it in parallel. The new version runs alongside the real one — fully de-risked. If it fails, the core is untouched.
4. Let it recursively improve. The lab runs the workflow until the loop is improving the process every iteration, and it's clearly outperforming the old way.
5. Migrate, then widen. Deprecate the old workflow; bring the next one into the lab. The lab gradually absorbs the organisation's functions and becomes the new operating core.
6. Rewire the stack (section 4) as you go.

Greenfield is the cleanest case of all. If you're building something new rather than transforming something old, there's no immune system to fight and no legacy stack to rip out — you put intelligence at the centre on day one. Almost nobody starting an organisation has that advantage and uses it.

7The questions the frame forces

The frame is only as real as the answers to these. They're the same questions in any organisation:

Purpose & boundaries

• What are the operating principles — the protocol the agents and people run inside? What will the organisation do, and refuse to do?
• Which constraints are hard-coded into every workflow (the things that must never be crossed)?

Scope & the first workflow

• Which single workflow do you rebuild first — standardised enough to template, valuable enough to matter?
• What's explicitly out of scope at the start, so the thing stays sharp?

Govern & assure

• What data is safe to put where? (A real policy, not a vibe.)
• Who decides and owns the output — where's the non-delegable human signature?
• What gets human review, triggered by what level of risk?

Stack & data

• Build or buy the data layer — and what are the permission rules at the level of each data object?
• Where does the knowledge bank (the codified judgement, the templates) live so that you own it?

People

• How does someone junior grow judgement here when the entry-level work is automated? (Design it now.)
• Is the talent layer's real job to codify judgement into the system — and is it set up that way?

8The hard questions — where the theory is thin

The architecture is detailed; the human, legal, and economic layers are asserted more than argued. The through-line: the case is that human decision-making is too slow, yet at every load-bearing point the human reappears as the safeguard. Held honestly, these are the real work.

• Apprenticeship. The biggest unsolved problem (section 5). Where do senior people come from once the work that trained them is gone? The codification engine is the best answer going, but it has to be built.
• The human-review bottleneck. "AI fast, humans catch every error" can't both be true at machine speed. The resolution is risk-tiered review, decided explicitly — not the pretence of reviewing everything.
• Regulation, insurance, and people-law set the timeline. Often these — not the technology — are the gating constraint. Treating them as afterthoughts is how the plan slips.
• The economic transition is a discipline. The hard part isn't building the stack; it's doing it while still priced and structured as though human hours are the product.
• Liability is real. "The accountable human is accountable" is correct — and means the buck genuinely stops with a person. The audit trail isn't bureaucracy; it's the defence file.
• Read the numbers critically. The confident headline figures (organisations running on a fraction of the workforce, large middle-management cuts) are under-evidenced. The mechanism is the real claim; the percentages are not.

9What dies, what survives, the moat

The ultimate moat. Regulatory position and proprietary data help, but erode. The durable advantage is intelligence — workflows that learn and iterate faster than anyone else's. If you learn fastest, no one catches you.

The question, thenWhere you'd start

You'll probably already be running a handful of AI projects. Are you seeing the value you were promised? If you're not — and most aren't — it's rarely the AI that's the problem. It's that you're bolting it onto something that was never built to carry it.

The frame doesn't ask you to rip that out. It gives you a way to experiment your way in — one workflow, rebuilt at the edge and run in parallel, where the core is never at risk — and let the version that works pull the rest of the firm toward it. The only real question is which workflow you'd start with.