When an AI agent uses a skills profile to determine who gets seen for an opportunity, that profile is no longer just HR data. It is part of a talent decision.
That changes the architecture the organization needs beneath it.
A shared taxonomy can help people speak the same language. A skills profile can improve visibility. A matching engine can surface possibilities. But none of those, on its own, establishes whether the evidence behind a skill claim is sufficient for a decision—or whether an agent has permission to act on it.
The question for enterprise leaders is becoming more consequential:
What must be true of our skills system before an agent is allowed to act on it?
Prefer a version you can share with your team? Download the point of view (PDF).
What it means for the HCM to become an agent runtime
We have traditionally described the human capital management system—the HCM—as a system of record. It maintains information about jobs, positions, people, performance, learning, and skills.
As software agents become part of talent workflows, that environment can also support interpreting information, applying rules, recommending actions, and initiating work.
That is what I mean by an agent runtime: an environment in which software agents can access approved data and tools to carry out work within defined controls.
This is an architectural direction, not a claim that every HCM currently supports the same degree of autonomy. Some agents operate inside the core platform. Others connect recruiting, learning, mobility, and workforce-planning systems. The runtime may span several products rather than reside in a single suite.
Wherever the agent sits, the enterprise needs to preserve the relationship between what a skill means, what supports the claim, what decisions that evidence may influence, and what actions the agent may take.
A skill claim is not permission to make a decision
Consider an illustrative internal-mobility example.
An employee’s profile suggests commercial forecasting experience. The claim was inferred from a previous role; it has not been validated through assessment or observed performance.
An agent uses that signal to suggest a project the employee might explore. That may be a useful way to expand discovery.
Now suppose the same workflow removes another employee from consideration because their profile contains no forecasting evidence.
The system has crossed a boundary: from identifying a possibility to restricting access. Missing evidence has become a judgment about capability.
Unknown is not the same as incapable. Inferred is not the same as demonstrated.
The problem is not simply data accuracy. It is the relationship between evidence, purpose, and consequence.
Evidence adequate for recommending optional learning may be inadequate for selection into critical work. A profile built for career exploration should not automatically become an input to performance evaluation or separation decisions. A different use requires an explicit review of evidence standards, authority, and applicable obligations.
The four layers of an agent-ready skills system
An agent-ready skills architecture needs four connected layers. They do not have to live in one platform, but their relationships and ownership must be explicit.
1. Skills architecture: What does capability mean?
A skill label needs enough context to guide a decision.
“Data analysis” might mean interpreting a standard dashboard, investigating an operational problem, or building a forecasting model. Those expectations are not interchangeable.
This layer defines skills and their relationships to tasks, roles, work outcomes, and observable proficiency. It also establishes ownership, versioning, and mappings between enterprise terminology and professional or vendor-defined models.
The goal is not one enormous list that replaces every domain vocabulary. It is a governed way to relate those vocabularies without losing the context that makes capability meaningful.
2. Skills evidence architecture: Why do we believe the claim?
Self-asserted, manager-observed, assessed, credentialed, work-derived, and AI-inferred claims represent different kinds of evidence. They should remain distinguishable throughout the workflow.
For each material claim, preserve the source, date, work context, validation method, and limitations. Record proficiency separately from confidence: an agent’s confidence that a claim is plausible is not evidence of a particular proficiency level.
Evidence types are not a universal ranking. An assessment may be poorly matched to the work; a recent work sample may be highly relevant. Fitness for the intended decision matters more than the evidence label alone.
Inference remains valuable. It can reveal potential that formal records miss. The control is to prevent a useful possibility from silently becoming a verified fact.
3. Decision governance: What may the evidence influence?
The organization needs explicit rules connecting evidence to decision consequences.
Which claims may support opportunity discovery? Which may influence hiring, advancement, succession, or separation? What additional corroboration is required when the consequences increase?
“Human in the loop” is not a complete answer. A reviewer needs relevant evidence, time to assess it, authority to challenge the recommendation, and a defined responsibility. An approval button alone does not create meaningful oversight.
This layer also establishes permitted purposes, exception handling, monitoring, and processes for people to correct or challenge inaccurate data and its use.
4. Activation architecture: What may the agent do?
Permission to read a skills profile is not permission to change it. Permission to recommend an opportunity is not permission to change eligibility or execute a talent decision.
This layer defines agent identity, approved data sources, read and write permissions, permitted actions, approval gates, escalation paths, logging, monitoring, and suspension.
It also establishes where new inferences are stored and how corrections reach connected systems. A corrected source profile provides little protection if an agent continues using an older derived score elsewhere.
The important distinction is between a policy the organization has written and a control the system actually enforces.
What implementation looks like
The four layers are not four software purchases. They are four sets of responsibilities that must be implemented across technology and the operating model.
Some elements are metadata: skill identifiers, definition versions, evidence sources, dates, work context, and validation status.
Some are business rules: which evidence is acceptable for a particular purpose, when corroboration is required, and when the workflow must stop.
Others are technical controls: permissions, approval workflows, integrations, audit records, and mechanisms to disable an agent or revoke an action.
And some remain organizational responsibilities: defining capability, approving evidence standards, reviewing exceptions, correcting errors, and evaluating outcomes.
Layer | What is stored or configured | What people must own |
|---|---|---|
Skills architecture | Definitions, identifiers, relationships, proficiency context, mappings, versions | Business meaning, stewardship, and approval of changes |
Skills evidence architecture |
Source, date, context, validation status, confidence, and use restrictions |
Evidence standards, validation methods, and correction processes |
Decision governance |
Purpose-specific rules, thresholds, review triggers, and retention requirements |
Decision rights, review responsibilities, exceptions, and challenge processes |
Activation architecture |
Agent permissions, workflows, integrations, logging, and monitoring |
Agent ownership, release approval, incident response, and suspension decisions |
Not every platform exposes all of these controls. Where a critical rule cannot be enforced reliably, narrow the use case or retain a controlled manual step rather than assume the agent will follow a written policy.
Nor does every organization need a new governance committee. Start by assigning these responsibilities across existing business capability owners, talent-process owners, skills architecture, HRIT, data governance, AI governance, and legal or employee-relations partners.
The objective is clear decision rights—not another layer of meetings.
Make the skills-to-agent contract explicit
A practical implementation device is a skills-to-agent contract: a specification that connects an agent’s business purpose to the evidence, rules, and permissions it must respect.
For the internal-mobility example, that specification might say:
- Purpose: Help employees discover relevant projects.
- Evidence: Use approved profile information and clearly identified inferences; do not treat missing evidence as proof of inability.
- Authority: Suggest opportunities, but do not automatically exclude people or change eligibility.
- Write permissions: Store new inferences separately from validated claims and preserve their source.
- Review: Escalate conflicts or proposed eligibility changes to the designated talent-process owner.
- Traceability: Retain the relevant inputs, definition versions, rule or model versions, actions, and human interventions, subject to access and retention controls.
- Correction: Update or invalidate affected derived records and re-evaluate recommendations when material evidence changes.
This is more than a document. Its enforceable requirements must be translated into permissions, validation checks, workflow gates, tests, and monitoring. Prompt instructions can help guide behavior, but they are not a substitute for access controls.
A fluent explanation is not the same as a defensible decision record, either. The organization needs traceable inputs and actions—not a generated rationale treated as proof that the evidence was appropriate.
Start with one bounded workflow
Organizations do not need to perfect an enterprise-wide taxonomy before making progress. They do need to limit deployment to what their evidence and controls can support.
Choose one workflow, such as project discovery or a role-specific development recommendation, and work through five steps:
- Define the decision and its boundaries. Identify the outcome, affected people, accountable owner, and actions that remain out of scope.
- Specify the minimum evidence. Define relevant capability, acceptable sources, context, freshness, and treatment of unknown or conflicting information.
- Map the rules to enforceable controls. Identify what belongs in metadata, permissions, workflow configuration, and human review.
- Test the difficult cases. Include stale profiles, unsupported inferences, missing evidence, corrections, conflicting records, and actions beyond the agent’s authority.
- Evaluate outcomes before widening autonomy. Assess decision quality, opportunity access, overrides, correction handling, and operational value—not just time saved or agent activity.
For organizations moving from skills pilots to scale, the standard is straightforward: prove not only that skills improve a decision, but that the conditions supporting that decision can be maintained when systems repeat it.
The leadership question has changed
The opportunity is a talent system that responds more effectively to changing work and capability needs: better discovery, more relevant development, and faster coordination across talent processes.
But activating agents and building an agent-ready skills system are not the same thing.
Ask your team:
- Where are inferred skills being treated as demonstrated proficiency?
- Who authorizes the transition from a recommendation to an action?
- When someone corrects a claim, can we identify and correct the decisions or derived records it affected?
The architecture question is no longer simply, “Do we have a common language for skills?”
It is, “Can we use that language to guide action without exceeding the meaning, evidence, or authority behind it?”
That is the standard an agent-ready skills architecture needs to meet.
Make the next skills decision with greater clarity
If an agent rollout, skills-platform investment, or talent pilot is exposing gaps between capability definitions, evidence, and decision ownership, the next step is to clarify the decision—not automatically expand the technology investment.
The Skills Decision Brief™ is a fixed-scope advisory engagement designed to clarify priorities, sequencing, and investment decisions before a larger skills commitment.
Explore the Skills Decision Brief™
Bringing this discussion to your leadership team? Download the point of view (PDF) for internal reading and discussion.
About the author
Brian Richardson is Founder and CEO of Richardson Consulting Group and an Enterprise Skills / Capability Systems Architect. He helps large organizations connect skills strategy, capability architecture, governance, and talent practices.
For more perspectives on enterprise skills and talent decisions, subscribe to The Skinny on Skills on LinkedIn.