AI training isn't about prompt engineering courses. It's about four specific skills learned by doing over 90 days. Here's the framework.
Your team doesn't need an AI course. They need to ship an AI system and learn by breaking it. Everything else is theatre.
I've watched dozens of companies spend six figures on AI training programmes that teach people how to write prompts, understand transformer architectures, and pass certification exams. The completion rates are high. The deployment rates are zero. The courses create the illusion of capability without any of the substance.
AI capability is muscle memory, not knowledge. And muscle memory only comes from doing the work.
After mobilising AI teams across multiple engagements, I've identified four distinct skills that every AI-capable team needs. They map to four archetypes. Most people fall naturally into one. The best teams have all four represented.
This isn't "how to use ChatGPT." It's how to look at a business process, say customer returns handling, and decompose it into a series of steps that an AI agent can automate. Which steps require judgment? Which follow predictable patterns? Where does the data come from? Where does it need to go?
Builders see architecture where others see magic. When someone says "we could use AI for that," a builder immediately starts mapping the data flow, the decision points, the failure modes, and the integration requirements. They think in systems, not in prompts.
The difference between an AI demo and an AI system is a builder. Demos are impressive and useless. Systems are boring and profitable. A builder knows the difference and only cares about the latter.
Operators are the people who will run AI systems day to day. Their critical skill is judgment: when to trust AI output and when to override it.
This sounds simple. It isn't. An AI pricing engine might recommend a 40% discount on a product that's actually out of stock in the warehouse. The data lag between systems created a window where the recommendation was technically correct but operationally catastrophic. An operator with AI judgment catches this. An operator without it clicks approve.
Understanding confidence levels, recognising edge cases, knowing failure modes: that's the skill that separates AI-using companies from AI-washing companies. You can't teach it in a classroom. You teach it by putting people in front of live systems with real consequences and a safety net.
Translators bridge the gap between technical teams and business teams. They turn "we could build a multi-agent orchestration system with RAG-augmented decision making" into "we can automate 60% of customer service queries and save £400K per year."
This is the most undervalued skill in AI adoption. Most companies have zero translators. The result is predictable: engineers build what's technically interesting, not what's commercially valuable. The CTO is excited about the architecture. The CFO has no idea what it does. The project gets defunded at the next board review.
Without translators, AI projects die in committee. With them, AI projects get funded, deployed, and measured. Every AI initiative needs someone who can write the ROI case, present it to the board, and defend it when the skeptics push back.
Skeptics aren't blockers. They're quality control. Every AI deployment needs at least one person whose job is to ask the uncomfortable questions.
"What happens when this fails?" "What's the rollback plan?" "Who's accountable when the AI makes a wrong decision?" "What's the worst-case scenario and have we planned for it?" "How do we know this is actually working and not just generating plausible-looking output?"
These questions are the difference between a robust AI deployment and a ticking time bomb. The companies that skip the skeptic phase are the ones that end up in the Financial Times for all the wrong reasons.
The trick is productive skepticism, not paralytic skepticism. A productive skeptic asks hard questions and accepts good answers. A paralytic skeptic asks hard questions to delay indefinitely. You need the former. You fire the latter.
The research on learning retention is clear. People retain almost nothing from lectures. They retain most of what they learn by doing.
Every AI training course in the market is built around the wrong end of that spectrum. Watch a video. Read the documentation. See a demo. The retention rate is abysmal because the methodology is wrong.
We use what we call the "first blood" principle. Ship something real in week 2, not week 20. It doesn't have to be perfect. It doesn't have to be the final system. But it has to be real: real data, real users, real consequences. The learning that happens when your first AI agent makes its first mistake in production is worth more than any certification programme.
Pair programming with engineers who've deployed these systems before beats classroom instruction by a mile. Your engineer writes the agent logic. Our engineer reviews it, explains what'll break, and shows them why. By week 6, your engineer is doing it alone. By week 10, they're teaching their colleagues.
You can't learn to ride a bicycle from a PowerPoint.
Curious what your margin opportunity looks like?
Free Tool
How much margin are you leaving on the table?
Answer 6 questions. Get a personalised margin estimate in under 2 minutes.
Take the Free Margin AuditThis maps directly to the AI Mobilisation Pattern we use on every engagement. The learning isn't a separate workstream. It's embedded in the delivery.
Weeks 1-2: Assessment. Your team observes. They sit in on our architecture sessions, data audits, and process mapping. They don't code yet. They learn how we think about problems, how we decompose processes, and how we identify the highest-value deployment targets. This is where system thinking develops.
Weeks 3-6: Deploy alongside experts. Your engineers pair with ours on every task. They write code. They deploy systems. They break things and fix them. This isn't shadowing, it's doing with a safety net. AI judgment starts developing here, because they see real systems making real decisions with real data.
Weeks 7-10: Enable. The ratio flips. Your team leads. Our team supports. Your engineers architect the next agent. Your operators monitor the live systems. Your translators present results to the board. We're available for questions, code reviews, and the occasional "don't deploy that on a Friday afternoon" intervention.
Weeks 11-13: Transfer. Your team operates independently. We watch, verify, and document. We run the self-sufficiency test at day 75. If they pass, our work is done. If they don't, we extend the enable phase until they do.
At day 75, your team should be able to pass five tests. These aren't theoretical assessments. They're practical demonstrations of capability.
1. Deploy a new AI agent end-to-end (from requirements through to production monitoring) without our involvement.
2. Diagnose and fix a failure in an existing AI system within the agreed SLA, without escalating to us.
3. Present the business case for the next AI initiative to the board, with ROI projections, resource requirements, and risk assessment.
4. Onboard a new team member to the AI systems and processes without external documentation or support.
5. Say no to a bad AI idea and articulate why a proposed use case isn't viable, with technical and commercial reasoning.
If they pass all five, you don't need us any more. That's the point. If you still need us after 90 days, we failed.
Read more about how this works in practice on our methodology page.
Our AI Mobilisation programme embeds real skills in your team through doing, not watching. By day 75, your team passes the self-sufficiency test — or we keep going until they do.
We go into businesses and make them permanently more profitable. Every initiative is EBITDA-tracked.