In practice · 08 of 09
The board told me to do AI. I have activity, not a programme.
AI is not a separate dimension of the operating model. It is a force acting on all of them, and running it beside the operating model rather than inside it is why most organisations cannot show a return.
Why the mandate produces motion rather than change
An AI programme, an AI lead, an AI budget, sitting alongside the business rather than inside it. Every experiment is greenfield, because greenfield is where the tools work. The estate that actually runs the business is untouched, so the return is measured on the part of the organisation that was never the problem.
The technical reason is specific. Coding agents work well on code written last month and poorly on a long-lived estate, because they sample, and sampling cannot reliably distinguish a deliberate business rule from an accident of a record layout. Point an agent at forty thousand files and it will read a few hundred of them and answer confidently.
The constraint is permission and evidence, not capability
This is the finding that surprises people, and it holds across very different institutions. The model is no longer the limiting factor. Two other things are.
- Legibility. Whether the part of the estate you want to point a tool at can be described accurately enough that the tool's output can be trusted and checked.
- Access. An agent needs access, and access is where internal AI tooling fails long before capability does. Internally built context tools tend to stall not because they do not work but because they let people see things they are not entitled to see, and role-based access, tenancy separation and an auditable record of what the agent saw turn out to be the hard part.
That is why the question an owner cannot answer is rarely "can the model do this". It is "can I evidence what the agent saw, and who authorised it".
What AI is doing to each dimension
Treated as a force rather than a programme, it presses on every dimension at once, and each one has a question its owner usually cannot yet answer.
- People. Knowledge transfer compresses from months to weeks, while the skill many teams were built to supply commoditises. If capacity is what commoditises, what is the team for.
- Vendors. The unit cost of a supplied engineer has not moved, so a single-digit discount does not add up. What is the supplier actually charging for now.
- Customer experience. Demand arrives already AI-generated. The volume shock comes from outside, before anything is adopted inside.
- Security and resilience. An agent needs access. Can you evidence what it saw and who authorised it.
- Investment and FinOps. AI for cost gets funded and AI for growth does not. Token spend is a new unit cost with no owner.
- Technology and architecture. The model is not the constraint. Legacy integration is, and that is where the benefit disappears.
- Engineering excellence. The tools are already in engineers' hands. Knowing where it is safe to use them is not.
What we actually do
We establish which parts of the estate are legible enough to be safe to point an agent at, and what has to be true before the answer is yes. That produces a short list of places where value is available now, a longer list of places where it is not and why, and the access and evidence conditions that have to be met before either list moves.
It is deliberately not a tooling recommendation. In most organisations the tools are already bought and already in engineers' hands, and the missing thing is a defensible answer to where they may be used.
Common questions
We have already deployed tools and cannot show a return. What went wrong?
Usually nothing about the tools. The return is measured on greenfield work because greenfield is where the tools were pointed, and the estate that carries the business was never in scope. The return appears when the constraint being removed is one the business actually pays for.
Should we build our own internal context or AI tooling?
Many organisations try, and the common failure is not capability. It is access control. A tool that shows an engineering manager their own estate also shows them things they are not entitled to see, and the deployment stalls there. Whatever you build, treat role-based access, tenancy separation and an audit trail of what the agent saw as first-class requirements rather than as a later hardening phase.
Is AI for growth or for cost?
In practice, cost cases clear approval and growth cases do not. That is an observation about how investment committees behave rather than a view about what is possible, and it is worth knowing before a business case is written rather than after it is rejected.
When this comes up. Comes up with a board AI mandate carrying a date, a new Head of AI, or a rollout that cannot show value.
How it is delivered
Compass across the dimensions as the diagnostic, then Blueprint. Canvas where legibility is the blocker and Vault where the access question has to be evidenced. Each module is a fixed deliverable behind a go or no-go gate, and the baseline earns the design. The full set of modules is here.
Related situations
- Sovereign and in-tenant deploymentA qualifying gate rather than an engagement. Nothing crosses the boundary.
- Key person risk and knowledge transferEvidence what depends on fewer than three people, then design the transfer around it.
- Capability centre and GCC designClassify the capabilities before anything moves, and design the receiving model around what does not commoditise.
Tell us what you are trying to land.
A short conversation about your situation and whether an independent accountable role is the right instrument. If it is not, we will say so. No deck follows automatically.