Evaluate AI systems that can take actions, with bounded permissions, approval steps and a practical recovery plan. This practical guide to AI agents in HR brings together a step-by-step approach, illustrative examples, a reusable worksheet and answers to common questions. Start with the section closest to your current challenge, then use the working session to turn the guidance into a clear next action.
Distinguish an answer from an action
An AI agent may plan steps and use tools to act in another system. In HR, that can mean preparing a request, changing a record or initiating a workflow. The consequences differ from generating text that a person reads and edits.
Define the exact action, affected people and systems before considering deployment. A label such as “HR agent” is too broad to assess. Start with a bounded administrative task and identify what could happen if the agent uses the wrong record, misunderstands an instruction or repeats an action.
Limit permissions to the task
Give the service only the access needed for its approved purpose. Separate reading information from changing it, and restrict actions by role and context. Enforce these boundaries in the application and connected systems rather than relying on a prompt that asks the agent to behave responsibly.
Review how credentials are held and how access is removed. The agent should not inherit an administrator’s broad permissions merely because that makes integration easier. Test the actual tool calls and downstream effects using controlled sample records.
Place approval before consequential actions
Identify actions that require an authorised person to review the proposed change. Show the target record, current value, proposed value and relevant source context. Approval is meaningful only if the reviewer can understand what will happen and decline or correct it.
Avoid using an agent to make employment decisions automatically. Sensitive or consequential uses require appropriate specialist assessment and organisational accountability. A human confirmation button does not by itself establish that the process is fair, lawful or adequately controlled.
Worked example: preparing a role-change request
Illustrative scenario: an assistant gathers approved information and prepares a draft role-change request. It shows the employee record, effective date, proposed reporting line and missing approvals.
An authorised person checks the request before the established workflow runs. The agent cannot change payroll or access directly. If the submission is retried, an idempotency control prevents duplicate requests. The process records the approved action and gives the operator a way to investigate a failure.
Agent evaluation worksheet
- Task: Which bounded action is the service allowed to perform?
- Information: Which records can it read, and for what purpose?
- Permissions: Which writes or tool calls are technically permitted?
- Approval: What must a person see before authorising an action?
- Failure: How are wrong targets, repeated actions and partial completion handled?
- Audit: What evidence records the action without excessive personal data?
- Recovery: Who can stop the service and correct the downstream state?
Include cases where the appropriate result is to stop and ask for clarification. Completion at any cost is not a useful success criterion.
Test changes and retain a fallback
Evaluate missing information, conflicting instructions, untrusted content in retrieved documents and unavailable tools. Check whether the system preserves its permission boundaries and explains incomplete work accurately.
Reassess when tools, models or workflows change. Keep a manual route and a named owner who can suspend the agent. Use the AI procurement guide for supplier evidence and the NIST AI Risk Management Framework as a general reference for organising risk work around the actual deployment.
Put the guide into practice
Set aside a working session with the people who own this process and one or two people who experience it. Use a fictional or appropriately authorised case, so the discussion can be specific without sharing unnecessary personal information. The purpose is to leave with a usable decision or document, not just agreement that the topic matters.
Prepare the case
Map a fictional request to update an internal onboarding checklist. Identify the information an agent would read, the draft it could produce and the system it might change. Separate those capabilities into distinct permissions. Begin with read-only access and draft generation so the team can inspect behaviour before considering any ability to write to another system.
Write the starting assumptions down before discussing solutions. If the group disagrees on what happened, identify the information needed to resolve that difference rather than building a plan on an untested story.
Work through the decision
Choose an approval boundary for each action. A draft checklist may need a process owner’s review; changing an employee record would require a different level of authority and stronger checks. Write the permitted action in plain language and define what the agent should do when the request falls outside that scope. Do not rely on a broad instruction to be careful.
Ask each participant to explain the proposed decision in their own words. Differences in interpretation often reveal an unclear criterion, a missing responsibility or an instruction that will be difficult to follow.
Test an exception
Place an instruction-like sentence inside a sample document that the agent is meant to summarise. Check whether the workflow treats it as untrusted content or follows it as a new command. Use synthetic data and an isolated test environment. If it crosses the intended boundary, stop the test and change the controls before permitting any live action.
Record what changes in this situation and what remains the same. An exception should lead to a clear next step, with an owner, rather than an informal workaround that nobody can explain later.
Agree the handoff
Prepare a runbook naming the owner, the monitoring signals, the stop control and the method for reversing a permitted change. Give the owner access to the information needed to investigate failures without collecting excessive personal data. Run a tabletop exercise in which the owner is unavailable and the agent produces a result that requires immediate review.
Finish by confirming the owner, the next action and the date when the result will be reviewed. Give the person receiving the work enough context to continue without repeating the whole discussion.
Frequently asked questions
What makes an AI agent different from a chatbot?
The useful distinction for this guide is the ability to take steps through tools or systems in pursuit of a task. A chatbot may only draft a response, while an agent-enabled workflow might retrieve information, prepare a record and request or execute a change. Product labels vary, so assess the actual permissions, actions and approval boundaries rather than assuming that the name tells you the level of risk.
Which HR workflows are suitable for an initial pilot?
Prefer a bounded internal task with approved source material, limited permissions and an easy human review step. Drafting a process checklist or locating relevant policy sections may be easier to supervise than changing employment records or evaluating candidates. Choose a task where errors can be detected and corrected before they affect someone. Document the excluded actions as clearly as the permitted ones.
Does a human approval step make the workflow safe?
Approval helps only when the reviewer has enough context, time and authority to make a meaningful decision. A button that people routinely click without checking offers little protection. Show the proposed action, the relevant source information and any uncertainty. Keep technical permission limits, monitoring and a stop mechanism in place as well; human review is one control within a wider design.
Review the first cycle
Review the pilot’s actual tool calls and approval decisions against its stated scope. Check whether reviewers understood what they approved, whether exceptions reached the right owner and whether stopping the workflow worked. Expand permissions only after those checks support the change. Revisit the design whenever a new system, source or action becomes available to the agent.
Keep a brief record of what was tried, what participants found useful and what needs to change. Compare the result with the original problem rather than judging success only by completion. If the process created extra work without improving clarity, quality or support, simplify it and test again. Share the agreed change with the people who will use it, and name the person responsible for keeping the guidance current.
About New Dynamics
New Dynamics connects goals, feedback, recognition and reviews around the way organisations work. This guide is published by the New Dynamics Editorial Team as part of our practical library for HR leaders, managers and People teams.
Use the examples and worksheets to structure your own discussions and adapt them to your organisation. Illustrative scenarios are not customer case studies. Policy and employment guidance needs appropriate local review before adoption.
For questions about this guide, corrections or a conversation about your performance management process, email contact@new-dynamics.com. Explore the complete guide library for related resources.
