Core Concepts

What Does "AI Native" Really Mean?

Concept overview · 3 min read

Most organisations that call themselves AI Native have bought AI tools and pointed them at existing work. The more useful definition is structural: an AI Native organisation is one whose operating model assumes machine intelligence is present, the way a digital native company assumes the internet is present. The difference is not which technology is deployed but what the organisation is designed to do with it.

A redesign, not a deployment

When a company adopts a tool, the tool is fitted around existing roles, approvals and reporting lines. A forecasting model is bolted onto a planning process that still runs on monthly spreadsheets. A document assistant is offered to teams whose incentives reward writing long memos rather than answering questions. The technology changes; the way work is decided does not.

AI Native work runs the other way round. It starts from the work itself: which decisions get made, by whom, on what evidence, and how quickly. Once those answers are explicit, the supporting data, knowledge and machine reasoning can be arranged around them. The tool then becomes a consequence of the design rather than a substitute for it. A useful test is visible in the workflow itself. Under a tool-led change, the steps, approvals and hand-offs stay where they were; under a design-led change, some of them cease to exist.

The five properties

In practice, organisations that have made this shift consistently show five properties. They are diagnostic rather than aspirational — each one can be observed, or found missing, in an ordinary working week. Read together, they describe an organisation whose default is to answer a question and act on evidence rather than to convene and defer.

• Organisational intelligence — the enterprise senses, reasons and acts as one system rather than as disconnected functions.
• Queryability — ordinary business questions can be answered in seconds by anyone entitled to ask them.
• Knowledge operations — knowledge is maintained like a product, with owners and quality standards, instead of accumulating in inboxes.
• Decision rights — written boundaries say what machines decide, what people decide, and what they decide together.
• Human middleware — the roles and interfaces that turn machine output into accountable business action.

Where to begin

The transition rarely starts with a platform. It starts with an honest assessment of where decision quality is weak, where knowledge is trapped, and where feedback never returns. From there, one workflow is redesigned end to end and used as the template for the next. Redesign is cumulative: each workflow makes the organisation easier to redesign again. A sound first candidate is important enough to matter and bounded enough to finish, with one accountable leader able to see it end to end.

Questions to ask

• Which decisions would be made differently if the relevant knowledge were available in seconds?
• Can we name an owner for each of the five properties, or are they nobody's responsibility?
• When we last deployed an AI capability, what decision or workflow changed as a result?
• Are we designing around the work, or fitting tools around the org chart?

Defining Organisational Intelligence

Framework deep-dive · 3 min read

Organisational intelligence is the capacity of an enterprise to sense, reason, learn and act as a single system. It is not the sum of how capable its people are, nor of how clever its AI tools are. It is an emergent property of how people, processes, data and machine reasoning are wired together — and it can be raised by design.

Three intelligences, often confused

Leaders frequently conflate three different things. Individual intelligence is the talent in the room. Tool intelligence is the capability of the software on the desk. Organisational intelligence is whether the two are joined up well enough to produce good decisions at speed. A firm can be rich in the first two and poor in the third, which is why strong specialists and impressive platforms can sit inside a slow, error-repeating organisation.

What high intelligence looks like

In a highly intelligent organisation, information crosses functional boundaries without a meeting to broker it. Decisions are made against shared evidence rather than against the loudest account of events. Feedback returns quickly: a change on the plant floor, at a supplier or in the market becomes visible to the people who can respond, and the response is recorded so that the next decision is better informed.

The symptoms of low organisational intelligence are equally consistent. Meetings substitute for data. Decisions are made in information vacuums and reconstructed afterwards. The same failure is rediscovered by a different team a year later because nobody wrote down what was learned.

How it is raised

Organisational intelligence is not bought in a licence. It rises when three things are deliberately improved.

• Shared sensing — agreeing which signals the organisation will watch, and making them visible where decisions happen.
• Connected knowledge — capturing the reasoning behind decisions, not just their outcomes, so context survives the departure of the person who held it.
• Closed feedback — designing each workflow so that the result of one decision returns to inform the next.

None of these three is a technology purchase. Shared sensing may begin with the decision to measure something the organisation currently ignores. Connected knowledge may begin with a discipline of recording why a decision was taken, not merely what was decided. Closed feedback may begin by attaching a single review step to a workflow that today ends in silence. Each is small on its own; together they change how the organisation thinks.

Questions to ask

• When a signal appears at the edge of the organisation, how many days and how many meetings pass before a decision is made?
• Are decisions made against shared evidence, or against the most persuasive account of it?
• When we get something wrong, is the lesson captured where the next decision can find it?

Why Unintelligence Matters

Strategy · 3 min read

Every organisation runs on two maps: what it knows, and what it does not. Most strategy work examines only the first. Unintelligence is the deliberate mapping of the second — the data you do not collect, the signals you cannot sense, the knowledge locked in individual heads, and the decisions made with no feedback at all. You cannot build intelligent systems on top of gaps you have never named.

Three kinds of gap

Unintelligence is not a single problem. It appears in at least three distinct forms, each with its own remedy, and most organisations carry all three to some degree.

• Blind spots — signals the organisation does not sense at all, so a change becomes visible only once it reaches the accounts.
• Stranded knowledge — understanding that exists in people's experience but was never captured, so it leaves when they do.
• Open loops — decisions with no feedback path, which means the organisation cannot tell whether its judgement was good.

Why the invisible gaps cost most

The gaps you already know about are, in a sense, already managed: someone has flagged them and the risk is at least on a register. The expensive ones are those nobody has noticed. A plant that measures output but never measures the causes of rework is running an open loop. A sales organisation that records its wins but not the reasoning behind its lost deals is stranding knowledge. These absences stay invisible precisely because nothing in the reporting system asks about them.

When AI initiatives stall, the cause is usually here. The models are adequate; the organisation simply lacks the structured evidence and captured context they need to be useful. Buying better reasoning does not fix missing inputs, and no amount of model capability will answer a question the organisation has never recorded the material to answer.

Auditing what you cannot see

An unintelligence audit is a structured exercise in asking what is not tracked. Take a critical decision and trace backwards: what led to it, what was known, what was assumed, and what will never be recorded. Repeat the trace across a handful of decisions and patterns appear — recurring blind spots, predictable open loops, knowledge that lives with two or three people.

Run the exercise with the people closest to the work, not only with managers, because the gaps are usually invisible from the reporting line and obvious from the floor. The output is a short list of gaps ranked by the cost of not closing them, which becomes the honest starting point for any serious AI strategy.

Questions to ask

• Which of our important decisions are made with no feedback loop at all?
• If two or three key people left tomorrow, what would we no longer know how to do?
• What do our systems measure about outcomes, and what do they measure about causes?
• Which signals would reach us months late, only once they appear in the accounts?

Building Queryable Organisations

Guide · 3 min read

A queryable organisation is one in which an ordinary business question can be answered in seconds. Throughput last shift, the suppliers with the highest defect rate, what was learned from a project that finished two years ago — in a queryable organisation these are questions anyone entitled to ask can resolve, with context, without booking a meeting. Queryability is the operational test of whether an organisation is genuinely run on its own knowledge.

What queryability is, and is not

Having dashboards is not the same as being queryable. A dashboard shows the questions somebody anticipated; a queryable organisation answers the questions nobody thought to design for. The distinction matters because most operational decisions are not on anyone's pre-built report. Queryability is measured by how close the organisation comes to answering an unanticipated question correctly and quickly, not by how many charts it can display. The aspiration is not a richer reporting stack but a working relationship with the organisation's own memory.

The three layers

Queryability rests on three layers, and a gap in any one of them breaks the whole.

1. Structured, accessible data — operational and commercial data held in a form that can be joined and interrogated, with clear definitions and owners.
2. Captured and indexed knowledge — the reasoning behind decisions stored so that it can be retrieved by topic rather than by remembering who was in the room.
3. An interpreting interface — a person or an AI system able to turn a natural-language question into a search across both, and return an answer with its context intact.

The underrated layer is definition. Two teams can hold the same data and still contest every answer, because they disagree about what a defect, a unit or a completed order actually is. Queryability depends on published definitions as much as on accessible systems.

Reaching a first queryable domain

Queryability arrives domain by domain, not as a company-wide switch. Start where questions are frequent and answers are currently slow — maintenance, quality, supply, or a major customer programme. Within that domain, define the questions people actually ask, then work backwards to the data and knowledge they require, and only then choose the interface. Publish a small set of answerable questions and expand the domain only once those answers can be trusted. Trust, once established, is what makes the next domain cheap.

There is also a cultural precondition. People must be able to ask questions without first justifying why they want to know, and answers must arrive without a meeting to bless them. Where asking is treated as a challenge to someone's authority, the data can be perfect and the organisation will still not be queryable.

Questions to ask

• Which five questions do our people ask most often, and how long does each take to answer today?
• Could someone new answer a routine operational question without interrupting a colleague?
• Is our knowledge indexed by topic, or only by whoever happens to remember it?
• When an underlying fact changes, does the answer change with it?

Human Middleware in AI Systems

Design pattern · 3 min read

Human middleware is the layer of people, processes and interfaces that sits between what an AI system outputs and what the business actually decides. As systems take on more reasoning, the human role does not disappear — it shifts from operating to interpreting, judging and escalating. Organisations that ignore this layer swing between blind trust in the machine and oversight so heavy that the system's value is lost.

What the layer does

Middleware is not simply a person who checks the output. It performs three specific jobs. It interprets machine output in the light of context the system cannot see — a customer relationship, a regulatory nuance, a plant constraint. It judges whether a recommendation is sound enough to act on. And it escalates, deciding when an answer is uncertain or consequential enough to leave the automated path. Designing the layer means naming who does each of these jobs, and when. In most organisations these jobs exist informally, performed by whoever happens to be nearby; the design task is to make them explicit, staffed and resourced.

Interfaces and thresholds

Two design decisions carry most of the weight. The first is the interface: people can only judge a machine's reasoning if they can see it. Recommendations that arrive with their evidence — what was considered, what was rejected, how confident the system is — can be assessed on their merits. Those that arrive as bare answers invite either rubber-stamping or quiet rejection.

The second is the threshold: written rules for when a human must be in the loop. Thresholds tied to consequence, reversibility and confidence let routine decisions flow at machine speed while ensuring that high-stakes or novel cases reach a person. A threshold that lives only in people's heads is not a control.

Keeping the loop closed

Middleware only improves the system if corrections travel back into it. Every override is evidence: it records where the model was wrong, where context was missing, or where a rule was miscalibrated. Organisations that capture overrides — and route them to whoever owns the model — convert human judgement into updated training and rules. Those that do not are left with a permanent set of people quietly compensating for the same error.

A common failure is to place the layer on the wrong side of the decision. If reviewers are asked to approve work they cannot evaluate, middleware becomes ceremonial: a signature that transfers risk without improving the decision. If they are asked to add judgement the system cannot hold, the layer is doing real work and should be designed and measured as such.

Questions to ask

• For each automated decision, can the person reviewing it see the reasoning behind it?
• Are the thresholds for human review written down, or assumed?
• When a person overrides the system, where does that correction go — and who acts on it?
• Are we asking people to add judgement the system cannot have, or to approve work they cannot evaluate?