Managing agents isn't the same as managing either people or traditional IT - digging into Workday's Agent System of Record

Ever since Workday launched its Agent System of Record over a year ago now, I've been curious to understand exactly where this product fits into the enterprise IT landscape and how Workday defines it. From the start, I wondered about Workday's credentials and motivations for expanding its reach into the domain of IT service management with a product designed to track, govern and manage the deployment of AI agents. I was skeptical that managing agents had much in common with Workday's established expertise in managing people. Last month, I had a chance to find out more from Dean Arnold, VP of AI Platform at Workday, who has been closely involved in the product's development from the very beginning.

When I reflected on our conversation I came to the conclusion that, while managing AI agents certainly isn't the same as managing people, neither is it equivalent to managing conventional IT assets. Agents are a distinct type of resource in their own right, for which an entirely separate management discipline has to be evolved. If not completely new, it's at least a novel and unfamiliar hybrid. This is why it's proving so difficult to get our heads around it, precisely because it doesn't map to what we already know.

When comparing AI agents to conventional IT assets, a helpful analogy may be to think of the difference between the open highway and a railroad. IT assets historically have always been deterministic — like a railroad, they follow a pre-determined path. You can always predict exactly how they are going to behave. If they do something you didn't expect, there will always be a deterministic root cause that you didn't take into account.

Agents are different, because they're probabilistic. While there's still an underlying logic to how they act, there's no predetermined path they have to follow. Just like vehicles on a highway, they have latitude — agency — to select various paths within the framework of guardrails and guidelines that have been laid down. This is more akin to how we manage people — we delegate permission to act within a certain scope. But there are still crucial differences with how humans are managed. Agency is not autonomy. Humans remain accountable for what AI agents do. This, by the way, is why the structure that sets boundaries around that agency is so important.

They’re not the same

The key takeaway is that this is not the same as how we manage humans, but nor is it the same as how we've managed IT assets in the past. We have to manage agents differently because they are not like conventional IT assets, but that's not because they're taking on human characteristics. It's because they're taking on agentic characteristics.

Coming back to the Agent System of Record product, this has important implications for what a product like this needs to do. First of all, unlike traditional IT management tools, there are two separate user roles that it serves. As well as an admin role, you also have an owner who is accountable for setting the agent's guardrails. Arnold explains:

We have two concepts. One's an agent admin and one's an agent owner. There's a little more definition beneath that, but broadly, those are the two top-level ones. So you have somebody who can install and configure and keep an eye on an agent that's more your CIO side. Then your agent owner is much more, 'I lead recruiting for my organization, for my enterprise, and I have a recruiting agent, and that's assigned to me in my organization. My team uses it.' So you can say, organizationally, in a supervisory role in an enterprise, 'I can assign agents and have them work alongside people.' And then we can also say, as the workforce interacts with agents, we can map their usage and how they engage.

That's how we're slightly different from being just a pure CIO take on, 'I'm going to register agents, and I've got a table of them, and I can check which LLM they use.' We can also say, 'Well, this is how it engages with your workforce, and here are different people who own the responsibility and effectiveness of it.' That's our different twist that fits really nicely into our CHRO, CFO go-to-market, plus CIO as well.

This agent owner role is something quite new, and those who take on this role will need a lot of support to carry it out effectively, especially when you bear in mind that one of the current selling points of AI agents is that they're able to carry out tasks that cut across traditional demarcations in the organization. The owner needs to be aware of potential hidden risks when setting up the guardrails, and also needs to carefully monitor agent behavior to make sure it's not doing anything unexpected or moving into areas where guardrails have not been set up. This is where a management console for agents really starts to earn its keep. Arnold goes on:

You need an agent owner. You need somebody [owning] an agent, that has roles and has access to certain data, and you need to be able to govern what they do and where they appear and what access they have to your system. So that's, again, where Agent System of Record fits in.

Agent identity is different

When looking at how agents interact across different systems, new considerations come into play that don't feature in traditional integrations. They need access permissions that correspond to their particular skills and roles, and therefore their identity profile is more like that of a human user than what a deterministic integration would use. Arnold explains:

Agents just can't be treated as an integration, because they need to perform and operate in your platform with an identity... not just a high-access user — which is what you see if you're in Boomi or you're in MuleSoft or whatever, you run an integration and it extracts all your payroll data, or it does some analysis over something or other. We call those ambient interactions. But when you're actually doing transactions and you're making changes to the system, that needs to be done as an identity, needs to represent as a user...

It's starting to become a standard that agents should execute in what we call delegate mode with a user, or operate as themselves, and they shouldn't just have carte-blanche access to the system, like an elevated profile. They should have the access and the roles that they need in the platform to do the job they're assigned.

It goes beyond saying an agent is an integration, where I move lots of data around from one system to another, in a hub-and-spoke datamart kind of thing. This is agents operating, performing skills and tasks and roles in the platform, and they should be assigned it to that level. If you're working through that lens, and that is your thesis, then aligning up with your workforce planning is what you want to do with agents.

When thinking about this more nuanced identity profile, it's easy to start to equate agents with human users. Arnold sums up:

We fundamentally believe that agents have unique identities and should be treated in line with their skills and their roles.

But giving agents unique identities doesn't make them human. In fact, Arnold goes on to say that the different ways in which agents behave make it important to manage those identities differently from how you would manage people. So while it can be helpful to start out by mapping the data and processes they can access to the permissions that human users have previously had for the same roles and workflows — this is a point I discussed in an earlier chat with Peter Bailis, Workday's CTO — ultimately, a new approach is needed. Arnold says:

They are going to do things across the enterprise that are different and differentiated from the human workforce... An agent has the opportunity to be able to span different processes out of organizational trees and charts and actually work across different areas.

There are limitations, therefore, in mapping agents to a traditional org chart. Instead, Workday is starting to explore the concept of the 'work chart', which maps the tasks and skills that are used to complete work across the organization, rather than the roles that people fulfil, and uses these mappings to inform the permissions assigned to agents. He goes on:

What is work versus what is your supervisory org hierarchy? What [do] those different processes look like? And how can agents fill a gap and stitch across these processes, connecting what would otherwise be work that might be done by humans in a very management chain focused thing? Agents can touch different areas... At the moment, they still need the roles and the capabilities to do those pieces of work. It might not be a vertical org chart kind of hierarchy of role, and it might be cross-cutting. But they still shouldn't have more than they need, and they should be able to do those functions.

My take

What comes across from this conversation is that how enterprises deploy and use a product like the Workday Agent System of Record {ASOR} is going to need a lot of careful thought, because there are important new principles to take on board. The change management processes are going to be crucial — and since this is all new territory, everyone is learning as they go along. Certainly, it seems to be early days in terms of how customers are using ASOR, mainly because customers are still quite early in their adoption of agents as a whole. And for now, connections to external agents using MCP and A2A protocols are largely at a testing phase rather than in full production mode.

This means that the only enterprises using ASOR at the moment are Workday customers — for whom it comes free of charge, so why not make use of it? Whether the product can become something that other organizations would adopt purely on its merits remains to be seen. But it's evident that there's scope for innovation in this field that could be a differentiator for whoever gets there first. I feel too that I understand better now why this is not solely the domain of integration specialists, and indeed why a vendor like Workday can build on its own knowledge of skills and workflows in the organizational domain that may be less familiar to those coming from an integration background. There's a lot still to learn in this very new field of IT.