Your organisation does not have an AI skills problem. It has three populations and no shared capability system.
People who use agents, people who supervise them, and the agents themselves need to be developed against the same capability definitions, in the same system, with the same evidence. This practice builds that — and it is structured so your own teams own it within a year, not depend on us indefinitely.
Three carriers
Employees, external partners and digital employees are developed in one system, not three separate initiatives.
Three new roles
Agent Owner, Agent Engineer and AI Steward, defined with competencies, not job titles.
Four learning modes
Microlearning, simulation, shadow mode and coaching on the job — in that order of difficulty.
Measured by performance
Time to competence, shadow-period error rate and post-deployment performance, not attendance.
Three capability carriers, one competency architecture
The three populations need different capabilities, but they share a common architecture: knowledge, skills, judgement, evidence. Building three separate curricula produces three separate standards, and then the agent and its supervisor are operating to different definitions of quality — which is the failure we are trying to prevent.
| Capability domain | Employees | External partners | Digital employees |
|---|---|---|---|
| Knowledge | Domain and process knowledge, plus the organisation's business definitions and the reasoning behind them | Product, policy and process knowledge needed to act correctly on your behalf, in your systems | Curated, owned and versioned knowledge: reference data, policy, precedent, and the rules in the semantic layer |
| Skills | Operating the agent, reviewing its output, handling escalations, and knowing when not to use it | Performing the delegated activity to your standard, within your tooling, to your evidence requirements | Tool use, orchestration patterns, retrieval discipline, formatting and protocol conformance |
| Judgement | When to trust the agent, when to override it, and how to tell the difference between a good answer and a plausible one | Judgement at the boundary of your process: when to seek help, when to stop, what never to do | Threshold reasoning, escalation discipline, refusing when the context is insufficient |
| Evidence | Activity, assessment and capability records proving they can perform the work unsupervised | Certification and evidence that they are qualified to work in your process, auditable by you | Evaluation sets, regression results, decision logs and a performance record reviewed on a cycle |
| Governance | Understanding what they are accountable for, what they may authorise, and how to raise a concern | Data handling, conduct and escalation obligations inside a process they do not own | A mandate, a tier, an expiry date, a named owner and the right to be suspended |
Why the digital-employee row is not a footnote. A digital employee that has never been onboarded is a liability with system access. It has no evaluation set, no performance history, no defined boundaries and no record of what it is allowed to do. Every element in that row is a piece of apparatus we would demand of a human hire — and building it is a learning design problem, not a configuration problem.
Agentic skills in numbers
Employees, external partners, digital employees
Every one has an owner, and every one expires
And the job descriptions that have to change with them
Not completion rates
Three capability carriers, one competency architecture
Most organisations build a curriculum for employees and stop. An agentic business touches external partners and digital employees too — and those two populations are where the risk concentrates.
- Need to supervise agents, not just use tools
- Their job descriptions change, not just their skills
- Some become agent owners — a role that did not exist
- Some become agentic skill authors, capturing what they know
- Judgement under new conditions is the actual capability gap
- Training must be evidenced in the LMS for governance, not for reporting
- The population nobody owns, inside the process that matters most
- They touch your customers and your data, often with less training than your own staff
- Scoping their access is a technical control; enabling them is a learning problem
- Partner enablement is usually owned by nobody, which is why it usually does not happen
- Their training record is your evidence when something goes wrong
- Treating partners as an afterthought is the most common finding in our assessments
Six artefacts, all of which have owners and all of which expire
We build a digital employee's onboarding pack with the same rigour as a human one, because the same failure modes apply. An agent without these six things is running in your systems on somebody's optimism.
Knowledge pack
The curated corpus it is entitled to use, with provenance, freshness dates and the steward responsible for each part. Not a link to a shared drive.
Skill and tool manifest
Every operation it may call, its class, its parameter envelopes, and the systems it may write to. Enumerated and versioned.
Evaluation set
Real cases with business-written expected outcomes, including the difficult ones and the historical failures, plus the pass threshold that permits it to operate.
Permission boundary
An identity of its own, scoped to the task, with read and write capabilities separated, and credentials held outside its own context.
Mandate and expiry
What it may decide, the thresholds within which it may act, the escalation conditions, and the date on which its authority lapses unless renewed.
Performance record
Outcomes, escalation precision, exception rate, review findings and the changes made to it — the digital equivalent of a performance file.
The seventh artefact, which is why learning matters
The compliance evidence pack is assembled from the six above, and it is the point at which the learning system stops being a development tool and becomes a governance instrument. For every agent in the estate, the organisation must be able to show: what it was trained on, what it is permitted to do, how it was tested, who owns it, and what it has done since.
That evidence is generated automatically when the learning and evaluation systems are integrated, and assembled by hand — painfully, expensively and inconsistently — when they are not. This is the practical reason the two practices belong together.
Positioning. Training is not what makes an agent reliable — evaluation and governance do. Training is what makes the humans around it reliable, which is the part nobody can skip.
Six artefacts, all of which have owners and all of which expire
A competency architecture that is not owned expires. So does one with no review date. These six are the minimum for an agentic business to be able to evidence its own capability.
| Artefact | What it is | Who owns it | When it expires |
|---|---|---|---|
| Competency architecture | The map of what each role must be able to do, at what depth, with what authority | CHRO with the operating model owner | Reviewed annually; changed by business change |
| Role specifications | Job descriptions rewritten for human–machine collaboration, including what the person no longer does | Function heads | On every operating model change |
| Agent job descriptions | The agent's purpose, non-goals, authority tier, approver and evaluation threshold | Named agent owner | Reviewed at every threshold review |
| Capability assessment | A live measure of what each population can actually do, evidenced in the LMS | L&D lead with function heads | Continuous; formal assessment twice a year |
| Skill library | Authored skills the agents use, versioned, with usage and failure data attached | Agent owners with L&D | Every skill has a review date |
| Training and enablement plan | The curriculum by population, with the evidence requirement stated per item | L&D lead with risk | Annually, and on every material change |
Three roles that did not exist, and the job descriptions that have to change with them
Deploying agents without new roles is how organisations end up with a central team that becomes a bottleneck, or with business units that each build their own and nobody can govern. We define the three roles that carry the work, then re-describe the roles that sit next to them.
Agent Owner — accountable for the outcome
Sits in the business, not in IT. Owns the delegated work: defines the units, sets the thresholds, approves releases, reviews exceptions, signs the business result and carries the consequence when it is wrong. This is the role that most organisations believe exists and in practice is shared between a product manager and a duty manager, which means nobody owns it.
- Competency evidence — able to decompose a process into delegable units, write an acceptance test, and judge whether an agent's output meets the business standard.
- Authority — holds the mandate, and can raise, lower or revoke an agent's tier within the mandate granted by the committee.
- Judgement — distinguishes a good answer from a plausible one, and knows which errors in their domain are expensive.
- Typical background — an experienced operations or process lead, not a graduate of a technical programme.
How we choose the first ten
We look for people who already hold a process and understand where it breaks. The Agent Owner is usually the person currently receiving the escalations — which means the first agent often improves their own day before it saves anyone money, and that is a much easier change to make.
We assess candidates on a real process with a real agent output, not on a quiz. The assessment is the work.
Agent Engineer — builds, evaluates and operates
The technical counterpart. Designs the tool contracts, tunes the context pipeline, writes the evaluation set with the business, versions the parameters, deploys, monitors and troubleshoots. Grounded in software engineering practice, but explicitly not a generalist developer — the work is mostly about constraints, retrieval, evaluation and failure analysis rather than application features.
- Competency evidence — can build an agent that writes to a system of record, with a proper evaluation harness, a trace and a rollback.
- Authority — owns the technical design, proposes the tier, and can block a release that has not passed the regression set.
- Judgement — reads a failure trace and names the responsible layer, rather than reaching for a prompt change first.
- Typical background — platform, integration or data engineering, with a deliberate ramp on evaluation and retrieval tuning.
Central or embedded — and the trade-off
A central pool produces consistency and slow throughput. Embedded engineers produce speed and divergent standards. We usually recommend a small central team that owns the shared platform capability and the evaluation harness, with embedded engineers who own individual agents — and a rule that the central team publishes the paved road rather than mandating the design of every agent.
AI Steward — keeps the estate honest
The role that sits between the business and the platform and protects the organisation from itself. Maintains the inventory, applies the classification, runs the control tests, prepares the evidence for audit, tracks vendor and third-party risk, and — most importantly — keeps the estate visible. Most enterprise risk from agents comes from things nobody registered.
- Competency evidence — runs the management system, prepares audit evidence, and can describe the estate and its risks without preparing.
- Authority — enforces the inventory, the tiering rules and the evidence requirements, and can refuse a deployment that does not meet them.
- Judgement — distinguishes a control that is exercised from a control that merely exists, which is the distinction auditors test for.
- Typical background — risk, audit, information security or compliance, with a specific ramp on how agents actually fail.
They must be able to say no
The Steward cannot report to the team that builds agents without losing the ability to refuse a release. This is a small organisational decision with a large effect on whether the governance is real, and it should be made at the start rather than discovered at the first audit.
Governance practice →Three roles that did not exist, and the job descriptions that have to change with them
Every one of these is filled by someone already doing the work informally. The change is naming it, giving it authority, and making it accountable.
Agent owner
Accountable for one agent in production: its scope, its authority tier, its evaluation threshold, its cost, and its retirement. Usually a senior practitioner rather than a new hire — the judgement already exists, the title does not.
Agentic skill author
Captures how an experienced operator actually handles exceptions, and publishes it as a versioned skill with an owner and a review date. This is the mechanism that turns your best people into organisational capability.
Workforce capability partner
Sits between L&D and the business, translating the operating model into capability requirements and the capability gaps back into operating model changes. Usually the most contested role, and the most useful.
From job description to human–machine collaboration specification
A traditional job description states responsibilities. A collaboration specification states, for each unit of work: who holds it, what the machine contributes, what the human contributes, what the handover looks like, and how the quality of the combined output is judged.
When this is done properly, the job changes shape — usually reducing the volume of production work and increasing the volume of exception work, review and judgement. The organisation has to decide what people do with that, and that decision is the real output of the redesign.
The question boards skip. If the agent handles the routine work, what does the released capacity go to? Capacity that is not redeployed into better work produces a cost reduction and nothing else — and the workforce will find that out, with or without a plan.
What a redesigned role looks like
| Element | What it states |
|---|---|
| Unit of work | The specific piece of work, with its input contract and acceptance test |
| Machine contribution | What the agent does, at what authority tier, with what supervision |
| Human contribution | What the person does: prepare, review, decide, approve, or handle the exception |
| Handover | What crosses between them, in what form, and what the human needs in order to act in under two minutes |
| Standard of the combined output | How the joint result is judged, and against what the outcome is measured |
| Escalation | When the person takes it back, and what they are accountable for when they do |
| Capacity redeployment | Where the released time goes — a named destination, reviewed like any other commitment |
| Competency requirement | What the person must be able to do now that they could not do before, and how that is evidenced |
The last two rows are where the learning programme is generated from. We do not design a course catalogue and then look for jobs to attach it to; the capability requirement is derived from the redesigned work, and the learning follows.
From job description to human–machine collaboration specification
This is the document most organisations need and almost none have. Without it, the first serious agent decision exposes that nobody agreed what the person's job now is.
- Responsibilities: what the person does
- Qualifications: what they know before starting
- Reports to: who they escalate to
- Performance measured on individual output
- Unchanged for a decade, occasionally refreshed
- Decisions delegated to agents, at which authority tier
- Decisions reserved to the person, and why
- Escalation rules they must recognise and act on
- Approval obligations: what they must review, and at what sampling rate
- Judgement calls they own that the agent must never make
- Capability required to do all of that, evidenced not assumed
Four modes, in order of difficulty
Most enterprise AI training is delivered in one mode — the workshop or the course. That works for awareness and fails for competence, because competence in a supervised machine colleague is built by doing the work under progressively less scaffolding, not by having the principles explained once.
Microlearning
Short, specific, delivered in the flow of work. One concept, one workflow, one screen at a time. This is where vocabulary and the operating rules live, and it exists to make the other three modes effective rather than to carry the learning itself.
Scenario simulation
Full-flow simulations against realistic cases, including the awkward ones — the exception, the missing document, the customer who is angry, the case that must be refused. Deliberate practice in a safe environment, scored against the same acceptance tests the agent is held to.
Shadow mode
The person works alongside the live agent, comparing decisions case by case. It is the most valuable and least comfortable mode, because every divergence is visible to both parties. It also produces the best error analysis available anywhere in the programme.
Coaching on the job
A named internal coach inside the business, reviewing real work as it happens and correcting in the moment. This is the mode that determines whether capability survives the end of the programme, and it is the one most often left out because it does not scale as a catalogue.
The progression is not optional
A person who has only been told how the agent works will either trust it too much or not at all, and neither failure is a training problem at that point — it is a design problem. Shadow mode exists because the judgement of "is this answer as good as mine?" cannot be taught, only practised against the real thing.
The proportion differs sharply by role. A supervisor needs most of their time in shadow mode and coaching. An Agent Owner needs a different balance, weighted toward defining acceptance tests and reviewing the cases the escalation queue sends them. An occasional user of a drafting agent needs microlearning and a rule for when not to use it.
Where the records live
Every mode in this progression produces a record: the simulation scores, the shadow-mode comparisons, the coaching notes, the assessment outcome. Those records are held in the learning system of record alongside an individual's employment and competency history — so the same system answers "is this person qualified" and "is this agent permitted to act" with the same standard of evidence.
Four modes, in order of difficulty
Capability requirements rise steeply with mode. Training designed for mode 1 does not prepare anyone for mode 3, and this mismatch is the most common cause of post-go-live resistance.
The agent assists; the person does the work. Lowest risk, fastest to deploy, and where most first projects should start. The capability gap is usually smaller than organisations expect.
The agent prepares and submits; the person approves. The capability shift is real: the person must judge output rather than produce it, which is a different skill and an uncomfortable one for experienced staff.
The person sets the boundary and monitors; the agent acts inside it. The person needs judgement about when the boundary is wrong — which is the hardest capability to teach and the hardest to hire for.
The person designs workflows and supervises agents rather than executing. A fundamentally different job, and only appropriate for a small number of roles. Most organisations should not attempt this broadly yet.
The population nobody owns, inside the process that matters most
Channels, suppliers, BPO partners and franchisees touch your customers on your behalf. They are inside your process and outside your control. Every enterprise we work with has a customer-facing step performed by a partner who has not been briefed on the current policy — and the agent estate makes that worse, because the agent expects a level of data discipline the partner has never been asked to provide.
Divergent definitions at the boundary
Your partner uses a different meaning of a key term, and the difference only surfaces in a customer complaint. Enablement must cover the definitions, not just the procedure.
Data quality you do not control
The agent's accuracy is limited by the quality of what the partner submits. Where that is weak, the fix is a partner data standard, not a better prompt.
No evidence of qualification
You cannot demonstrate to a regulator or a customer that the people handling your case were qualified. Certification, scoped to the activity, is the artefact.
What we build for partners
- A qualification standard — what a partner role is competent to do in your process, expressed as observable performance, with the assessment that demonstrates it.
- Scenario-based enablement — the same realistic cases your agents handle, so a partner and a digital employee are being developed against the same definition of correct.
- Certification with expiry — valid for a defined period, tied to a required refresh, and revocable. It is a qualification record, not a completion certificate.
- An interface contract for data — what the partner must supply, in what form, to what standard, and what happens when the standard is not met.
- Escalation into your operation — a defined path for the partner to reach a human in your organisation when the agent and the partner both cannot resolve the case.
Partners are a capability carrier, not a supplier category
The moment a partner performs part of your process, they hold capability that your customer experience depends on and your risk register does not. Treating them as a capability carrier — with the same standards, the same evidence and the same review cycle as your own employees and your agents — is the only approach that holds up when a case goes wrong in front of a customer.
The third carrier is the one nobody plans for
Digital employees are managed as assets with a job description, a supervisor and a curriculum — or they are unowned software that quietly accumulates authority.
Digital employees need an onboarding curriculum
Not a deployment checklist. A curriculum: what the role is, what its boundaries are, what it must never do, who supervises it, and how it is evaluated. Delivered through the LMS like any other onboarding.
They need a performance record
Accuracy against threshold, escalation rate, override rate by approver, cost per task, and the failure clusters. Held over time, so a degrading agent is visible before someone complains.
They need a retirement plan
What happens when an agent is retired — where its knowledge goes, which decisions it made that need reviewing, and what the humans who relied on it now do. Nobody plans this, and everyone needs it.
Four numbers that tell you whether capability is real
Attendance and completion rates tell you that a course was delivered. Four other measures tell you whether the organisation can now operate the agent estate without us. We report these to the steering committee from the first cohort onwards.
| Measure | Definition | Read it as | Target direction |
|---|---|---|---|
| Capability baseline | Before training, the assessed performance on the real work with the real agent output, recorded per person and per role | Whether the gap you are closing is real and how large it is | Establishes the reference point; every later measure is relative to it |
| Time to competence | Elapsed time from enrolment to first independent, assessed performance at the required standard | How fast the organisation can produce a capable supervisor or owner | Falling as cohorts accumulate |
| Shadow-period error rate | During shadow mode, the rate at which the human and the agent would have taken materially different actions, and the rate at which the human was wrong | Where the agent is safe to release, and where it is not yet | Falling; and the human-error rate falling too, which is the sign the learning is real |
| Post-deployment performance | Outcome quality, cycle time, escalation precision and exception rate of each role and each agent, measured on the same shared scorecard | Whether capability survived the end of the programme and the departure of the coach | Stable or improving without central intervention |
Small and named
We start with the people who will supervise and own the first agents. They are the highest-value cohort, and their results set the reference for every cohort after.
The coach comes from inside
Our programme trains an internal coach as it runs. Without that, the capability is rented for the duration of our engagement and stops when it ends.
Then scale, with the coach
Subsequent cohorts are run by the internal coach with our materials and our assessment, and we sample the results to keep the standard comparable.
What we do not do
Training is the easiest part of this work to sell and the easiest to do badly. We are explicit about where we refuse to go.
- We do not run certification courses with no performance standard behind them. A certificate that a participant receives for attending a session is a completion record, not a capability record. If the only thing we can offer is attendance, we will say that this is not what the organisation needs.
- We do not run AI awareness bootcamps and call it capability building. Awareness has its place — everyone in an enterprise should know what the agents can and cannot do — but it does not produce supervisors, and it is not what a business owner should be buying when they are worried about reliability.
- We do not certify individuals to do work they have never been assessed on. Assessment is against the real work, with real cases, and it is held in a system of record that persists after the programme ends. We do not issue certificates that cannot be produced on request.
- We do not train the organisation to depend on us. Every cohort includes the training of an internal coach, and every engagement ends with a handover of materials, assessments and the capability to run the next cohort yourself. If a proposal does not include that, it is selling a subscription to our people rather than your capability.
Where the learning practice connects
Employees and digital employees
The argument for one capability system across both human and machine populations.
Custom courseware and simulation
How scenario simulations are built with your subject matter experts, and where the learning record lives.
Technical team training
The curriculum behind the build, evaluate and operate competencies above.
Operating model
Where the redesigned roles and their authority are connected to how work is delegated.
What we do not do
We are not a training vendor that also does AI. We do not sell completion-rate improvement, and we will not put a course in front of your people that we cannot evidence against a working behaviour. The uncomfortable part of this work is telling a function that its training budget has been spent on the wrong thing for a decade — and then building the replacement.
What this page answers
Every topic below is covered in the sections above, and each links to the page that goes deeper on it.
Bring us the role that has to change and nobody is sure how
A 45-minute working session with a learning lead. We will take one job, work out what the agent changes about it, and show you the competency gap that creates. You will know within the session whether this is a training problem, an operating model problem, or both.