Where enterprise AI stalls: between the pilot and daily use

Anthropic announced Claude Frontier Academy. As described in the announcement:

• 10,000 “Frontier Deployed Engineers” trained by the end of 2027.
• A multi-day programme with Anthropic engineers, followed by a 12-week residency back at their own company.
• Each participant arrives with a named Claude project to lead back at work.
• First partners include Accenture, Deloitte, McKinsey and Morgan Stanley, among others.

Anthropic’s own reason is that the people who can make AI work inside a real business “have become the hardest talent to find.”

If the hard problem were model quality, a model maker would spend its money on models. It is spending on people who can take a working demonstration and turn it into something an organisation relies on every day. I would say the hard step is getting from a pilot that works to a system people use daily.

I want to mark that as my interpretation. Anthropic did not say it in those words. But it fits what I see in the way AI projects are set up.

There is also a catch. The credential is a Claude badge, so the skills it builds may not travel if you change vendors. The general skills, such as mapping a process and deciding where a human checks the output, do travel. The platform-specific ones may not. Anyone building a team should know which is which.

A pilot has advantages that daily use lacks. It has an enthusiastic owner, a bounded scope, a forgiving audience and usually a person watching the output closely. When it succeeds, it proves the technology can do the task. It does not prove that the organisation can absorb it.

Daily use asks different questions. Who owns the process now? What happens when the output is wrong at four in the afternoon on a busy day? Who is told when the model changes? What does the team stop doing, so that this does not become extra work on top of the old work?

None of these is a technical question, and none is answered by buying a better model.

A pattern I describe often runs like this. The board buys enterprise AI licences. Staff get access and are told to find uses. People become somewhat more productive in their own tasks. Six months later the question arrives: why is the AI investment not showing returns?

My diagnosis is that the approach was tool-first instead of problem-first. You handed people a list of solutions and asked them to go and find the problems. That sounds reasonable until you look at who is being asked. A sales team is busy with targets. A finance team is closing the month. Most were never taught to think about process redesign, and spotting a good use case is itself a skill.

The alternative is to start from the process inventory, not the tool inventory. A process inventory is a plain list of how work actually gets done: who does what, in what order, who approves, and where it stalls. Most organisations do not have one. Marketing teams, in particular, often do not document their process, and it lives in people’s heads.

Five questions help:

1. Which processes are slow?
2. Where do we pay agencies or consultants?
3. Where is there friction between teams?
4. What is repetitive?
5. Which decisions get too little analysis because nobody has time?

Then I would go and sit with the people who do the work. A bottom-up approach has, in my experience and in my opinion, a much higher chance of success than a top-down mandate. The architecture has to be built by the people doing the work, because they know where the process really breaks. For each step, note what a model can deliver and where it might hallucinate, meaning where it might give a confident answer that is false, and design that risk out.

This is where Anthropic’s announcement is useful, even if you never send anyone to its academy. Before your next AI budget, try one thing: name the person on your team who could lead a production deployment today.

I do not mean the person who is best at prompting. I mean the person who can map the process, choose where a human signs off, set the spending limit, handle the data question, and stay accountable for the system after the launch excitement has faded. If you can name that person, your budget has somewhere to go. If you cannot, the gap to close first is not a tool. It is that role.

Organisations tend to fill the role in one of three ways, and each has a trade-off.

• Your own engineers. Slowest to start, but the knowledge stays with you when the project ends.
• A consulting firm. Faster, but the knowledge can leave with the engagement unless you require handover and documentation.
• The vendor. Convenient, and closest to the product, but the interest in your long-term independence is limited.

None of these is wrong. The mistake is to leave the choice unmade, so that the deployment is led by whoever happens to be keenest.

Who leads AI deployments in your organisation today: your own engineers, a consulting firm, or the vendor? The answer matters more than most of the line items in the budget, and it is usually missing from the plan.