A small contrast to set the frame. The traditional Workday application is built for a human to navigate. Screens. Forms. Click paths. Configuration to make the path shorter. When AI shows up, it is bolted on top of the same architecture. The agent sees what the human sees, can do what the human can do through the UI, and is constrained by the UI in the same ways.
Agent-native architecture flips this. Agents are not bolted on top. They are designed as participants. The application exposes the right capabilities for an agent to use directly, in the same way it exposes the right capabilities for a human to use through the UI. The work redistributes between humans and agents based on what each is good at, rather than forcing one to mimic the other.
Four principles describe what this means in practice for Workday teams.
1. Parity
Agents need the same capabilities humans have through the UI. Today, this is not yet true across the Workday ecosystem. API coverage is broad but uneven. SOAP Web Services handle core transactions well. Many administrative actions still lack a clean programmatic equivalent. Some configuration work is UI-only.
The principle is not "every screen needs an API tomorrow". It is that the architecture should be designed toward parity over time, and that the gaps should be named and tracked. When an agent cannot do what a human can, you have to know which gap is blocking which use case. Otherwise you build around the gap with workarounds that ossify into permanent constraints.
A concrete example. One HRIS team wanted an offboarding agent that could complete the same steps an HR specialist runs manually: terminate the worker, kick off the exit checklist, revoke access, and notify the manager. Three of those four are clean API calls. The exit-checklist initiation still required navigating a configurable task list that did not have a stable programmatic equivalent. They named that one gap, raised it with their Workday account team, and in the meantime had the agent stop short and hand off to a human at exactly that step. The agent was useful immediately and the gap stayed visible instead of being papered over by a screen-scraping workaround.
2. Granularity
Instead of monolithic workflows, expose atomic, reusable building blocks. Agents compose these primitives dynamically based on context, rather than following a rigid predefined process.
A small example. "Hire a worker" is a monolithic workflow. Useful as a thing humans can run end to end. But for an agent, the useful primitives are smaller. Check the requisition. Retrieve the candidate record. Validate the offer fits the comp band. Submit the hire event. Update the manager. Each primitive does one thing. The agent assembles whichever sequence the situation requires. This is the difference between an agent that runs your scripted process and an agent that handles a hire that does not match any of your scripted processes.
Workday's existing business processes are at the monolithic end of this spectrum. The Extend platform is closer to the atomic end. Agent-native design treats the atomic primitives as the building blocks, with the business process as one possible composition.
3. Composability
Once you have atomic tools and full parity, new features become new prompts rather than new code. A single agent request could orchestrate across multiple data sources and systems without custom development. The marginal cost of a new capability drops sharply.
This is the principle that most changes how HRIS roadmaps look. Today, every new use case is a project. New requirements gathering, new design sessions, new build, new test, new deploy. In an agent-native architecture, many use cases are new compositions of capabilities that already exist. The work shifts from "build the feature" to "describe the use case well enough that the agent can compose it from existing tools". Different skill set. Different timeline.
An HRIS team we worked with had already built primitives for fetching headcount, fetching open requisitions, retrieving budget data, and posting to a comp planning worksheet. When the CFO asked for a "replacement-vs-backfill" view by department two weeks before quarter close, the team did not run a build cycle. The agent composed the four existing tools into a new view, the analyst sanity-checked the output, and the report went into the CFO pack. The same capability would have been a four-week build in their old delivery model.
4. Emergent capability
In a well-designed agent-native system, agents will accomplish tasks you did not specifically design them to do. They combine the available tools creatively to solve a user's actual request. This is a feature, not a bug, as long as the governance around it is sound.
The practical implication: instead of planning every feature, observe what users actually ask agents to do, and formalise the successful patterns. Product discovery moves at the speed of conversation, not at the speed of project cycles. This is faster than any traditional Workday roadmap and gets faster as more capability accrues.
The risk: emergent capability is also where compliance can drift. Treat it the same way you treat any AI: log everything, monitor the patterns, escalate the surprising ones, retire the wrong ones. Emergent capability without observability is shadow IT.
Concretely, one HRIS team logged every agent transcript for the first three months of a manager assistant. They expected it to be used for direct-report comp questions. What it was actually being used for, half the time, was managers asking how to write a structured one-to-one note. The team had not designed that use case. Once they noticed it in the logs, they added a small SOP-retrieval tool, the agent got better at it, and the unexpected use case became a sanctioned one. That loop only works when the observability is in place from day one.
“The HRIS teams that get value from agent-native architecture say the same thing six months in: the work has shifted from shipping features to noticing patterns in how the system is actually used.”
The critical gaps in today's ecosystem
The principles are clear. The gaps in implementing them in Workday today are real, and worth naming honestly. Uneven API parity: programmatic coverage is improving but not yet complete. Scattered context: the 80 percent of HR knowledge outside Workday requires robust retrieval layers to be useful to agents. Emerging governance: the Agent System of Record helps, but the operating practice around it is still being established. Existing configurations: most Workday tenants were designed as standalone solutions, not as composable components. Refactoring is work.
None of these gaps are insurmountable. All of them mean that "agent-native" is a journey, not a switch you flip. The teams investing now in the knowledge layer, the API parity, the governance frameworks, the composable design patterns are the ones who will be ready when the full picture lands.
Where to start
Three practical moves for HRIS teams thinking about agent-native architecture now. Map the parity gaps that matter for your top three use cases. You do not need full parity to start, but you do need to know which gaps are blocking which agents you actually want to build.
Invest in the knowledge layer alongside the data layer. Clean policies, structured SOPs, well-curated content collections. The retrieval layer is what turns a generic LLM into something that knows your organisation.
Establish governance before you scale. The Agent System of Record, your AI governance board, the operating model for agent ownership. The teams that put these in place first ship more agents, not fewer. Disciplined operating practice is the multiplier.
