Teach It Once
By Uy Tran - Chief Services Architect
09/02/2026
The second specialist is where the trouble shows up.
The first one goes fine. A team stands it up, shapes it over weeks of configuration and correction, and ends up with a worker that genuinely does the job. Then the team goes to stand up a second one, for an adjacent role, and discovers something uncomfortable. Half of what the first specialist can do is needed again, and there is nothing to hand over.
The capability exists. It is just not anywhere you can point to. It is dissolved into one worker's setup, spread across instructions and corrections and configuration that nobody could separate back out. So the team that built it once builds it again, from the beginning, for the next specialist. And again for the one after that.
Capability that lives inside one worker is not capability the organization owns
Organizations hit this exact problem with people, generations ago, and the answer they landed on was not better training. It was the written procedure.
A procedure takes something one person figured out how to do and turns it into something the organization has. It has a name. It can be read, questioned, and improved. When a new person joins, nobody reconstructs the capability from scratch; they hand over the document. The knowledge stopped living in a person and started living in an artifact.
The same move is available for AI specialists, and it changes more than convenience. A skill, in this sense, is a discrete written unit of capability: how to produce the quarterly report, how to qualify an inbound request, how to review a document against the standards that matter here. Written once. Handed to any specialist whose role calls for it.
A skill is handed; memory is earned
In the last piece in this series, we drew a line between knowledge a specialist inherits and knowledge it earns by doing the work. Skills sit firmly on the inherited side, and that placement is what makes them governable.
Because a skill is authored, it can be reviewed before any specialist runs it. Someone with standing can read it, decide it reflects how the business actually wants that work done, and put their name on it. Because it is a unit, it can be granted and revoked deliberately, role by role. And because it is written down, improving it once improves every specialist that carries it. The correction that used to be made worker by worker gets made in one place.
None of that is true of capability that grew invisibly inside a single specialist's configuration. That version works, but it cannot be inspected or transferred, and improving it means reaching into the one worker holding it.
An organization that cannot express its capability in transferable units has no medium in which to redesign anything.
The unit is what makes redesign real
The reason I keep pressing this goes beyond tidiness. In McKinsey's latest State of AI survey, just 39 percent of organizations report any earnings impact from AI at the enterprise level, and most of those put it under 5 percent. The organizations seeing the most value are nearly three times as likely as everyone else to have fundamentally redesigned individual workflows rather than layering AI onto existing ones, and of all the factors McKinsey tested, that intentional redesign was among the strongest contributors to meaningful impact.
Redesigning a workflow means deciding, explicitly, how a piece of work should be done and writing that decision down where it can be executed. That artifact is the skill. An organization that cannot express its capability in transferable units has no medium in which to redesign anything; it can only tune individual workers, one at a time, and hope the tuning holds.
Where skills come from
Authored does not mean invented in a conference room. In practice skills arrive from a few directions. Some are written deliberately by the team that owns the work. Others get captured from the person who does the job today, which is often the fastest path and the most honest one. A few are adapted from a standard the organization already trusts.
And some are proposed by the specialist itself, drawn from what it earned doing the work. That last path is the promotion loop the previous piece described: the specialist notices something durable, puts it forward, and a person decides whether it becomes part of how the business operates. The skill is what that decision produces. Earned knowledge, once reviewed, becomes authored capability.
What this is really about
A capability you cannot point to is a capability you cannot govern, cannot transfer, and cannot improve except by hand. Teams feel this as repetition: the same capability rebuilt for every new specialist, the same fix applied worker by worker.
My advice is unglamorous. Write the capability down as a unit. Review it like you mean it. Hand it to every worker whose role warrants it, and improve it in one place.
Teach it once. Equip as many as the work requires.
Chief Services Architect, Arkane Digital
Uy architects AI-driven systems with a focus on integration, infrastructure, and reliability—ensuring solutions are scalable and production-ready.