A wrong ticket and a wrong pay change are different problems
An agent that files a wrong ticket in a service desk creates a visible problem with a cheap fix. The queue owner sees the noise and the record is corrected that day. An agent that changes a worker's compensation, job profile or employment status creates a problem the affected person may never see, and that surfaces months later in a grievance or an audit.
Most agent governance material treats every system the same way. Scope the service account, log the actions, add an approval step, build a kill switch. Those controls belong everywhere, including in the argument that agents need a pause button. They are not sufficient in a human capital system, where the failure modes differ in kind.
Agents doing retrieval and drafting in HR are genuinely useful, and nothing below argues against them. The bar rises at one line, and in HR that line sits earlier than most architects expect.
What makes worker data different from a purchase order
Start with what the worker can see, which is almost nothing. People see their own profile, their payslips and whatever self service exposes. They cannot see that an agent read their performance history or changed a field on their record overnight. In a sales system the account owner notices a wrong opportunity. In a Workday HCM tenant the subject of the record finds out last.
The legal weight differs too. Employment decisions attract scrutiny a purchase order never will: pay equity, discrimination, dismissal fairness and the rights people hold over their own data. A tribunal can ask an employer to explain the basis of a decision about a named individual, and a model output with an approval timestamp is a weak answer.
Correction is harder than people assume. Reversing a compensation change is different work from deleting a row. The payment may already have run, tax may already have been withheld, a benefits carrier may already hold a new enrolment. Depending on the modules a customer runs, undoing one field means a coordinated fix across payroll, benefits, finance and an outside provider.
The fourth property gets missed most often. An agent summarising a worker's file has assembled something no single screen ever showed: leave reasons beside performance ratings beside compensation history beside a manager's note. Each element may be legitimately visible to the person asking. The assembled picture may not be, which is one reason security group sprawl matters more once agents read for someone.
Agents that read, agents that draft and agents that act
The useful distinction in a design review separates agents that read, agents that draft and agents that act. Reading answers a question from data the requester could already have opened. Drafting produces something a human then sends or approves. Acting changes state, and state in a human capital tenant means someone's money, their job or their record.
The boundary belongs before anything that changes a worker's record or their pay. That line is easy to state and hard to hold, because the demos that win budget sit just past it. An agent that opens a job change and submits it carries the business case, and it is also the one that can be wrong quietly.
Drafting holds most of the real value and it survives scrutiny. An agent that prepares a job change for a manager to review leaves a human at the decision point. Whether your tenant expresses that boundary cleanly depends on your configuration, so ask whether the agent's authority is bounded by the same security model that bounds a person, or only by its instructions.
A review queue nobody can work is a rubber stamp
Human review is the control everyone claims and few build properly. The honest test has two parts. Does the reviewer see enough to judge the item, and does the reviewer have enough time to judge it.
Enough information means the proposed change, the current value, the data the agent used and the rule it believes it is applying. An approval card showing a pending job change with approve and deny buttons produces a click, which leaves the reviewer accountable for a decision they were never equipped to make.
Enough time is a volume problem. A queue that grows faster than reviewers can work it gets cleared in batches, and a batch approval is automation with a human name attached. That is worse than no automation at all, because the organisation now holds a documented human decision behind an unexamined change. If you cannot staff review at the volume the agent generates, cap the volume.
Sampling is an honest alternative where volume is genuinely high, provided you say so and record the rate. Reviewing every twentieth item properly beats pretending to review all of them. The handoff between human and agent work deserves as much design attention as the agent itself.
You should be able to say what the agent did and why
Traceability means answering three questions months later, in a room where the person asking is not on your side. What did the agent do. On what basis did it do it. Under whose authority did it act.
The first is usually easiest, since most platforms write something to an audit trail. The second is harder, because the basis includes the data the agent retrieved and the instruction it was following at the time, and instructions get edited. If you cannot reconstruct the prompt and policy in effect on the date in question, your answer has a hole in it.
The third question catches people out. An agent acting through a shared integration identity leaves a trail naming the integration rather than the manager who asked. Service account identity stays a dull topic until someone asks who approved a change to a named employee's pay and the answer is a system user.
An organisation that cannot answer all three should not enable the agent. That reads as severe until you notice it is the standard already applied to every human with the same access, whose account is provisioned, logged and attributable.
Works councils belong in the project schedule
In several European jurisdictions, and under collective agreements elsewhere, employee representative bodies hold a real right to be informed or consulted before an employer introduces a system that materially affects workers. Whether your deployment triggers that right depends on the country and on what the agent does, which makes it a question for employment counsel rather than the architecture board.
What architects control is the schedule. Consultation takes weeks or months, it can produce conditions you then have to build, and it goes badly when it starts after the configuration is finished. Put it in the plan beside the integration work. A works council that finds an agent already writing to worker records will not be won over by a demo.
The same reasoning extends to workers generally. Telling people that an agent may read their records or propose changes, and telling them how to ask what happened, is defensible even where no law demands it. Employers who stay quiet and are later found out spend the next year rebuilding trust.
Test the awkward records before the clean ones
HR data is full of legitimate irregularities: a worker on long term leave, a secondment where the cost centre and the reporting line disagree, dual employment across two legal entities, a rehire whose earlier service counts toward some entitlements and not others. Take real shapes from your tenant, anonymise them, and run the agent against those before it sees a tidy case.
Systems tuned on the common case handle these badly. The agent picks the wrong effective date, applies an entitlement rule that does not fit, or reads the wrong one of two active positions. A reviewer who was never told these cases exist approves the output because it looks plausible. Coverage here buys more than another round of prompt tuning, and it is what an agent readiness check should force you to write down.
Before enabling anything that writes to a worker record, produce one page and get it signed by the HR systems owner. It names each agent, states whether it reads, drafts or acts, names the human accountable for its output, records the security groups it runs under and the worker data it can reach, and says how long you keep the evidence. If you cannot fill that page, that is your first piece of work.
