Diagnose. Prioritise. Adopt. Our AI-Augmented Enterprise framework.

Diagnose. What the AI maturity audit covers.

The Diagnose phase looks past the surface of an AI programme and reads the operating reality underneath. In our experience, most enterprises know what they have done in AI by proof-of-concept count and by vendor demos. They know much less about what they can actually deliver, who owns the work after launch, where the data is trusted, and what the regulatory exposure looks like across the use cases on the roadmap. The audit covers four layers.

The capability layer. What the engineering and data teams can actually build. The skills on the bench, the tooling in place, the platform standards that already exist or need to be created. The teams we work with often have stronger engineering capability than they realise, and weaker platform discipline than they would like. Both are worth naming honestly.

The data layer. Where the trustworthy data lives, who decides what the canonical source is, and what the gaps are between the data that exists and the data the agents will need. This is rarely a volume question. It is almost always a governance question, and the Diagnose phase tends to surface unresolved disagreements about ownership that should have been settled before the first use case was funded.

The regulatory layer. The mapping of the use cases on the roadmap against the regulatory regimes that apply, including the AI Act for European exposure, the financial services regulators where relevant, and the national data protection regimes in the regions where the work will run. Bringing legal, security and compliance into Diagnose rather than into a final audit is one of the highest-leverage moves we recommend.

The organisational layer. Who genuinely wants the AI programme inside the executive team, who would prefer the status quo, where the operator buy-in actually sits, and what the politics of the build look like once it moves from innovation to operations. The honest reading of this layer is the single largest predictor of whether the programme will reach production.

The audit is not a vendor demo run by us. It is a structured conversation with the leadership team, the engineering team, the operators, and the legal and compliance functions, with the output being a clear-eyed map of where the organisation is and where the gaps live. The clients we work with who take Diagnose seriously tend to walk into Prioritise with a much sharper view of what is actually fundable.

Prioritise. The scoring exercise that focuses budget.

The Prioritise phase reduces a long list of plausible AI use cases to a small number of bets that justify the investment. The teams we work with usually arrive with somewhere between fifteen and forty candidate use cases, each of which sounds reasonable when described in isolation. The job in Prioritise is to apply a consistent scoring discipline that surfaces which use cases will pay back and which would consume disproportionate budget for marginal value.

The scoring we use carries five dimensions, each of which the leadership team scores explicitly with reasoning, not just numbers. The dimensions are operator value, technical feasibility, data readiness, regulatory exposure, and the change management cost. A use case that scores high on operator value but low on data readiness is a candidate worth investing in differently from one that scores high on technical feasibility but low on operator value. The honest read of the scoring tends to compress the long list to between three and six bets that the organisation can actually deliver in the relevant horizon.

In our experience, the Prioritise phase is where the executive team finally has the conversation about trade-offs that has been quietly avoided. Two leaders both want their use case prioritised, the budget supports one of them, and the discussion that follows is the one that should have happened months earlier. The framework's value is partly in the scoring and largely in the conversation the scoring forces.

For more on the prioritisation thinking that sits behind this phase, our earlier writing on the journey from proof-of-concept to production covers the operating ground that makes a prioritised use case actually deliverable. The two pieces work together: Prioritise tells you what to build, the production discipline tells you how to make sure it ships.

Adopt. The change management work nobody talks about.

The Adopt phase is the one most often skipped and the one that decides whether the AI programme turns into operating value. The pattern we see across the teams we advise is consistent. The build phase gets the budget, the steering committee attention, and the press release. The adoption phase gets a small training plan added at the end. The agents ship, the operators do not use them, and three quarters later the programme is being quietly rebranded.

Adoption is design work, not training work. The job is to put the operators in the room from the first sprint, let them shape what the agent does, what it shows, when it interrupts them and how it admits uncertainty. The agents that operators co-design are the agents operators use. The agents operators are introduced to at launch are the agents operators avoid. We have seen this play out enough times that we now insist on operator participation in the design phase as a precondition for our engagement, not as an option.

Adoption also requires explicit handover discipline. The operations team that will run the agent after launch needs to be in the room before the agent exists. They write the runbook with the build team. They co-design the alerting. They name the on-call rotation. They define the service level agreement. When launch day arrives, the agent is already theirs. The programmes that hold this discipline tend to keep their agents in production. The programmes that treat handover as the final step usually rebuild the engagement six months later.

The third dimension of Adopt is the incentive layer. Operators whose performance is measured against metrics the agent does not help with, or actively hinders, will not use the agent regardless of design quality. The Adopt phase looks honestly at the measurement and incentive system that will surround the agent in daily use, and surfaces the changes that need to happen in parallel with the technical build.

An AI programme that ships agents and never reaches the operators is a programme that has done the easy half of the work. Adoption is where the value lives, and it does not yield to acceleration.

How AI-Augmented Enterprise integrates with Tech Factory.

AI-Augmented Enterprise is the consulting side of the work. The build side, when the prioritised use cases need engineering and the agents need to be built, runs through our Tech Factory. The integration between the two sides is one of the operating choices we have made deliberately, and it tends to be one of the reasons clients work with us across both engines rather than separating them.

The integration matters because the design intent that comes out of Prioritise needs to survive the build. The build team needs to understand why a use case was chosen, what trade-offs were accepted, what the operator inclusion plan looks like, and what the governance commitments are. When the consulting partner who led Prioritise stays close to the Tech Factory team that runs the build, the design intent holds. When the engagement is handed over to an unfamiliar engineering team, drift starts in the first sprint and tends to compound.

In practice, the way we run this is that the consulting partner from AI-Augmented Enterprise sits on the build steering committee throughout the engagement. They do not run the engineering. They hold the design intent and catch the drift. The Tech Factory partner runs the build, the consulting partner holds the brief, and the client team retains the integration authority. That triangle is the operating model we have found tends to ship working agents.

The difference between pilots and production.

If your organisation has a portfolio of AI pilots that have not made the jump to production, the Diagnose phase will usually tell you why before any new use case is added to the roadmap. The honest pattern, which we have explored in our earlier writing on industrialising AI agents, is that the bottleneck is rarely the model. It is the operating discipline around the model, the data trust underneath it, and the operator inclusion that should have happened before the build started.

AI-Augmented Enterprise is the framework that addresses those three foundations explicitly. It does not promise faster pilots. It promises a smaller number of better-chosen bets, with the operating model in place to turn them into production systems that operators actually use. The clients who have walked the framework with us tend to come out of it with fewer projects on the roadmap, a clearer view of which ones will ship, and a much sharper sense of what their organisation needs to learn to make the next wave of work easier.

If your team is approaching an AI programme, or trying to recover one that has stalled, the brief form below is the place to start the conversation. We answer within one working day, with the partner who will sit on the file rather than a relationship manager.