Why this exists
Most AI programmes do not fail in the build. They fail in the decision about what to build, taken before anyone could say what it would return.
The usual path runs: a platform is chosen, a centre of excellence is formed, a roadmap is drawn from somebody else's company, and twelve months later the organisation owns licences nobody opens, a pilot nobody promoted, and a maturity model it is behind on. Nothing in that sequence was incompetent. It was simply too much, decided too early, measured too late.
ENOUGH is six stages that answer one question in order: how much AI does this business actually need, and how do we stop there.
The last stage is the point. A framework that ends with "expand" is a subscription. This one ends with the client running it without us.
E
Examine
What is already true.
- Runs for
- Four to six weeks.
We spend the first fortnight listening rather than proposing. We sit with the people whose week the work would change — not only with the people who would sponsor it — and ask what takes them longest and what they do twice. We pull the usage numbers out of the tools already bought: seats issued against seats opened in the last ninety days. And we try to reach the data ourselves, because how long that takes is the honest measure of readiness, and it is never the answer you get by asking.
By the end we can say, for every candidate on the list: how many hours it touches, what it would cost to build and to run, whether the data is reachable, whether anyone could tell if it worked, and who would own it afterwards.
---
- You end up with
- A jobs-to-be-done map ranked by hours; an inventory of what is paid for against what is opened; a readiness reading per candidate across target, data, evaluation and ownership; and the blockers that have to close before anything starts.
- What we refuse here
- Benchmarking you against other companies' maturity models. What a peer is doing is not evidence about your business.
N
Narrow
What to build, and what will not be built.
- Runs for
- Six to ten weeks, overlapping the end of Examine.
This is where the list gets shorter. We rank the candidates by hours returned against what a year of running them costs, then sequence what survives: what has to exist before what, and who owns each piece.
Then we set the target. Most roadmaps are borrowed from a company that is not yours; we work out the level of maturity your own numbers justify and stop there. Everything above that line goes on the refusal list with a reason and a figure beside it — what you save by not buying it, and what you give up.
---
- You end up with
- A twelve-month plan with an owner and a budget per initiative; a metric tree built into reporting you already run; a read on who you hire, who you train and who you stop hiring; and a signed refusal list.
- What we refuse here
- Choosing a platform before choosing the first workflow. The work picks the platform, not the other way round.
O
Outline
The smallest architecture that carries the chosen work.
- Runs for
- Three to five weeks, inside the first build.
We draw the smallest architecture that carries what you decided to build, and nothing for what you decided not to.
In practice that is one gateway with budgets and a bill you can read; somewhere for context to live, with an owner for every fact in it; a skill library your team writes and extends; MCP services over the systems that matter, with access scoped and audited; a harness that runs, retries and watches the agents; and evaluations with a labelled set and a score that moves when something changes. Security sees this at the start rather than at the end. And before anything is chosen, we price what leaving it would cost.
---
- You end up with
- An architecture that fits on one page; a build order; an access model security has already seen; and the lock-in you are accepting, written down with the cost of getting out.
- What we refuse here
- Anything bought for a workload that does not exist yet.
U
Use
One or two things in production, used in real weeks.
- Runs for
- Eight to twelve weeks for both.
We build one or two of them into the place the work actually happens, and we write the evaluations before the build rather than after.
Then they meet real demand instead of prepared examples. When an answer comes back wrong we fix the cause — the metric definition, the source rule, the skill — and run the question again, so the mistake improves the system instead of being corrected by hand. Somebody from your side owns each system from the first week, while it is still ours to fix.
---
- You end up with
- One or two systems running in your infrastructure; the evaluations that prove they work; the skill library and context your team owns outright; and a runbook saying what each costs a month, where it fails and what to watch.
- What we refuse here
- Shipping without an evaluation. What can only be judged by impression will be defended by impression.
G
Gauge
What it returned and what it costs to run.
- Runs for
- Four weeks, starting a month after the first system is in use.
A month after people start using it, we measure — against the baseline taken in Examine, not against an estimate made now.
Hours returned per person, cycle time, and the reporting line that was supposed to move, set against the whole cost of running it: tokens, seats, infrastructure and the people hours keeping it alive. Where the return did not appear, we say so and explain what that tells us. That answer re-ranks the list for the next round.
---
- You end up with
- What each system returned and what it costs, in your own numbers; a revised ranking for the next cycle; and a note of what was measured, how, and what the measurement cannot tell you.
- What we refuse here
- Reporting adoption as a result. Seats issued and sessions opened describe activity, not return.
- The loop
- This is the only place the framework goes backwards: the measured result re-ranks the list in Narrow. Everything else runs once.
H
Hand over
The roadmap the team runs without us.
- Runs for
- Four to six weeks per cohort.
We move the work to named people with capacity already budgeted, and train the facilitators for the next build from inside, so the second project costs less than the first.
Your team writes the standard they will then have to live with — it is theirs, not ours, which is the only reason anyone follows one. We leave a twelve-month roadmap in your language, with the decisions already taken and the ones left open on purpose. Then we stop.
---
- You end up with
- A roadmap with owners and dates; the skill library, context and evaluations owned outright; a standard your team wrote; trained facilitators already on your payroll; and the hours returned measured per participant.
- What we refuse here
- A retainer to run what we built. If the handover needed one, it was not a handover.
Operating principles
Every fact has one owner
A metric definition lives in one place and is referenced, never copied into five skills and three prompts.
The refusals are the deliverable
Two of the six stages produce more value by removing than by adding, and they are priced accordingly.
Nothing is proposed before it is examined
No recommendation in week one.
Measure against a baseline taken before, not an estimate made after
A number produced at the end of a project to justify it is not a measurement.
Minimal is a constraint, not an aesthetic
Every part added has to beat the cost of operating it for a year.
The engagement ends
Dates are set at the start, including the date we stop.
Where this fits the work
The four services are the framework, sold in the sizes clients actually buy.
Where to start
With the thing you already know is broken. One workflow, one number it should move, one person who would own it. That is enough to run stage E, and stage E is enough to find out whether the rest is worth paying for.