The five pillars of AI readiness

"Which model should we be standardising on?" It is the question I hear most in board reviews, and it is the wrong one. AI readiness is not a model problem. It is the condition of five things sitting underneath the model: your data, your tools, your agents, your governance and your operating cadence. Two companies can run the identical frontier model and get opposite results, because everything that decides the outcome lives in those five pillars, not in the model choice. So the useful questions are these. Can the model reach the data it needs? Can it call the tools that touch your customers? Can it run an agent that does more than answer a single prompt? Do you know what it is never allowed to decide? And does anyone maintain the whole arrangement on a rhythm that keeps up with how fast it changes?

Why AI readiness is not a model problem

Most organisations grade themselves on the wrong axis. They ask which model they run, which platform they bought, which roadmap they signed off. None of those predict whether AI produces real output a year from now. The model has become a commodity you can swap in an afternoon. What surrounds it takes months to get right, and that is exactly where the readiness lives.

Think of the five as a stack, not a menu. Each pillar rests on the one below it. You cannot build agents on data you cannot trust. You cannot govern tools you cannot see. And none of it stays standing without a cadence holding it up. Read the stack from the base:

This is also why the AI operating system and the readiness assessment are different objects. Readiness is the diagnostic: it tells you where the stack is thin. The operating system is the runtime: the thing you build once you know. Teams that only ever run the diagnostic re-score the same five pillars every quarter and never construct anything, because nobody moved from grading to building. The score is only worth having if a build follows it.

Pillar 1: Data

Data is the pillar most companies underestimate and most pilots die on. The model was fine. The data underneath was incomplete, stale, scattered across tools that do not speak to each other, or owned by nobody. This is the single most common reason AI pilots stall at production: the demo ran on a clean export a person prepared by hand, and Monday-morning data looks nothing like it.

What good looks like here is specific. Every customer-facing system has a documented owner and a refresh cadence. Permissions are declarative, written down, not tribal knowledge held by one long-serving admin. The model can reach the same source of truth a human would consult, in the same shape, without three exports and a manual join. Sensitive fields are tagged at source, so privacy is a property of the data rather than a filter someone remembers to apply at runtime.

What bad looks like is just as recognisable. "We need to do a data project first" becomes the reflex answer to every AI question. The same metric reads three different ways in three systems and nobody can say which is right. Every workflow needs a human to stitch the inputs together before anything can run.

The trap is treating this as a two-year platform migration. You do not need clean data. You need enough trustworthy data to run one real workflow end to end. Start with the data one workflow touches, get that reachable and owned, and move on. The rest can wait for the workflow that needs it.

Pillar 2: Tools

A model without tools is a chatbot. A model with tools is an operator: it reads the calendar, drafts the message, books the room, updates the record, closes the ticket. The gap between those two states is where most of the value sits, and it is a wiring problem, not an intelligence problem.

Good here means the model can call a small, well-chosen set of tools through stable interfaces: MCP, function calling, internal APIs. Every tool call is logged and reversible, so a mistake is a line in an audit trail rather than a silent action against a customer. New tools get added by the team that owns the workflow, not routed through a procurement queue that takes six weeks. This is the pillar where automation platforms earn their place. n8n runs around £20 per builder seat per month, is SOC 2 and ISO 27001 compliant, and self-hosts, which means the team can wire a new tool into a workflow in an afternoon instead of buying another point solution.

Bad here is the tell that a company has bought AI theatre. Every integration is a screenshot or a copy-paste. Tool access waits on someone manually granting credentials. The "AI tool" turns out to be a wrapper around a chat window with no access to any system that matters. It can talk about the work. It cannot do it.

Tools are the pillar where engineering and operating teams have to actually sit together. Skip that joint design and you end up with tools the model technically can call but operationally should not, which is worse than no tools at all.

Pillar 3: Agents

An agent is a model plus a goal plus the ability to take steps. Most companies do not need many. They need three or four, doing the work that used to clog three or four roles. The instinct to build an agent for everything is how you end up with a graveyard of half-finished ones, none of which has been run on a real day's work.

Good agents are scoped to a single workflow with a clear owner and a clear off-switch. Each one carries a "what should never happen" list, not just a "what to do" prompt, because the failure modes are where the risk lives. They are judged on output quality and operator trust, not on how many tasks they touched. The fastest way to climb the AI operating ladder is not to deploy more agents. It is to deploy fewer, better-scoped ones, into workflows that already exist and already have an owner.

Bad agents are a pile no one can name from memory. Agents orchestrating other agents to produce output nobody reviews. An inventory that grows because building is fun and pruning is not. If you cannot list your agents and their owners in a single breath, you have too many.

The honest base rate is worth stating. On one defence-tech engagement, a small set of well-scoped agents reclaimed 83 hours a week and handled 70 per cent of routine queries through systems the team owned, with zero critical issues two months on. That did not come from a large agent estate. It came from a few, built into the grain of work that was already happening.

Pillar 4: Governance

Governance is the pillar most teams treat as the brake. It is not the brake. It is the steering. The teams that move fastest with AI are the ones that decided early what they would never let it decide, because a clear boundary is what lets everyone else move without asking permission each time.

Good governance is short and written. A one-page list of decisions a human must make. A logged audit trail of agent actions on any customer-facing surface. Clear escalation paths for when an agent produces an outcome outside its envelope. Privacy and DPA review built into workflow design, not bolted on the week before launch. The document your CFO, GC and DPO will actually read, treated like product rather than paperwork.

Bad governance lives in a Slack thread between the head of legal and the head of engineering. Every new agent re-asks the same compliance questions from scratch, so nothing compounds. The audit trail exists in principle, but nobody can tell you where the logs are kept. When that is the state, governance is not slowing you down. Its absence is, the first time something goes wrong and there is no record of what the system did or why.

Pillar 5: Operating cadence

An AI operating system without a maintenance cadence is a garden without a gardener. The plants do not stop growing. They just stop being the plants you wanted. Cadence is the cheapest pillar to build and the most expensive to skip, and it is the one that keeps the other four honest.

Good cadence is a standing rhythm with names against it. A weekly or fortnightly forum where new workflows, agent failures and policy changes get reviewed out loud. A named owner for each agent, with explicit hours, not a shared sense that "the team" looks after it. A monthly look at the metrics that matter (operator trust, output rejection rate, time to decision) rather than vanity dashboards. A quarterly cull of agents and tools that no longer earn their keep, which is exactly the review that £40k licence never got.

Bad cadence is a programme that is permanently "in flight" with no recurring meeting. The launch was the last time anyone looked at the workflow. Nobody can name who owns the prompt that runs ten thousand times a week. When cadence is missing, the system does not fail loudly. It drifts, and you find out months later that half of it has quietly stopped being trustworthy.

What ready looks like against what theatre looks like

Put the five together and the difference between a ready organisation and one performing readiness gets easy to see. It is rarely about ambition. Both kinds of company want the same outcome. One has built the conditions underneath the model and the other has bought the appearance of them.

This is also the honest answer to boards that want AI framed as a maturity number. A board-ready maturity model is useful for tracking progress over time, but it only means something if it maps to these conditions. A high maturity score with a two-year data project underneath it is a score measuring intent, not capability.

Score one workflow, not the whole company

Here is the play you can run on Monday. Do not assess the organisation. Assess one workflow. Pick a single workflow you actually need to run: a contract renewal, a new-joiner setup, a support triage. Score that workflow out of three on each pillar. The lowest score is the pillar stopping it from reaching production. Build the smallest thing that lifts that pillar to a two, then run the workflow.

Worked through, it looks like this. Take a new-joiner setup workflow and score it honestly:

The lowest scores are tools and cadence, both at one. So the first build is not a data platform and not a smarter model. It is wiring the identity tool and putting the workflow on a fortnightly review. Two small, cheap moves that turn a stalled workflow into a running one. Repeat with the second workflow, and the third. Within a quarter you have a working AI operating system built in the order real work demanded it, not the order a vendor sold it, and the readiness score starts moving on its own.

If you want a structured version of the same exercise, the free Readiness Assessment runs sixteen questions across the capability layers and hands you a ranked view of where your thinnest pillar is. It takes about ten minutes and gives you somewhere honest to start.

AI readiness is the condition of an organisation's data, tools, agents, governance and operating cadence such that it can absorb AI as capability rather than as demo. The five pillars form a set, and the weakest one decides the strength of the whole.