Teaching AI agents turned out to be a change management exercise

Earlier this month I spent two hours teaching a room of PMETs, retirees, and people between jobs how to build one working AI skill. It was the closing module of a full day pilot at the Singapore University of Technology and Design. Two hours is not enough time to teach someone to design an AI agent from a blank page, so I did not try to. I taught them to build one thing well enough that it kept working after I stopped talking, and that turned out to be the same adoption problem I have spent 8+ years diagnosing across 100+ digital maturity assessments.

The skill nobody names on a CV

Across 8+ years in digital transformation and Industry 4.0, and more than 100 digital maturity assessments across manufacturing, oil and gas, and precision engineering, I have noticed something that never makes it onto a job description. The thing that actually gets tested, whether in a classroom or on a shopfloor, is never “do you know the framework.” It is whether you can watch how a group of people actually work, notice where the real friction sits, and build something they will use rather than something that looks impressive on a slide. That is the change management lens every assessment runs through. It is also, almost exactly, what teaching a room with two hours and no coding experience between them to build something useful requires.

What two hours actually allowed

There was no time for participants to design an agent from scratch, so I built the shortcut for them. Working in tables of five, sharing a single paid Claude Cowork seat between them, the room practised pulling the key requirements out of a job description using fictitious postings, nothing real or sensitive. Once that worked, we saved it as a skill: a routine they could call up again on a new job description without retyping the original instructions, set to output a Word document straight into their laptop folder. The exercise itself was small. What mattered was that it kept working once I was no longer standing at the front of the room.

The pattern repeats everywhere I look

Once you have run enough of these assessments, you start to recognise the same failure mode wherever it shows up, whether the change being managed is a new ERP rollout, a factory adopting a new production line, or someone trying their first AI skill. Adoption fails not because the technology was wrong but because nobody built something that survives without the expert in the room. Show people a demo and they forget it within the week. Give them something they can call up again on their own, and they keep using it. The SUTD room was the same pattern in miniature, compressed into two hours instead of a six month rollout.

Reinvention is a change management project, and you are the organisation

I wrote recently about the patterns that separate transformations that stick from the ones that stall: resistance that hides instead of announcing itself, quick wins chosen for visibility instead of relevance, shopfloor buy-in that beats a leadership mandate every time. It turns out those same patterns apply to a career, not just a company. Most of the room that day was not made up of business owners. It was PMETs, retirees, and people between roles, each already living out their own reinvention. Teaching them to build one AI skill that kept working after the session ended was proof, in miniature, that a reinvention built on what you already do well outlasts the workshop it was born in.

Nobody wakes up one day a different professional. If a career change feels like starting over, it probably is not. It is probably the same skill you already have, looking for a new room to work in.