I keep asking the same question in customer conversations, and the answer keeps coming back as a long pause.
Who owns this agent?
Usually the person who built it answers first. Sometimes the line of business that asked for it. Sometimes the platform team that hosts it. The honest answer, more often than not, is that nobody really does. The agent exists because someone built it. It runs because nobody has turned it off. It does the work it was scoped to do until somebody notices it has drifted from that scope, and then there is a brief and slightly awkward conversation about whose problem this is.
The technology to build the agent has run ahead of the discipline to manage one.
That is the gap this piece is about.
The category we’re missing
There is a familiar way large organizations talk about software, and a familiar way they talk about people. Neither one quite covers what an agent is.
Software is a system. It does what its code says. When it breaks, you log a ticket, the platform team patches it, and life continues. You do not assign a software system a manager. You do not ask whether it is meeting its goals this quarter. You do not run a quarterly business review of an authentication service.
People are workers. They join the organization, they get an identity, they get assigned to a function, they have a manager, they have a job description, they have a performance cycle, they get developed, they leave or get promoted. The whole infrastructure of human resources exists because organizations need a consistent way to handle the lifecycle of a worker.
The agent is neither. It is a system that does the work of a worker. It needs the technical fabric of the first and the operating model of the second, and most enterprises have built only the first half.
The result is a workforce of agents without a function that manages them.
Why I keep landing on the HR shape
The first time I described this gap as missing an HR function for agents, I expected pushback. The phrase sounds like a vendor pitch. It sounds like the kind of overreach you write into a keynote deck to make a category feel bigger than it is.
It is also accurate, which is why it keeps coming up in conversations regardless of how it sounds.
The conviction is not theoretical. A few years ago, during the long pivot to hybrid work, I spent a stretch of time working with customers on Viva rollouts. The product was the conversation starter. The actual work, in most of those engagements, was much bigger than the product. Companies were re-examining what work was, where it happened, and what they owed their people.
What I watched, in conversation after conversation, was who actually ran that change.
It was almost always HR, and almost never HR alone. HR sat with communications to figure out how to tell the story inside and outside the company. HR sat with the technology function to figure out what to deploy and how. HR sat with the business leaders who had to operate the new model. The good ones treated it as one job with three counterparts, and they were the connective tissue.
The lesson that stuck with me is that workforce transformation is never owned by a single function. It is a coordinated act across HR, technology, and the business. The muscle that got large organizations through hybrid is the same muscle that will get them through a workforce of humans and agents. We have run this play before.
Walk through what HR actually does for human employees, stripped of the cultural noise. It is a short list.
It establishes who someone is, with a unique identity that does not depend on another person’s account. It assigns them to a function and gives them a scope of work. It names the person accountable for them. It controls what they have access to, and ages that access as their role changes. It runs a loop that asks whether they are doing what they were hired to do. It handles the exit when they leave.
That is the lifecycle.
Compare it to what an enterprise has to do for an agent it intends to use in production.
It has to establish who the agent is, with credentials that do not piggyback on the person who built it. It has to assign the agent to a function and give it a scope of work. It has to name a person accountable for it. It has to control what the agent can reach, and age that access when the function changes. It has to run a loop that asks whether the agent is doing what it was deployed to do. It has to retire the agent cleanly when it is no longer needed.
That is the same lifecycle.
The fact that the discipline does not have a name yet does not mean the work is not happening. It means the work is happening badly, in a thousand uncoordinated places, with no shared vocabulary, no agreed owner, and no consistent rigor.
What the industry is doing about it, and what it is missing
The conversation is starting to form in two places, and they are not yet talking to each other.
On one side, the security and identity world has noticed that the number of non-human identities inside a typical enterprise is exploding. Service accounts, API keys, machine credentials, and now agents. The ratio of non-human to human identities at most large organizations is growing exponentially, and the agent slice is the fastest-growing of the bunch. The discipline being built around this is identity governance. Discover the agents, credential them, scope their access, audit their actions, decommission them when their owner leaves. Useful, necessary, real.
On the other side, the HR and people-analytics world has started using language like digital employees and digital coworkers. Major HCM vendors are shipping products to register agents the way you register people. The framing is intuitive and the tooling is improving. It is also being shaped more by product roadmaps than by operating principles, which means the language is running ahead of the practice.
Both sides are correct about what they see. Neither side, on its own, is what an enterprise actually needs.
Identity governance is the plumbing. It tells you who an agent is and what it can touch. It does not tell you whether the agent is doing useful work, whether it belongs in the function it sits in, whether its scope is still appropriate, or whether the time has come to retire it. Those are not security questions. They are people-management questions, applied to a thing that is not a person.
A people-management discipline built for agents is the operating layer sitting on top of the security plumbing. Both have to exist. Most enterprises have built half of one and none of the other.
The function we are missing is the one that asks whether an agent is still doing the job it was hired to do, and what to do about it when the answer is no.
We have been here before
The closest historical parallel to where we are now is not generative AI itself. It is robotic process automation.
A decade ago, large organizations watched RPA software promise to absorb the unglamorous work that humans had been carrying for years. Form filling, ticket routing, invoice processing, the long tail of clicks and keystrokes that nobody wanted to do. The promise was real. The early deployments worked. Many of them still do.
What also happened, and what most enterprises quietly learned to regret, was the operating model around them.
Bots got built on the credentials of the person who built them. When that person left the company, the bot either died or, worse, kept running under credentials nobody could trace. Bots got deployed onto desktops that were never managed for that purpose, which meant they broke every time something in the environment changed. Ownership lived in pockets, often inside the line of business, which sounded good until the bot failed in a way that needed central support and nobody could find who to call. Decommissioning was nobody’s job, which meant the population of bots quietly accumulated until the next CIO arrived and asked, with some alarm, what exactly was running in production.
The technology was not the problem. The discipline around the technology was. We had no consistent way to onboard, manage, or retire a non-human worker, and the consequences caught up with us at scale.
Agents are about to repeat that lesson, faster, with broader access, and with the added complication of reasoning.
The good news is that the lesson is already paid for. The bad news is that most organizations are not yet acting on it.
What this function actually looks like
I do not have the perfect name for the discipline. Agent operations is being used in some places, mostly to describe the engineering side of running agents reliably. That is closer to MLOps than to what I am describing here. Digital workforce management is being used in others, mostly as marketing language attached to a product. Useful, also not quite the thing.
What I keep landing on, when I sketch the shape of it, is something that looks less like a product and more like a small function inside the enterprise. Three or four people, sometimes larger in a more agent-heavy organization, sitting at the intersection of IT, security, and the lines of business that use the most agents. Not a center of excellence in the consulting sense. A small operating team that owns the lifecycle.
Their work, in plain language, is:
Define what an agent looks like inside your organization. The default shape, the default identity model, the default scope boundaries, the default escalation path when an agent runs into something it cannot decide.
Maintain a list of every agent the organization runs and a named human accountable for each one. If an agent has no named owner, that is the first finding to chase.
Run a quarterly review of each agent that asks three questions. Is this agent still doing the work it was deployed for? Is its scope still appropriate? Should we keep it, change it, or retire it?
Coordinate the decommission process. When an agent is no longer needed, somebody has to actually shut it down, revoke its credentials, and close the audit trail. That work is small and unglamorous and nobody is going to do it unless it is owned.
Sit close enough to the lines of business to know what is being built, and close enough to security to make sure the controls are consistent.
That is the function. It is small. It is mostly process. It does not require a moonshot platform. The hardest part is naming the team and giving someone the authority to run it.
The honest limits
Worth being clear about what this is not.
It is not a new C-suite role. The temptation, every time a category like this emerges, is to invent a chief something officer and put a logo on it. That is the version of this story that gets the analyst coverage and the keynote slot. It is also the version that, in most organizations, gets staffed half a year later than it should and stays performative for years after. The work I am describing does not need a new title. It needs a small empowered team with a clear charter.
It is not the same thing as agent engineering. Building reliable agents is a real discipline with its own tooling, its own monitoring, and its own learning curve. Running an agent workforce is a separate discipline that depends on the first. Engineers should not be asked to do both. Each is full-time work.
It is not a substitute for HR. Human resources serves human beings, with all of the emotional, developmental, and legal weight that implies. Calling the new function HR for agents is a useful framing because it borrows the shape of the lifecycle. It is not a useful claim that the actual HR function should absorb it. The two should sit close and learn from each other. They should not necessarily be merged.
It is not solved by a product. There are good tools in this space, and there will be more. None of them will substitute for the question of who in your organization is accountable for the agent population. Tools are leverage. They are not the operating model.
What this looks like a few quarters out
If I had to guess what most large enterprises look like a year from now, it would be this.
The first few will have stood up a small function that owns the agent lifecycle, named it something pragmatic, and quietly cleaned up an embarrassing number of orphaned agents along the way. They will not talk about it much. The work is not glamorous.
The rest will discover the problem the hard way. Somebody will leave the company, an agent built on their credentials will fail in a way that costs real money, and the postmortem will reveal that the organization had no consistent answer to who owned this. The fix will get framed as a security incident, which is technically true and operationally insufficient.
The vendors will continue to ship tooling. The analysts will continue to publish frameworks. The discourse will continue to argue about whether agents are digital employees or autonomous systems or non-human identities, and the answer will continue to be yes.
There certainly are benefits to the technology an organization chooses. Deep enterprise stacks built on the same Identity, service boundary, security stack, and public cloud provide benefits at scale. However, the organizations that do well in this period are not going to win it on the technology alone, they are going to win it on the discipline.
The closing read
Last article I wrote about giving agents a place to work. This one is about giving them a function that manages them once they are working.
These two pieces are the same argument from two angles. We have been so focused on what agents can do that we have not slowed down to ask where they live, who is in charge of them, and how they leave the organization when their job is done.
Those questions are not foreign concepts, the organization already knows how to answer them for humans. The work is borrowing the shape of that answer and applying it to a worker that does not breathe.
The agents are joining the org chart whether we plan for it or not.
The least we can do is make sure somebody knows who they report to.
Views expressed are explicitly that of my own.