Workforce Reskilling in the AI Era: Why Completion Rates Are Not the Outcome

Which three populations actually need reskilling?

Three, with different curricula, time commitments and sponsors. Attempting one programme for all three is the most common design error, and it produces a course too basic for the builders and too abstract for the users.

Population	Share of workforce	Core capability	What they must be able to do
Agent users and supervisors	The majority	Judgement and review	Decompose work into delegable and non-delegable parts, write a clear instruction, evaluate an agent's output critically, decide when not to delegate, and recognise a confidently wrong answer
Agent builders	A small, cross-functional group	Design and evaluation	Scope an agent's authority, build a retrieval pipeline, write an evaluation set, instrument a trace, and tune behaviour from failure evidence rather than intuition
Agent owners and governors	Per function, plus central specialists	Accountability and evidence	Define what an agent may decide, own its performance, produce evidence for review, and stop it when the risk changes

A fourth group deserves a mention because organisations consistently forget it: managers. A manager whose team's output is now partly produced by agents needs to review agent work as part of performance management, allocate between human and machine effort, and run a conversation about what a role is for when half of it has been automated. Managers are usually not sent on the agent curriculum at all, which is why programmes stall at the point where behaviour has to change in the flow of work. Our employees and digital employees capability practice treats all four populations as one framework with different requirement sets.

How do you design a competency framework for it?

The same discipline as any competency framework, applied to a moving target. What follows is the structure we use, and the element that most often breaks is the evidence rule.

Element	Example for the agent user population	Common failure
Capability	Delegating work to AI agents	Defined so broadly that nothing can be observed
Competency	Decomposes a defined work process into delegable and retained steps, and specifies each delegated step precisely enough for execution without clarification	Written as a noun — "prompting ability" — rather than an observable behaviour
Behaviour level	Awaiting, Contributing, Independently, Advising	Levels describing effort rather than scope and judgement
Proficiency dimension	Complexity of the process, ambiguity tolerated, number of systems involved, consequence of error	No assessor can apply it consistently between two observers
Evidence requirement	Observed decomposition of a live work process plus a reviewed set of delegated outputs with a recorded quality judgement	Set to "training completed" — which measures attendance, not capability
Role requirement	Customer-facing roles require Advising on delegation boundaries; processing roles require Contributing	Invented by one committee and never validated against real work

Two design rules specific to AI reskilling. First, add a fourth axis to the proficiency scale: cost of error. The same behaviour — approving an agent's output — carries a very different risk when the output is an internal draft versus a filing a regulator will read. Levels that ignore this produce technically capable, operationally reckless graduates.

Second, the framework must be machine-readable and versioned, because it has to work in two directions: tell a person what they must be able to do, and express the required capability of a digital employee in the same terms, so one framework covers both populations. Our article on the LMS vs TMS difference and why one employee record matters sets out the shared-record discipline this depends on.

Finally, plan for the framework to be wrong. Job content moves faster than a three-year-old matrix, and a framework that is not re-validated is a document — and a learning platform holding a document is a filing system.

How do you build practice that transfers to the job?

Four design elements, in increasing order of fidelity. Most programmes use only the first two, which is why the third and fourth matter to the outcome.

1. Concept and worked example. Necessary, insufficient. Use it for the vocabulary, the failure modes and the governance boundaries — what a person needs in order to reason about a decision, not just operate a tool.
2. Simulation with a live agent and bounded consequence. The learner delegates real work to a real agent inside a safe environment, judges the output, and sees the downstream effect of accepting a wrong answer. This is where judgement actually develops, because the feedback loop is real and the consequence is bounded by design.
3. Supported application on live work. The learner delegates real work, with a named reviewer, and logs the judgement they made. The evidence artefact for the competency framework comes from here, which is why it is the only element that satisfies a rigorous evidence requirement.

Two mechanics make this work. First, the simulation must have plausible wrong answers, because judgement is only practised against errors that could plausibly occur. Second, the learner's judgement must be recorded — which decision was delegated, which was retained, why, and whether the agent's output was accepted. That record is simultaneously the assessment evidence and the data that shows where the framework is wrong.

For the builder population, the same principle applies with a different medium: instead of a simulated business process, the exercise is a broken retrieval pipeline, a failing evaluation set, or an agent that produces confident nonsense, with the learner required to diagnose the layer. Diagnosing a failure is a much better test of understanding than reproducing a success.

How should the programme be sequenced?

Six steps, in this order, and the order is the argument.

1. Establish the baseline. What is delegated today, how often, with what quality and what correction rate. Without this, every later claim is unfalsifiable.
2. Build the competency framework for that process. Three or four competencies, observable behaviours, an evidence rule and a role requirement. Small and validated beats large and aspirational.
3. Redesign the target workflow. Pick one process where delegation is genuinely possible, and change the job description, review step and performance measure to match. Do this before any training, because otherwise the training has nothing to land on.
4. Pilot with one team. A real team, real work, a named owner, the simulation and the supported application sequence, and weekly review of the judgement being made.
5. Instrument the behaviour. Delegation rate, acceptance and correction rates, escalation reasons, and the failure taxonomy from the pilot. This becomes the data that shapes the framework and the curriculum for the next cohort.

Two final points. Do steps one and two before the programme is designed, not after — a reskilling programme that begins with a catalogue of courses has already lost the argument about what the work should become. And put the manager layer in at step six: managers are the mechanism by which a new way of working becomes the norm.

Where we draw the boundary

We are not a training vendor that sells content, and we will say so in scoping. If your bottleneck is a specific technical skill that a good course teaches well, a course is the right answer. The case for a full reskilling programme earns its cost when the work itself is being restructured around AI agents. Across Singapore, Hong Kong SAR and the wider Asia Pacific region, that is the common pattern we see in manufacturing, financial services and logistics. Our agentic skills and training practice and the enterprise AI, data and context engineering training practice are the two places this work sits.