Running it with an internal AI taskforce, answered in full.

Because scaling an agent pilot requires changing roles, decision rights and governance across functions the taskforce has no authority over. A taskforce is typically staffed part-time by enthusiasts from one or two teams. It can prove agents work; it cannot redefine other people's jobs, and that is what scaling actually requires.

The first third adopt because they were always going to, they are curious and self-directed. Everyone else adopts only when their actual role, incentives and measurement change to assume the new way of working. More training does not move this number because awareness was never the constraint. The 30% figure is a pattern we have observed across the engagements we have run rather than a published statistic.

Usually yes. A taskforce is cheap, fast, and discovers real friction points better than any external party. Run it, learn what agents can do in your context, and bring in outside help at the point where scaling requires authority the taskforce does not have. Engaging a consultancy before that point tends to buy analysis you could have generated yourselves.

The reliable signals are: pilots succeeded but did not spread; adoption plateaued and more enablement is not moving it; different functions are building incompatible things; or risk and audit have started asking questions nobody can answer. Any two of those together mean the constraint has moved from capability to operating model.

Three conditions do most of the work. Protected time rather than side-of-desk goodwill, so the pilot survives a busy quarter. A first workflow that sits inside one function, because anything needing three departments to agree will outlast the enthusiasm behind it. And a stated point at which the taskforce says what it has proved, so exploration does not quietly become a year of pilots. Risk and audit belong in the room early too, since taskforces typically meet them only when something goes wrong. Get those right and a taskforce gets further than most consultancies will admit, because nobody knows your business better than your own people.

It is not a duration, it is an event, and it arrives the first time success depends on a function the taskforce does not sit in. Feasibility is quick. A workflow can be proved in weeks, which is why our own fixed-price proofs of concept run two to four weeks. What consumes the calendar is everything after, because spreading a working pilot means changing roles, decision rights and measurement across an org chart the taskforce has no authority over. The signal is not months elapsed. It is that pilots stopped multiplying while enthusiasm stayed high.

Start with the people whose work actually changes, not only the volunteers from technology and innovation. The standard shape is part-time enthusiasts from one or two functions, and that shape predicts the stall precisely because the group proves agents work and cannot redefine anybody's job. So add an executive sponsor who can change how a role is performed, someone from risk and audit while the design is still moveable, at least one engineer who will build rather than evaluate, and a named person from the function that has to operate the thing afterwards.

Whoever will run the workflow afterwards, with an executive accountable for the change in how the job gets done. The commonest mistake is leaving ownership with the taskforce. It proved the thing, so it looks like the natural home, but it sits outside the function whose roles, targets and measurement have to change and it cannot change any of them. Moving ownership properly means the operating function owns the outcome, a named executive owns the decision rights, and risk owns the governance. The taskforce then keeps what it is genuinely good at, which is finding the next thing worth proving.

You pay when the question has changed from whether agents work to whether this workflow can be built properly and run afterwards by your own people. Free is accurate on cash and misleading on time. A taskforce is usually staffed with your busiest people, and the meter running is elapsed quarters rather than invoices. A fixed-price proof of concept is £20,000 to £55,000 over two to four weeks, built inside your estate, with your engineers paired on it and the code yours at the end. If the taskforce has not hit a wall yet, keep the money.

It keeps going, and it becomes the most useful thing in the room. The taskforce holds the institutional knowledge and the map of where the real friction sits, which is exactly what an outsider spends weeks acquiring. In practice its members pair with ours on the build, with skill transfer measured rather than assumed, and the permanent team we help you recruit is usually built around them, because recruiting that team is a stated deliverable. We leave on an exit date agreed at kickoff. The taskforce is what is still standing afterwards.

Usually not, and the parts that get rebuilt are rarely the parts people worry about. The pilot proved the workflow, exposed the data problems and showed which exceptions matter, and none of that has to be discovered twice. What tends to be redone is governance, because approval points and evidence bolted on afterwards rarely satisfy the people who have to sign them off, plus anywhere two functions built incompatible versions of the same thing. Bring the working pilot to the first conversation. It is the fastest briefing you can give us.

Because each group is solving its own problem correctly and nobody owns the seams between them. A taskforce can convene teams but it cannot tell a function that its version has to give way, which is one of the reliable signs it has run out of mandate. The parts worth settling once are the shared ones, identity and access, retrieval, evaluation and the audit trail. What should stay local is the thin layer holding each function's exceptions and policy. Deciding that split above the functions, and making it stick, takes authority a taskforce does not have.

Take it as information rather than obstruction, since the constraint has moved from capability to governance, and shipping more pilots will make it worse. The pattern is familiar. Taskforces ship first and meet the risk function when something goes wrong or when audit notices, and retrofitting the evidence costs far more than designing it in. The move that works is to stop scaling for a moment and bring risk and audit in as designers rather than blockers, settling the human-in-the-loop points, the decision trail and what gets logged while the design can still change. Governance before scale is cheaper than governance after an incident.

Sometimes very little, and that is worth knowing before you spend anything. If your taskforce already has a costed sequence, a sponsor and a mandate to change roles, buy the delivery rather than the analysis. What the AI Readiness Audit adds, where it adds anything, is the breadth a taskforce rarely reaches: the workflows in functions it never got into, a straight read on your data estate and risk appetite, and working prototypes rather than slides, inside a costed plan your board can approve. Four weeks, £44,000 fixed, standalone, and a recommendation to stop is a valid outcome.

Often it is the same structure with a better name, and it meets the same wall for the same reason. The test is not what the group is called or where it reports. It is whether the group can change how a job is done inside a function nobody on it reports into, and whether governance is designed by it rather than negotiated with it after the fact. A centre of excellence with real cross-functional decision rights and full-time people is a different animal and will get a long way. One staffed part-time with enthusiasts and a mandate to advise will prove feasibility and stop.

Two numbers, and neither of them is licences issued. First, the share of the target population using the thing in their real work, which tends to stall somewhere around 30% across the engagements we have run, a pattern we observe rather than a published statistic, and the number that tells you when the constraint has stopped being capability. Second, whether the process itself changed: a step removed, a queue gone, a handover that no longer exists. If the second is flat while the first climbs, you have a popular tool sitting on top of an unchanged process, which produces enthusiasm and no measurable value.

Side of desk is fine for exploration, and it is part of why a taskforce is such a cheap first move. It stops being fine the moment you want a pilot to spread, because the work then is negotiating role changes with functions that never volunteered, and that is nobody's second priority. Part-time staffing is also why a taskforce reads as advisory to everyone outside it. If you cannot free at least one person properly, say plainly that what you are buying is feasibility evidence rather than a rollout, and say it to the sponsor before the pilot lands.

Size matters less than how many org charts a single decision has to cross. In an organisation small enough that one team's decisions affect everyone anyway, the people in the room already set roles and measurement, so the mandate problem does not exist and a taskforce can carry the whole thing. Once a workflow spans functions with their own targets, their own systems and their own view of the risk, the taskforce is negotiating rather than deciding, and negotiation is where it stalls. Count the functions the workflow touches rather than the headcount.