How to write a training needs analysis for AI agents

Write the analysis from the agents outward. List each agent's capabilities and the depth of each, then every role that decides, reviews, builds or oversees that work. For each role, state the skills it needs, test what people know now, and assign training to close the gap, starting with whoever approves held actions. Record the evidence that each gap closed.

What is a training needs analysis for agents, and who owns it?

A training needs analysis compares the skills a job requires with the skills people have, and plans how to close the difference. For agents, the job has changed shape. People now review drafts, decide held actions, explain refusals, read the workspace, write reasons that teach the agent, and respond when a certificate lapses. A conventional analysis built on old job descriptions misses most of that.

The learning and development lead usually owns the document. The head of each function supplies the role detail. Risk or compliance reviews it, because training is one of the controls an auditor will ask about. In EU markets, the EU AI Act's Article 4 asks providers and deployers to ensure a sufficient level of AI literacy among staff dealing with AI systems, which a well-kept analysis helps to show.

Why start from the agents rather than the org chart?

Because the agent determines what people must decide. An agent that drafts replies at depth 2 creates reviewers. One that moves money at depth 4 creates approvers of held payments and people who must recognise manipulation. One that coordinates other agents at depth 5 creates a need for people who understand the whole chain.

Starting from the org chart produces generic training for everyone. Starting from the agents produces precise training for the people whose decisions carry weight.

The steps

1. Agent, depth 1: lists each agent's capabilities, the depth of each, the business's limits, and current certificate expiry dates, from the workspace.
2. Person (L&D lead with function heads): maps roles to each capability in five relationships: uses the output, reviews drafts, decides held actions, builds or certifies the agent, oversees the deployment.
3. Person (function heads): states the required skills for each relationship, in plain terms. For example, a reviewer must read provenance, tell refused from withheld and write a reason a colleague can follow.
4. Person (L&D lead): measures current skill, using a short test set in the team's own industry, a learning needs survey and a sample of real decisions where agents are already live.
5. Person (L&D lead): records the gap for each role and person.
6. Person (L&D lead): assigns training to each gap, matched to the relationship: foundations for users, operator-level training and a practicum for reviewers and approvers, deeper build and certification training for builders, and governance-level training for those who oversee regulated, multi-agent deployments.
7. Person (risk lead): prioritises by consequence: approvers of held actions and anyone who can move money or change records go first.
8. Person (L&D lead): sets the evidence of completion and renewal dates for each role.
9. Agent, depth 2: drafts the quarterly refresh of the analysis from changes in capabilities, depth and staffing; the L&D lead reviews it.

Which roles and skills should the analysis cover?

A workable map, written as a list rather than a matrix, so each line can be read on its own:

• Executives and buyers: why agents must be governed, depth and certification, what the business pays for, data ownership. Evidence: a foundations-level badge.
• Users of agent output: the four verdicts, what to do with a refusal, when to ask for a person. Evidence: a foundations-level test.
• Reviewers and approvers: the decision chain, provenance, held and withheld actions, writing reasons, manipulation and pressure. Evidence: a written exam and a practicum on real decisions.
• Team leads: all of the above plus reading the workspace, running the daily rhythm and absorbing a sudden drop in an agent's depth. Evidence: the reviewer evidence plus observed leadership of the rhythm.
• Builders: designing briefs, choosing sources, setting bounds, preparing certification. Evidence: a certified capstone agent.
• Leaders of regulated, multi-agent deployments: governance, oversight across agents, audit readiness. Evidence: a capstone and an independent review.

Writing reasons deserves its own line in any analysis for reviewers; how to train reviewers to write reasons a colleague can follow shows why.

Which controls matter, and what evidence do they leave?

• Analysis tied to the workspace. Evidence: the capability inventory with its date and source.
• Approval rights following training. Evidence: the admin record showing that people with lapsed training cannot approve.
• Renewal schedule. Evidence: due dates per person.
• Quarterly refresh. Evidence: version history of the analysis.

What should you measure?

Roles mapped to every live capability. Gaps closed by due date. Approvers with current evidence. Test scores by concept before and after training. And decisions sampled from live work, which show whether training changed behaviour.

Where does it usually go wrong?

The analysis is written once for a launch and never refreshed. Agents gain capabilities and depth; the analysis must move with them.

Everyone gets the same course. Users are over-trained and approvers under-trained.

Evidence is attendance, not competence. A completion record proves someone sat a course; a practicum proves they can decide.

Pryme Intelligence Academy's four tracks, Foundations, Operator, Builder and Architect, follow this same split, and its free readiness assessment for teams of up to 25 shows scores by concept and the gaps. For definitions and formats, see what a training needs analysis is, what a training needs analysis for agents looks like and what a learning needs survey is. A ready-to-fill version is the training needs analysis template for AI agents. The guide to training teams for AI agents covers what to teach and who first.