Last week’s piece ended on assembly: what SAP’s two subsidies always did for you was the joining, and no product replaces that.
SAP’s AI Agent Hub lists six capabilities. When SAP announced it at Sapphire in May, two were generally available and four were planned for Q3 2026 — and each of those four executes in a different product.
Q3 closes this month, so some may have landed since. The mapping is what matters.
The two that were available are the two that run inside LeanIX, where the Hub lives. The four that weren’t are the four that execute somewhere else.
The availability line and the ownership line are the same line.
Which means it doesn’t arrive as a product. It arrives as four deliveries, into four other products, with four different owners inside your enterprise — whoever runs your ALM tooling, security, process, and HR.
That looks like a fragmentation problem. It isn’t.
Read the list again
Go back to the six and ask what each one would be if the worker were a person.
AI registry — everything that exists and can be addressed. That’s the company directory.
Evaluation and verification — risk rating, criteria, sign-off. That’s the job description, and the standard the worker is held to.
AI observability — how you measure against that standard. Performance monitoring.
Identity and access control — what it’s allowed to reach, and which tools can be called at all. That’s provisioning.
Agent mining — what the worker actually does, as opposed to what the job description says.
Org chart and skills mapping — where they sit, who they report to, what they’re qualified for.
Six capabilities. Six things you already do for every new hire.
And you don’t run those six in one product for humans either. HRIS, identity platform, performance system, some view of how work actually flows, an org chart. Separate systems are normal. Nobody calls that fragmentation.
Open Outlook and look at your directory. People, conference rooms, shared mailboxes, service accounts — everything in the estate that has an identity and can be reached. Now search it for your agents.
The thing that makes it work for humans
For people, those systems are connected by a process, not by a product.
Joiner-mover-leaver. Somebody starts, and a sequence fires: a form, an approver, accounts provisioned in each system, roles assigned per system, a manager named, a review date set. They change roles, it fires again. They leave, and a different sequence removes what the first one granted.
The systems stay separate. The process spans them. Somebody owns it.
It isn’t that the process runs well — anyone who has been onboarded knows it often doesn’t. It’s that when it fails, there’s a trigger that should have fired and somebody to call.
For digital employees, the systems are arriving. The sequence isn’t.
That’s the gap. Not missing capability — missing connective tissue, and a role that owns it.
Why the word matters
Say “named user” in an SAP shop and a great deal arrives with it. A form. An approver. Licensing implications somebody will ask about. A role design, an ACL group, an access review, a leaver process. You can’t say the phrase without summoning twenty-five years of accumulated practice, most of it written down, some of it enforced by an auditor who checks it first.
Say “agent” and almost nothing arrives.
The word has been in this ecosystem for decades meaning something different each time — transport agents, monitoring agents, agent determination in workflow. It arrives pre-worn and non-specific.
So you get two words for things that live in the same estate, with overlapping questions about access, approval and review — and one retrieves a checklist while the other retrieves nothing.
Here’s the part that surprised me.
SAP’s reference architecture for agent identity stores agent identities in SAP Cloud Identity Services — in the same Identity Directory that holds your people, each with a Global User ID. Identity Provisioning synchronises their roles and groups across connected applications. Authorization Management defines what each agent identity may do. SAP Cloud ALM is named for agent lifecycle governance, explicitly from development through decommissioning.
Directory, provisioning, authorization, lifecycle to decommissioning.
That’s joiner-mover-leaver, for agents, in the identity platform. The frame isn’t an analogy I’m proposing. It’s the architecture SAP is building.
Which makes the practical question narrower and more useful: not whether to think this way, but whether anyone in your organisation is running the process that architecture assumes.
Try it on one
Take a specific one rather than “an agent.” A digital goods receipt clerk, say. Something narrow enough to picture.
Start with the joiner questions. What systems does it need? What roles in each — not one role, a role per system, designed for the job it’s doing? Who approved it? What is it explicitly not allowed to reach? And when it acts, whose identity does each system actually see?
Then be honest about how that will go. The form has fields nobody understands, somebody picks a licence type without knowing what it means, and the roles get assigned by copying another user.
Copying another user’s roles carries forward permissions nobody has justified for this job. For a person, those mostly go unexercised. A digital employee will exercise them, repeatedly, at speed.
Then ask what happens when its job changes. The mover event is the one everybody skips. Widen its scope, point it at a second plant, add a step — who revisits the permissions, who re-approves, and who removes the access the old job needed and the new one doesn’t?
Then ask how you’d notice, and how you’d correct it. Not how you’d notice it failing loudly. That one takes care of itself.
The hard case is the slow decline — work that still looks fine at a glance but isn’t what it was. A manager is supposed to know what good looks like and review against it. A digital employee degrades the same way: the model changes underneath it, the data shifts, the edge cases stop being edge cases, and it gets quietly worse at the thing you hired it for.
And the failure doesn’t have to look like a mistake. The agent has full authority. It follows the method exactly. It determines no values of its own. It posts the receipt against the wrong storage location — the right quantity, the right material, a reference the process never intended. Every permission checks out. The document is valid. The stock is in a place it isn’t, and nobody finds out until someone counts.
Observability traces individual agent sessions in Cloud ALM. That’s real and it’s the right thing to build. But a trace tells you what happened, not whether it was acceptable — and that’s what the evaluation criteria were for.
Noticing is the easy half. With a person, you’d have a word. With an agent, a correction is a write to something — and there are two very different kinds.
“Use the storage location on the PO for this one” changes the current task.
“From now on, check the storage location against the PO before posting” changes the intended behaviour.
Where does that second instruction persist — this conversation, the agent’s memory, its configuration, or its code? Who tests it, who approves it, and how would you reverse it?
That’s change control, and it should scale with the impact. Some corrections are a conversation. Some are a transport.
Then ask how you’d stop it. Go back through the six and ask what each does at the moment an agent acts. Inventory. Standard. Trace. Identity. Execution paths. Placement.
Most of them are a record or a lens. Two aren’t.
Verification is a stop. SAP states that only verified MCP servers can be called in production workflows, and that access is revoked when verification status changes. Mark an asset unverified and the calling stops. That one lives inside the Hub.
Identity is the other. Disable an agent’s identity in SAP Cloud Identity Services and you remove the credential it authenticates with — and autonomous agents operate on their own dedicated technical identity and tokens, so what you’re removing is the basis on which that agent is trusted anywhere downstream. That’s suspending a worker.
The stops are real. Notice who holds them. One belongs to whoever governs the registry. The other belongs to security.
So the manager who notices something wrong at four on a Friday doesn’t have a control. They have a ticket.
And both are blunter than the moment usually calls for. Verification is a production gate, not a pause. Revoking a credential is not the same as stopping work in flight. Does it stop a run already under way? Does an existing token keep working until it expires? Who is allowed to pull either one, and has anyone tested it?
When the job ends
There are two leaver questions, and only one of them gets asked.
The first is access. When the purpose ends — process retired, pilot concluded, team moved on — who removes it?
The architecture is further along here than most expect: Cloud ALM’s lifecycle governance runs explicitly through decommissioning. So there’s a documented owner, which is more than this question usually gets.
What that doesn’t settle is the trigger. For a human leaver, HR fires it and somebody’s job depends on it running. For an agent, nothing announces that a digital worker has stopped being needed. A lifecycle stage exists. Something still has to tell it the job is over.
That’s the same failure enterprises spent two decades fixing for service accounts, arriving again under a different word.
The second question is the one nobody asks. The work outlives the worker — the records it changed, the outputs it produced, and the evidence of what it did and on whose authority. Who inherits that? Where does it live once the agent is gone?
Observability retention is set for operational reasons. Does it preserve the evidence you’ll need after the agent is retired?
What to do this week
Name one agent as a job, not a technology. Digital junior buyer, digital goods receipt clerk. See whether the people in the room start asking different questions.
Run the lifecycle against it. Joiner: systems, roles per system, approver, restrictions. Mover: who revisits all of that when the job changes. Manager: how you’d notice it degrading, how a correction persists, what an intervention actually stops. Leaver: what happens to the access, and what happens to the evidence.
Then name the owners. Start with the business owner of the job. Name the technical owner who can change or suspend the agent. Agree the handoffs with security and the application owners. That’s a starting pattern, not an org chart — but it’s more than most organisations have written down.
Note which questions have an owner and which get a shrug.
The shrugs are the work.