Most of what arrives at an HR service desk falls into one of five categories. The categories sound obvious once you write them down. They become useful when you start labelling each agent use case with one of them and asking, separately for each type, what an agent should actually do.
Once you have the labels, three things get easier. The architecture conversation shortens because the pattern follows from the type. The governance conversation cleans up because the risk follows from the type. And the portfolio view starts to make sense, because you can see at a glance whether the mix is healthy or whether you have eight transaction helpers and no investigator agents to deal with the cases that actually hit the inbox.
Type 1: Transactions
Hire, terminate, change manager, change job, request time off, create a position, adjust compensation. The user wants something specific to happen, and the agent's job is to make the existing path easier rather than to replace it. Keep the Workday business process as the spine, layer the agent on top to pre-fill from context and validate against policy, and keep human approval on the critical path because a wrong hire or pay change has real downstream consequences. The agent suggests and pre-fills. The human approves and submits.
Type 2: Knowledge questions
The cleanest pattern is a search-and-answer agent backed by retrieval. Workday's native Self Service Agent and its knowledge-learning capabilities (Sana is part of this story now) cover a lot of this for content that lives in Workday. For content in the intranet, SharePoint, or other knowledge sources, a retrieval-augmented agent with the right security filters does the job. The questions are the recognisable ones: what is our parental leave policy in Spain, how do I request unpaid leave, can I expense a hotel for a one-day client visit. The user wants information, not action.
Two things sink this pattern more often than the model choice. The first is the content. The quality of the agent scales with the quality of the source library, which means cleaning up the policy library is usually higher leverage than picking a fancier LLM. The second is provenance: always show the source, and always make it clear that the answer came from AI. An authoritative-sounding wrong answer costs more in trust than a slightly slower "according to our parental leave policy, [quote]" answer.
A common design mistake is to over-engineer the model and under-engineer the library. The agent that quotes a clean, well-indexed policy library with a basic model outperforms the agent that wraps a frontier model around a messy SharePoint folder, every time. Pick which problem you are actually solving before you pick a stack.
Type 3: Status updates
Has my promotion been approved. When does my new hire start. What is the status of my expense report. The information exists; the user just cannot find it without three clicks and a tab. A tracker or notifier agent reads from business process status, the in-box, or the case-management system and answers in plain language, ideally proactively (pushing an update when something moves rather than waiting to be asked). The risk on this pattern is low as long as the agent calls Workday's existing security model rather than implementing its own access logic, but "user sees a status they shouldn't" is the most common way early agents leak information they should not, so the security path goes in on day one rather than version two.
Type 4: Advice and decision support
The user needs guidance to make a choice that depends on both rules and judgement. "Which job profile should I pick for this new role?" "Is this candidate strong enough to extend an offer?" "What should I say in my year-end review for an underperforming team member?" The answer is not a fact retrievable from a policy. It is a recommendation shaped by context.
The cleanest pattern is a coach or advisor agent with a human in the loop. The agent mixes Workday signals (skills cloud, benchmarks, organisational data) with retrieved guidance from internal playbooks and templates. It explains the options. It drafts the message. It does not make the decision. Under the EU AI Act, most of these sit in the high-risk classification, which means documented assessments, human oversight, and transparency to the employee. Treat advice agents as high-risk by default. The agent suggests, the manager or HRBP decides, the decision gets logged. Design the human-in-the-loop step to be useful, not ceremonial. A manager who clicks through it as ceremony will eventually trust the agent more than they should.
“The best advice agent is the one that helps a human make a better decision, not the one that delivers the most confident answer.”
Type 5: Problem analysis and complex cases
Something is broken or unclear and needs investigation: a paycheck discrepancy, the same complaint logged three times, the system keeps assigning the wrong manager. The pattern is an investigator or triage agent, usually built as a multi-agent setup with a supervisor coordinating specialised sub-agents (payroll-data, policy, case-history) that collect context and propose likely causes. These are the easiest agents to over-build. Start with narrow problem categories where the inputs are well-defined, resist building a general HR investigator until two or three specific ones have shipped, and keep a human owner on every case. The agent's output is one input to their investigation, not the conclusion.
How to use this in practice
Three things change when you label your agent use cases with these types. First, the design conversation gets shorter because the pattern is already obvious from the label. A transaction agent has a known shape. So does a knowledge agent. You stop reinventing the wheel for each use case.
Second, the governance conversation gets cleaner. Knowledge and status agents are usually low-risk and can ship with light review. Advice and complex-case agents are usually high-risk and need the full assessment. Transaction agents sit in the middle. Your AI governance board can have a useful, fast conversation when each new use case arrives with its type already attached.
Third, the portfolio conversation makes sense. Most mature HR agent portfolios end up with a mix: several knowledge agents, two or three status trackers, a handful of transaction helpers, one or two well-governed advice agents, and a small number of investigator agents in specific domains. The mix is a feature, not a mess. The types help you see whether the mix is healthy.
If you cannot label each candidate use case with one of these five types in about fifteen minutes, the use case is probably not ready for design yet. It needs another conversation with the people who actually do the work, not another whiteboard with the team that wants to build it.
