---
title: "Remake"
description: Remake: the framework for the four kinds of work AI is remaking — thinking, deciding, creating, delivering — how a Board governs the remaking and an organisation executes it.
canonical: https://mariothomas.com/remake/
---

In [The Great Remaking](/briefings/the-great-remaking/), I proposed that AI isn't just another technology wave to be adopted like desktop, internet, web, mobile, and cloud before it. It is remaking how organisations *think*, *decide*, *create*, and *deliver*, across the cognitive and the physical domains at once, and that is why I treat it as a remaking rather than the sixth wave in a familiar sequence.

Every organisation thinks, decides, creates, and delivers, whatever its size or sector. They are not departments; they are the essence of the work itself and AI is remaking each of them.

Governing and executing that remaking needed a framework that did not exist. Most frameworks were built to help you adopt a technology. They ask whether you are ready for a tool, when the real question is what is happening to your work. And they serve one audience at a time. Board toolkits let directors oversee the work without ever touching it. Delivery methods let teams do the work without the Board having line of sight to that work. Either way you get the same result: work nobody truly governs, or governance that cannot see. Most organisations have both problems at once, in different rooms, looking through different windows at the same work.

The Remake framework closes that gap. It is built for the two groups of people every remaking involves: the **operators** who do the work, and the people **answerable** for it, from the executive who owns it up to the Board. In Remake, both work from the same tools and the same labels, so the people doing the work and the people answerable for it always look through the same window. And both must be present before anything starts. If there is nobody with the skills and authority to do the work, or no accountability that reaches the Board, the work does not begin.

None of it is theoretical. Remake is built on three decades of leading businesses through the technology waves that preceded this one, and a front-row seat to the AI and emerging technology wave we now find ourselves in. The models, diagnostics, methodologies, and principles it draws on were used with real organisations before they were written down. The Great Remaking names what is happening to work; Remake is what a Board does about it. The rest of this page sets out what it is, how it works, what it will do for you, and who does the remaking.

## What the framework is {#what-it-is data-toc="What it is"}

Remake is the framework your organisation uses to transform each essence of work. When work is remade, it is either stopped, kept, or changed.

Each is a real decision with real obligations. Stopping means a plan to wind the work down, and proof that it happened, because work that is quietly dropped comes back as risk. Keeping means writing the work down properly, so it no longer lives in one person's head. Changing means the work is transformed and never done in the same way again. Deciding to change nothing is a perfectly good outcome: you have bought certainty, not change for its own sake. The three verdicts are held in the [Stop Keep Change Model](/remake/library/#stop-keep-change).

The decision to stop, keep, or change is reached by using ADAPT: a five-step motion that takes one piece of work at a time from open question to lasting change.

The motion runs on two disciplines. Progression between stages is earned, never scheduled: a stage is complete when its work is done, not when the calendar says so. And each run of the motion carries **one unit of work**: one problem, one sponsor, one decision space. [The motion has its own home](/remake/adapt/), and every stage has its own page, setting out what it protects against, how it runs, and what it produces.

Every remaking begins with the same discipline: one problem, one sponsor, one decision space. Align exists to answer whether you are **working on the right problem** at all. It takes a named problem and a sponsor, tests whether the remaking is worth doing, and tests whether the accountability to carry it reaches the Board. What it produces is **the Investment Case**: a straight answer to whether this change is worth pursuing, and on what basis, before serious money is committed.

[Align in full &rarr;](/remake/adapt/align/)

With the Investment Case made, Diagnose asks **what is actually preventing the outcome**. This is the evidence-based definition of the real problem, not the reported one, and it is where a remaking stops being a matter of opinion. What it hands on is **the diagnosis**: the real problem, evidenced, and ready to be answered.

[Diagnose in full &rarr;](/remake/adapt/diagnose/)

Advise takes the diagnosis and asks for **the strategic response**: what the organisation will do about the real problem, stated clearly enough to direct everything that follows. This is where the verdicts are returned, **Stop, Keep, or Change**, for each piece of work under examination. What it produces is **the guiding policy** the rest of the motion executes.

[Advise in full &rarr;](/remake/adapt/advise/)

Plan turns the guiding policy into executable work: scope, order, and ownership. The question it answers is **how the response becomes something the organisation can actually run**. What it produces is **the Transformation Plan**: one integrated document holding the diagnosis, the policy and its verdicts, the sequenced moves, and the validated Investment Case embedded.

[Plan in full &rarr;](/remake/adapt/plan/)

Transform delivers the plan and asks the question that outlasts the programme: **how does the change endure?** Delivery runs paired with the embedding of capability, so the change survives the programme that produced it. What you are left with is **a transformed organisation**: able to sustain progress on its own rather than renting it.

[Transform in full &rarr;](/remake/adapt/transform/)

## The Remake Library {#library data-toc="Library"}

The Library holds the assets: the named tools the framework thinks with. Each one is a Model, a Diagnostic, a Methodology, or a Principle, and each is used inside the motion's stages.

Remake is openly published and fully described in these pages.

## How it works {#how-it-works data-toc="How it works"}

Every remaking has two groups of people in it. There are the operators, the people who actually do the work: the framework calls this **agency**. And there are the people who answer for the work, from the executive who owns it up to the Board: the framework calls this **accountability**. How Remake works is how it serves both at once.

One rule stands at the front door. Work begins only when two things are true: there are people with the skills and authority to do it, and someone answers for it, all the way up to the Board. If either is missing, the work does not start. Accountability cannot be handed to a project team and still mean anything. A sponsor who shows up at kickoff and then fades is not accountability, and a Board that is briefed but not answerable is not oversight. A change with no one truly answerable for it fails often enough that the framework simply refuses to start one.

Governance is then built into the way the work runs, not bolted on beside it. The stage names do the joining: Align is both the label the Board governs by and the stage the operators run. And every tool in the Library must pass the same test before it gets in: the operators must be able to do the work with it, and the person answerable must be able to use the same tool to see what was done, and answer for it.

## What will it do for me {#outcomes data-toc="Outcomes"}

The outcome of running Remake is not a completed transformation. It is an organisation that knows how to keep transforming, because AI is not going to settle, and the wave behind it is already forming.

AI discussion in most boardrooms collapses into risk management alone. The [Six Board Concerns](/remake/library/six-board-concerns/) behave as one system, and every verdict and every stage output feeds them, so a Board running Remake keeps all six answered continuously.

Every remaking is tested against [Well-Advised](/remake/library/well-advised/) and its five priorities. AI spend stops being justified by hours saved alone, and starts being judged as any other investment would be: on the value it returns and the balance of that value.

Functions move through the [AI Stages of Adoption](/remake/library/ai-stages-of-adoption/) at different speeds, and an organisation running Remake knows honestly where each one stands. No maturity mirage, where the deck says transformation and the operations say pilot: progress becomes deliberate, not accidental.

[Maximum Fidelity](/remake/library/#maximum-fidelity) grades every reading a Board relies on by one of four indicator types: lagging tells you what happened, leading tells you which way it is heading, predictive models what could happen next, and reasoned proves what must hold true. The Board sees forwards, not just backwards, and knows the quality of the evidence under every judgement.

Each run of the motion makes the next one faster: quicker from open question to owned verdict, better at stopping and keeping as well as changing, less dependent on outside help each time. Transformation stops being an event and becomes something the organisation knows how to do.

And that is the posture that matters. When the next wave arrives, and quantum and Embodied AI are already forming, an organisation that runs Remake does not start again. The framework is built to outlast the wave it currently governs. So is the organisation that runs it.

## Who does the remaking {#who-does-it data-toc="Who does it"}

The framework says two groups must exist before any work begins: people who can do the work, and people who answer for it. This section is about how the doing side is actually put together.

The most effective structure I see is built on forward deployment: engineers embedded directly inside the business, building AI where the work happens rather than in a delivery function at arm's length. A forward deployed engineer sits with the people whose work is being remade, sees how the work is really done, and builds with them, not for them.

Forward deployed engineers work in pods: small, self-contained teams that pair the engineers with domain experts, the people who know the work being remade inside out, and the operators who own it. A pod takes one unit of work through the ADAPT motion, which is exactly the discipline the motion demands: one problem, one sponsor, one decision space. And when there is more work, you do not grow the pod; you add another. Pods scale by multiplying, not by swelling.

Every pod needs the layer above it. Someone has to see across the whole organisation: to spot where a remaking would pay before it is obvious, to decide what gets remade and in what order, and to keep each pod's unit of work pointing at the strategy rather than at the loudest problem. That is the remaking lead. Deciding what gets remade, and in what order, is strategy work, so the role sits where strategy sits: reporting to the chief executive and working directly with the Board. It runs the portfolio of remakings the way an executive owner runs one change, sequencing the work so each remaking sets up the next, and it keeps the Board's picture of the whole remaking current. Forward deployment makes this layer matter more, not less. I have spent my career in that layer, and it is that experience this operating model is built on.

The structure, from the top:

| Role | What it is | What it does in a remaking |
|---|---|---|
| **The Board** | Accountable for the remaking as a whole | Governs with the same labels and tools the pods run |
| **The remaking lead** | A senior role, reporting to the chief executive and working directly with the Board | Sees across the whole organisation: spots the opportunities, decides what gets remade and in what order, and keeps the Board's picture of the remaking current |
| **The executive owner** | The senior leader accountable for one change | Owns the verdicts and answers for the outcome, up to the Board |
| **The pod** | A small, self-contained team: forward deployed engineers, domain experts, and the operators who own the work | Takes one unit of work through the ADAPT motion |

Two things support the chain. An [AI Centre of Excellence](/briefings/operating-ai/) gives the Board one view across every pod and carries standards between them. And as pods multiply, their people share what they learn, so each remaking starts further ahead than the last and capability compounds across the organisation.

None of this needs a reorganisation to start. One pod, one problem, one executive owner who answers for it: that is a remaking underway. The structure grows by repetition, and every pod that completes the motion leaves capability behind it.

## How the framework is governed {#framework-governance data-toc="Governance"}

A framework that asks organisations to anchor their governance to it must hold still while they do. Remake is versioned: changes are dated, published, and recorded here, so what you adopted, and which version of it, is never in doubt.

Using the framework means using its fixed parts as they are published: the four essences, the gate, the three verdicts, the five stage names, and the outputs each stage owes. Everything else, the shape of a pod, the cadence of reviews, which assets you reach for, adapts to your organisation. The fixed parts are what make one organisation's remaking legible to another; the adaptable parts are what make it yours. Use of the framework, its materials, and its name is governed by its [licence and permissible-use terms](/legal/remake/).

And the framework changes by revision, never by drift. An asset enters the Library only when it passes the admission test, usable by the operators to do the work and by the accountable owner to answer for it, and the framework itself absorbs what field use teaches in numbered releases. The record lives in the [history](#history), at the end of this page.

## Questions {#questions}

### What is the work?

One of four essences: thinking, deciding, creating, or delivering. Naming the essence being remade is the first step; the essences are not remade at the same speed or through the same mechanisms, so the framework works one essence at a time.

### What is the difference between Remake and ADAPT?

Remake is what an organisation keeps: the map of the work, the rule about who must answer for it, the three verdicts, and the Remake Library. ADAPT is what it runs: the five-step motion that points all of that at one problem, with a clear start, a clear finish, and something to show for each stage. The framework stays; the motion runs, one unit of work at a time.

### Does everything need remaking?

No. For the work under examination the framework returns one of three verdicts, and all three are governed. A Stop verdict requires a decommission plan and verification that the stopping actually happened. A Keep verdict requires documentation sufficient to break key-person dependency. A Change verdict proceeds through the full motion. An all-Keep outcome is a legitimate result, and the motion exits cleanly at Remake: Advise when it occurs. The questions that reach the verdict are set out in [Not Everything Needs AI](/blog/not-everything-needs-ai/).

### What happens when nobody is accountable?

The work does not start. A remaking proceeds only where there are people with the skills and authority to do the work and accountability for the change that reaches the Board, and the gate tests both together. Accountability cannot be handed to a project team and still mean anything: a sponsor who fades after kickoff is not accountability, and a Board that is briefed but not answerable is not oversight. A change with no one truly answerable fails often enough that the framework refuses to start one.

### How is it done?

Through ADAPT, the framework's five-step motion: Remake: Align, Remake: Diagnose, Remake: Advise, Remake: Plan, and Remake: Transform. Two disciplines hold it together. Progression between stages is earned, never scheduled: a stage is complete when its work is done, not when the calendar says so. And each run carries one unit of work: one problem, one sponsor, one decision space.

### What do you get?

An Investment Case from Remake: Align: a straight answer to whether the change is worth doing before serious money is committed. A Transformation Plan from Remake: Diagnose, Remake: Advise, and Remake: Plan together: one document holding the evidenced problem, the chosen response and its verdicts, the order of work, and the Investment Case it rests on. And from Remake: Transform, a transformed organisation: change delivered and measured, capability built into your own people, and the ability to keep going without outside help.

### Why does this matter?

The five technology revolutions before AI, desktop, internet, web, mobile, and cloud, changed the surrounding conditions of work. AI remakes the work itself: how organisations think, decide, create, and deliver. That is the thesis of [The Great Remaking](/blog/the-great-remaking/), and it is why a framework built around adopting a technology misses the point. The Great Remaking names what is happening to work; Remake is what a Board does about it.

### Does Remake apply beyond AI?

Yes. Remake is designed for technologies that change the essence of work, not for AI alone. AI is the first instance, and quantum and embodied AI are the next tests I expect it to meet. Other technologies belong in scope only if they pass the same test. The technology may change, but the framework's questions do not: what work changes, who has agency, who remains accountable, and how the change is carried through.

### Do we need to reorganise to use Remake?

No. One pod, one problem, one executive owner who answers for it: that is a remaking underway. A pod is a small, self-contained team, forward deployed engineers, domain experts, and the operators who own the work, and when there is more work you add another pod rather than growing the first. The structure builds by repetition, and every pod that completes the motion leaves capability behind it.

### How does the framework itself change?

By revision, never by drift. Remake is versioned: changes are dated, published, and recorded, so what you adopted, and which version of it, is never in doubt. An asset enters the Remake Library only when the operators can do the work with it and the accountable owner can answer with it, and the framework absorbs what field use teaches in numbered releases.

### Can we use Remake in our organisation?

Yes, that is what it is for. Remake is openly published and fully described in these pages: the path, the verdicts, and the motion are all here to be applied to your own remaking. Use of the framework, its materials, and its name is subject to the framework's [licence and permissible-use terms](/legal/remake/): applying it inside your own organisation is permitted, and commercial delivery of Remake is licensed separately.

### How does it relate to the Complete AI Adoption Framework?

The Complete AI Adoption Framework is retired as a progression, not a deprecation. It was the prototype that first proved the integration of the execution assets under board-level governance, and its name marks exactly what its successor outgrew: it governed the adoption of a technology, where Remake governs the remaking of the work. The public chain reads: the Complete AI Adoption Framework, then Remake, the same integration, properly architected, with the two relations, the gate, the three verdicts, and the ADAPT implementation motion.

### Where do the assets fit?

The assets are the lenses applied within the motion's stages, not a separate layer above or below it. AISA is read at Remake: Align and Remake: Diagnose, Well-Advised is the Align close-out test and returns at Advise, the Six Board Concerns are surfaced in the Investment Case and carried through. ADAPT is the motion; the assets are the lenses within it. The full set lives in the [Remake Library](/remake/library/).

## History {#history}

Provenance and revision history for the framework itself: the same record every asset in the Remake Library carries.

<dl data-role="control">
<div><dt>Framework</dt><dd>Remake</dd></div>
<div><dt>Status</dt><dd>Current</dd></div>
<div><dt>Version</dt><dd>1.0</dd></div>
<div><dt>Published</dt><dd>11 August 2026</dd></div>
<div><dt>Supersedes</dt><dd><a href="/remake/library/#complete-ai-adoption-framework">The Complete AI Adoption Framework</a></dd></div>
</dl>

### Versions {#versions}

<ol data-role="history" reversed>
<li><b>1.0</b> <time datetime="2026-08-11">11 August 2026</time> <span>First public release of Remake, superseding the Complete AI Adoption Framework.</span></li>
</ol>


## Pages in this section


- [ADAPT](https://mariothomas.com/remake/adapt/)

- [Library](https://mariothomas.com/remake/library/)

