Agentic OS for the Digital Workplace

The digital workplace was never designed. It accumulated.

A service desk platform, because tickets had to go somewhere. A UEM console, because devices had to be patched. An identity provider, a SAM tool, a DEX vendor, a survey tool, a dispatch system. Each arrived to solve a real problem, each brought its own data model, and each drew a boundary around what it could see. The result is the nine towers most workplace practices are organised around — and nine places where the context stops.

Most AI in this space has so far been applied inside those boundaries. A chatbot on the service desk. A recommendation engine in the patch console. A sentiment dashboard in the DEX tool. Each is useful. None changes the shape of the problem, because the problem was never that an individual tower was slow. It was that no tower could see the others.

That is why the useful analogy is an operating system.

An OS is not an application. It is the layer that lets separate resources behave as one machine: shared memory, so any process can read what another wrote; a scheduler, so work reaches whatever should handle it; a common execution model, so a program need not know which disk it is writing to. An agentic OS for the digital workplace does the same three things for employee support — shared context across every tower, agents that act across systems rather than inside one, and a common record underneath.

What follows is a tower-by-tower look at what that actually changes. The nine-tower model here is a composite of Gartner's outsourced digital workplace scope and how the large practices cut their own P&Ls; the labels vary by organisation, the shape rarely does.

---

1. Service Desk and Employee Support

The scope. Level 0 and Level 1 — the front door. Multilingual coverage across voice, chat, email, portal and self-service, routed by persona, because a frontline worker on a shared device and an executive travelling are not the same support problem. Practices are typically held to contractual deflection and first-contact-resolution targets.

What agents change. Deflection has historically been a matching game played against a knowledge base: find the article that describes the fix, present it, hope the employee follows it. This caps out quickly, because the constraint is not article quality. It is that reading instructions is not the same as having a problem solved.

Agents move the unit of work from retrieval to resolution. The system is not looking for a document; it is executing the fix, verifying it worked, and escalating with full context when it didn't. That single change does something structurally interesting to the support pyramid: shift-left stops being a periodic restructuring exercise and becomes continuous. As the agent library learns what it can reliably close, L2 work drifts into L1 and L1 work drifts into L0 — not because anyone reorganised, but because the boundary moved.

A second-order effect is worth noting, because it is consistently underrated in business cases. The same intelligence pointed at the analyst rather than the employee improves handle time on everything that was never deflectable. Deflection has a ceiling; assisted resolution does not. Platforms like Rezolve embed the agent experience directly inside the analyst's console for this reason — the economics of the tower improve from both ends, not one.

---

2. ITSM Platform and Process Operations

The scope. The system of record and the ITIL processes running on it: incident, request, change, problem, major incident. CMDB accuracy sufficient for impact analysis. Platform administration, integrations, reporting and metric governance.

What agents change. These processes were designed as human workflows with software assistance, and the ceremony still shows. The CAB meets Thursday regardless of what is queued. The major incident bridge spends its first twenty minutes assembling people rather than diagnosing. Problem management is where tickets go to be closed rather than understood.

The ceremony exists because the analysis was expensive. Assessing change risk properly meant a human reading the change, understanding the dependencies, and knowing what broke last time — so organisations batched that work into a weekly meeting. When the analysis becomes cheap, batching loses its justification. Risk can be assessed per change. A major incident can open with blast radius already mapped, comms drafted and the right people paged. Problem management can run continuously against ticket clusters rather than waiting for someone to notice a pattern.

The other shift is in reporting. Governance packs are currently rebuilt monthly, which means the number an account team presents is an artefact somebody assembled rather than a question anybody can ask. Agents that query the operational data directly turn the monthly pack into a live interface — and change what a governance conversation can cover, because a follow-up question no longer takes a week.

---

3. Joiner–Mover–Leaver and Request Fulfilment

The scope. Day-one readiness — hardware, software, access and licences in place before the start date. Mover re-kitting, granting the new role and revoking the old. Clean exits with every seat reclaimed and every device recovered, evidenced. Plus the day-to-day request traffic underneath.

What agents change. JML is the tower most exposed to experience penalties, and it is almost always run as a request flow: HR raises a ticket, IT works the ticket, something is missed. It is properly an event flow. The HRIS record changes, and everything downstream should follow without anyone raising anything.

Most organisations know this and have not done it, because the hard part was never the trigger — it was reconciling state across four systems that disagree. The HRIS says the role changed. Identity says the group membership didn't. The endpoint tool has a device assigned to someone who left. The asset record has a different device. Every JML automation project eventually collides with this, and most quietly narrow their scope to onboarding only.

Agents handle it differently because they can hold the entitlement question open continuously rather than answering it once at ticket close. What should this person have, given the role they now hold, versus what do they actually have — evaluated as a standing reconciliation rather than a checklist executed on day one. Movers are where this pays: the population where over-entitlement silently accumulates, and the one every access audit finds.

The exit side is mostly an ageing problem. Devices leave and are not returned, seats persist for months, and nobody notices because nothing escalates. Tracking recovery through the asset record with agents chasing anything past policy is unglamorous and closes a real leak.

---

4. Endpoint Management and Device Lifecycle

The scope. Provision, configure, deploy, update, patch, protect and repair every endpoint. Application packaging and OS lifecycle. Refresh planning and EOL migration without breaking dependencies. Modern management and virtual estates alongside traditional PCs, with warranty and spare-pool accuracy across sites.

What agents change. Patch and vulnerability work has been a reporting discipline. A compliance percentage, a dashboard, a list handed to somebody else to action. The gap between knowing and fixing is where all the risk lives, and it is an ownership gap rather than a detection gap. Agents close it by owning the full loop — plan, deploy, verify, report, and chase the exceptions that make up most of the actual work.

Refresh is the more interesting case. Age-based refresh is a budgeting convention, not an engineering judgement, and everyone in the practice knows it: the machines generating disproportionate support cost are rarely the oldest ones. The reason age persists as the criterion is that age is the only variable available in the asset record. Ticket history sits in the service desk. Crash and performance data sits in the endpoint tool, if it is collected at all. Nobody can rank the estate by actual cost to serve, so everybody ranks it by purchase date.

Put those three datasets in one context and refresh becomes an evidence-based decision. The specific pattern worth hunting is the individual machine quietly producing escalations — the repeat offender that costs more in analyst time each quarter than replacing it would. That device is invisible in every tool that exists today and obvious the moment ticket history and device telemetry are read together.

---

5. Field, Depot and Walk-up Services

The scope. Deskside, depot, walk-up and the physical asset loop. Dispatch for what remote support cannot close, tech bars and smart lockers for contactless fulfilment, spare-pool sizing by site, RMA throughput against OEM entitlement, and physical stocktake evidence.

What agents change. This is the highest cost-per-contact in the practice, which means the value is not in making dispatch faster. It is in not dispatching.

A meaningful share of truck rolls fail on arrival: wrong part, wrong diagnosis, employee not present, or an issue that was remotely fixable all along. Each of those failures is predictable from information the organisation already holds at the moment of booking — it is simply not assembled. Scoring dispatch readiness before a visit is committed is a low-drama application of agents with an unusually direct cost impact.

The larger prize is pattern recognition across visits. Three separate deskside tickets on the same device across two months are three tickets to a dispatch system and one hardware fault to anyone looking across them. Converting recurring visits into a single planned intervention is where field cost genuinely moves.

The physical inventory side benefits differently. Stocktake is a compliance chore mainly because the evidence is manual — count, attest, hope the auditor accepts it. Reconciliation with barcode scanning and photo proof per asset produces evidence rather than assertion, and it is exactly the sort of structured, repetitive verification agents are suited to.

---

6. DEX and Experience Management

The scope. Digital employee experience telemetry across the estate, and the experience-level agreements built on it. Sentiment measured across the journey. Persona journey mapping that exposes inequity between worker types. Proactive remediation triggered by signal rather than by a ticket.

What agents change. XLAs have a credibility problem, and it is worth being blunt about the cause. Most XLAs in production are CSAT and NPS restyled — they measure how someone felt about a transaction, which is not what an experience-level agreement claims to measure. A client executive who has been sold on experience management and then handed a satisfaction score has been given a survey with a new name.

The obstacle has always been correlation. Device telemetry lives in one tool and knows what broke. The ticket estate lives in another and knows what was reported. Neither knows about the other, so nobody can answer the question that matters: did the crashes on Tuesday produce the frustration on Wednesday, and for whom? Without that join, proactive remediation is not really possible either — you can trigger on a device threshold, but you cannot tell whether crossing it actually harms anyone, so you either alert on everything or on nothing.

Join the datasets and two things become available at once. An experience measure that is observed rather than surveyed. And remediation that fires on signal before the employee gives up and files a ticket — which is the majority of degraded experience, since most people do not report a slow laptop, they simply work around it.

This is the tower where the operating-system framing stops being a metaphor. Rezolve's work on a unified employee journey — composing tickets, voice, virtual agent, enterprise search and device telemetry into one narrative per employee — is an attempt at exactly this substrate. Whoever builds it, the requirement is the same: shared memory across towers is the precondition for experience management that means anything.

---

7. Collaboration, M365 and Copilot Enablement

The scope. Microsoft 365, Teams and unified communications support across on-prem, cloud and hybrid. Adoption and organisational change management. Copilot rollout, licence optimisation and adoption tracking. Increasingly, governance of the client's own agent estate.

What agents change. Two distinct shifts, and the second is arriving faster than most practices expected.

The first is placement. The correct place to resolve a Teams problem is Teams. Support that requires leaving the collaboration tool to describe a problem with the collaboration tool imposes a friction cost that shows up directly in deflection rates. Agents living inside Teams and Slack are not a channel strategy; they are an acknowledgement of where the work already happens.

The second is that practices are now being asked to govern AI they did not deploy. Clients are rolling out Copilot agents and custom skills faster than anyone is tracking them, which is simultaneously a licence problem, a security problem and a support problem. Who built this agent? What can it read? Is it still in use? Should this user have a licence at all? These are workplace-tower questions, and they arrive in bids well before most practices have an answer.

Adoption tracking is the tractable entry point, and it is more valuable than it first appears — because adoption data is only interesting when it connects to spend. Knowing that forty percent of Copilot seats are dormant is a chart. Turning that into reclaimed seats with owner notice and an audit trail is a result. Rezolve's SpendIQ approaches Copilot this way deliberately: adoption as a spend-and-value question rather than a usage dashboard.

---

8. Workplace Security, Patch and Compliance

The scope. The endpoint hygiene half of workplace security. Patch and vulnerability remediation across the end-user estate, EOL and unpatched hardware tracked to an owner with an SLA, least privilege on privileged seats, shadow IT and orphaned devices found before an auditor finds them, and evidence for ISO 27001, HIPAA and PCI.

What agents change. Security tooling is extremely good at producing findings and structurally bad at closing them. That is not a criticism of the tooling — closure requires knowing who owns the asset, what breaks if you touch it, and who can approve the change, and all three of those facts live outside the security tool.

This makes remediation a context problem rather than a detection problem, which is precisely the class of problem agents address. An agent operating across the service desk, the asset record and the endpoint estate can convert a finding into an owner-assigned, SLA-tracked item with a change path attached. The difference between a report and a closed finding is almost entirely this.

The same logic applies to the findings nobody can act on today because ownership is unknown — orphaned devices, shadow IT, over-provisioned privileged seats, toxic privilege combinations. These persist not because they are hard to detect but because detecting them produces a list with no next step.

One caution belongs in this tower specifically. Introducing AI into support creates a new data path, and a support agent with broad read access across systems is an exfiltration surface if nobody designed for it. Any serious platform should be screening what its own agents handle — Rezolve runs data-leak prevention as a foundational agent in the conversation path rather than a policy applied afterwards. It is worth asking any vendor how they handle this, because the ones without an answer have usually not thought about it.

---

9. IT Asset, Licence and Spend Management

The scope. Entitlement versus deployment reconciled before a vendor audit arrives. True-up readiness with defensible per-publisher evidence. Shelfware and idle seats identified, notified and reclaimed. Cost to serve per asset, per ticket and per site. Asset and CMDB records that finance and IT both trust.

What agents change. Software asset management has always been a reconciliation exercise on a quarterly cadence, which produces two problems. The number is stale the day after it is produced. And because it is stale, the reclaim conversation is a negotiation rather than a fact — the business unit disputes the finding, the finding is three months old, and the seat survives another quarter.

Continuous agents change the cadence, but the more consequential shift is that reclaim becomes an executable workflow rather than a recommendation: detect the idle seat, notify the owner, wait the policy window, reclaim, log the evidence. The evidence trail is what makes it survive challenge, and the reason most shelfware programmes fail is that they produce candidates rather than closures. This is the substance of what tools like SpendIQ are built around.

The genuinely new question sits one layer up. Once asset data sits alongside ticket volume and device telemetry, an organisation can answer not what an asset cost, but what it costs to serve — the machine, the site, or the persona consuming disproportionate support. That number is what a client executive actually wants, and almost nobody can produce it today, because it requires exactly the cross-tower join this whole model is about.

---

Where this leaves an existing ServiceNow or Jira estate

Everything above raises an awkward question for any organisation with a mature ITSM investment. If the intelligence layer is where the value now sits, does the system of record have to change?

The useful development of the last few years is that these two decisions have come apart. The record layer and the intelligence layer used to be bought as one thing, because the intelligence was a feature of the platform holding the data. Agents that operate across systems break that coupling, which means the sequencing is now a genuine choice. Broadly there are three positions:

Layer intelligence over the incumbent record. Agents operate against the existing ServiceNow or Jira estate, reading and writing through its APIs, with the agent experience embedded inside the console analysts already use. No migration, no data cutover, no change visible to end users. Tower KPIs — deflection, handle time, change throughput, seat reclaim — can move within a quarter.

The honest trade-offs: you inherit the incumbent's data model and its limits, you are constrained by what its APIs expose, the incumbent licence cost stays on the books, and you are operating two vendors where you had one. For most organisations these are acceptable prices for removing migration risk entirely, which is why this is where nearly everyone should start.

Replace the record layer, keeping the agents. Usually considered at licence renewal, when the cost question is live anyway. The agents continue running; the record moves underneath them. The advantage of having layered first is that this becomes a much smaller decision than it would have been cold — the operational improvement is already banked and demonstrable, so the platform question is evaluated on cost and fit rather than on hope. The trade-offs are the familiar ones: migration effort, historical data decisions, retraining, and the process debt that surfaces whenever anyone opens up how change management actually works.

Do neither yet, but stop buying as though the coupling still exists. The position worth naming, because it is the cheapest. If the layers are separable, then a point tool bought for a single tower is a decision that constrains the intelligence layer later. Evaluating new tower tooling on whether an agent can read from it and act through it is close to free today and avoids a lot of expensive unpicking.

What makes this a real choice rather than a vendor talking point is the decoupling itself. A platform question no longer has to be answered before an operational improvement can begin — which is a reversal of how these programmes have been sequenced for twenty years. Rezolve is built for both positions deliberately, running agents against an incumbent ServiceNow or Jira estate while carrying a native record layer for organisations that eventually want one. The sequencing stays with the client rather than the vendor.

---

Why it is an OS rather than nine products

Read the nine sections back and a pattern shows up. Almost every transformation depends on context from a tower other than the one being discussed.

Refresh planning needs ticket history. Security remediation needs asset ownership. XLAs need device telemetry joined to support records. Dispatch avoidance needs failure patterns across visits. Licence reclaim needs adoption signal. Cost to serve needs all of it at once.

Not one of these is a hard problem in isolation. All of them are hard when the data lives in nine tools with nine schemas and nine refresh cycles.

That is the actual argument for an agentic OS, and it is not a claim about model quality. It is a claim about architecture. Point-solution AI in each tower produces nine local optima and no compounding — nine tools that each got better and a practice that did not. A shared substrate produces the opposite: an improvement in one tower shows up in another, because they are reading the same context.

Which suggests the question to evaluate any of this against is not what can this agent do. It is what can this agent see — and whether anything it learns is available to the next tower over.

There is a final implication worth stating. Nothing in this architecture is specific to IT. The same agentic layer over the same record extends to HR, facilities and legal service management with domain agents per line of service. That is where employee support was always going, since no employee has ever cared which department owned their problem. The nine towers were an artefact of how the tooling was bought. Agents are the first technology that makes the boundaries between them optional.