Part 2 of 4 : Rethinking Unified Endpoint Management in the AI Era
By CXO Chronicle | Based on insights shared by Sunil Sankaramanchi , CEO at Wenable Inc.
This article is Part 2 of our thought-leadership series featuring Sunil Sankaramanchi, CEO and Co-founder of Wenable, exploring the evolution of Unified Endpoint Management (UEM) in the AI era. Read Part 1 here: Beyond Connectivity: How AI Is Redefining the Future of Enterprise Telecom
For most of its history, endpoint management has been built around a simple assumption: something happens, and an administrator responds.
A device falls out of compliance. A ticket is opened.
An application crashes. Someone investigates.
A configuration drifts. A policy is pushed.
A user reports poor performance. IT begins troubleshooting.
A security condition changes. Someone decides what to do next.
For years, the industry has focused on making each of these steps faster. But perhaps the underlying operating model itself needs to evolve.
The next generation of Unified Endpoint Management (UEM) will not simply provide administrators with better tools to manage devices. It will increasingly focus on managing the operational state of the endpoint environment itself.
That represents a fundamental shift in how enterprise technology is managed—and may eventually make the term device management feel surprisingly outdated.
From Systems of Control to Systems of Operations
Traditional Mobile Device Management (MDM) was primarily about control: configure a setting, install an application, restrict a capability or enforce a policy.
UEM significantly expanded this scope by bringing more operating systems, applications, security controls, telemetry, workflows and integrations into a unified environment.
Yet the underlying operating model largely remained unchanged:
Observe. Decide. Act.
In most enterprise environments, the critical decision-making step still belongs to a human administrator. Someone must interpret an alert, review a dashboard, investigate a ticket or assess a compliance violation before determining the appropriate response.
Artificial intelligence introduces the possibility of a different approach.
Rather than simply helping administrators complete individual tasks, AI can increasingly participate across the entire operational cycle:
Observe → Understand → Decide → Act → Verify → Learn
This is much closer to an autonomous operations system than a traditional management console.
The objective is not to eliminate administrators. It is to reduce the need for constant manual intervention in routine operational activities while preserving human oversight where it matters most.
Why the Dashboard May Become Less Important
For years, enterprise software has competed on visibility: more charts, more alerts, more telemetry and more ways to monitor thousands of endpoints.
Visibility remains essential. However, a dashboard often serves as an advanced mechanism for telling a human that there is more work to do.
Consider an enterprise managing 50,000 endpoints. At 2:13 a.m., several hundred devices begin experiencing abnormal battery drain following an application update.
A conventional platform might identify the anomaly, generate alerts, identify affected devices, display relevant charts and create incidents for investigation.
That is useful, but it leaves the operational burden with the IT team.
An autonomous operations model asks a different question: why should someone need to intervene if the problem can be safely resolved within predefined boundaries?
If the system can correlate the issue with a specific application version, identify affected devices, compare their behaviour with healthy endpoints, select an approved remediation, execute the action and verify the outcome, the value is no longer limited to generating an alert.
The real value is that the problem gets resolved.
This distinction could become increasingly important as enterprises manage larger and more complex endpoint environments.
AI Should Not Just Explain the Problem
Much of the early enterprise AI experience has focused on assistance.
Summarise an incident. Explain an error. Write a script. Find devices experiencing a particular issue. Recommend a remediation.
These capabilities are valuable, but they still assume that AI primarily advises while humans primarily operate.
A more advanced model emerges when AI is allowed to take action within carefully defined boundaries.
Consider a certificate failure affecting 427 devices.
A conventional system might report that the devices have certificate problems and require investigation.
An AI-enabled operations system could potentially identify that the failures followed a specific policy update, isolate the affected configuration, roll back the policy on devices where the action is approved, quarantine devices that do not match the expected pattern, verify service restoration and document the remediation history.
The exact actions would depend on the environment, available capabilities and security policies. The underlying difference, however, is significant.
The first approach helps administrators identify work.
The second aims to complete appropriate work, verify the outcome and escalate exceptions.
These are not simply two versions of the same product. They represent different operating philosophies.
The Endpoint Becomes a Sensor
The transition becomes even more interesting when we reconsider what an endpoint actually represents.
A managed device is not merely an object waiting to receive policies. It continuously generates operational information, including:
- Battery health and storage pressure
- Network quality and connectivity patterns
- Application behaviour and crash reports
- Authentication failures
- CPU utilisation and operating-system health
- Peripheral status and configuration changes
- Security posture and compliance signals
- User-experience indicators
- Location context, where appropriate and permitted
Historically, much of this information has been handled by separate systems.
Security platforms focus on security. UEM platforms focus on device management. Network systems monitor connectivity. Help desks manage tickets. Application teams investigate performance.
Yet an endpoint experiences all these conditions simultaneously.
A device may be compliant but unable to connect to an application. An application may appear healthy while network conditions are deteriorating. A security policy may be correctly configured while a software conflict affects user productivity.
The endpoint can therefore become one of the enterprise’s richest sources of operational signals.
The next generation of UEM must do more than collect endpoint telemetry. It must increasingly interpret relationships between those signals and use that context to support better decisions.
The Difference Between Automation and Autonomy
The distinction between automation and autonomy is critical.
Automation follows a predefined rule: if condition X occurs, perform action Y.
Autonomy involves understanding the situation, determining whether action is necessary, selecting an appropriate response within policy boundaries, executing it, verifying the result and escalating when confidence is insufficient.
Automation follows a path someone previously designed.
Autonomy evaluates which approved path is appropriate for the situation.
This introduces an important requirement for enterprise endpoint platforms: confidence in the decision and the consequences of the action.
An autonomous system cannot simply be powerful. It must also know when not to act.
A remediation affecting five information kiosks may be suitable for automatic execution. A change affecting 40,000 clinical devices could require a much higher confidence threshold and explicit approval.
Restarting an application may carry limited operational risk. Changing an authentication configuration across an enterprise could have far-reaching consequences.
The future of UEM is therefore unlikely to be a simple model in which AI does everything. A more practical direction is graduated autonomy:
- Observe conditions automatically.
- Recommend appropriate actions.
- Remediate low-risk issues automatically where authorised.
- Request approval for higher-impact changes.
- Escalate situations where confidence is insufficient.
- Maintain a complete and reviewable audit trail.
- Preserve human authority over critical decisions.
Enterprise autonomy without governance is simply automated risk.
For autonomous operations to be trusted, security, accountability, policy enforcement and human oversight must remain integral to the design.
How This Changes the Role of the Administrator
Discussions about AI often focus on whether technology will replace people. That framing misses a more important transformation.
The endpoint administrator of the future may spend less time operating individual devices and more time defining how the overall environment should operate.
Instead of repeatedly responding to individual conditions, administrators could establish operational intent:
- Keep designated devices compliant.
- Maintain a minimum application version.
- Enforce approved configurations across defined environments.
- Prioritise connectivity for business-critical applications.
- Automatically remediate specified classes of failures.
- Require approval before performing high-impact actions.
- Escalate issues when confidence falls below an established threshold.
This would move the administrator higher up the operational stack.
From operator to orchestrator.
From responding to individual incidents to defining operational boundaries.
From managing thousands of devices one by one to governing a system that continuously manages them within approved limits.
The administrator remains essential, but the nature of the work evolves from repetitive intervention towards policy design, exception handling, risk management and operational governance.
Why Autonomous Endpoint Operations Need Network Intelligence
Once endpoint operations become more intelligent, UEM can no longer comfortably exist as an isolated system.
The reason is straightforward: an endpoint reveals only part of the problem.
A device experiencing poor application performance may be functioning correctly. The underlying cause could be the network, carrier, authentication service, DNS configuration, application backend or a connectivity issue affecting a particular location.
Conversely, the network may appear healthy while a device-specific configuration is causing the failure.
An effective operations system must therefore distinguish between device, application, security and network problems rather than treating every symptom as an endpoint issue.
That requires relevant context to be shared across systems.
Instead of asking, “What is wrong with this device?”, IT teams can increasingly focus on a more meaningful question:
What is preventing this user, application or device from achieving the expected outcome?
This is a broader operational question—and answering it requires intelligence that extends beyond the endpoint itself.
As endpoint and network intelligence become more closely connected, troubleshooting could become more contextual, helping teams identify root causes rather than repeatedly addressing symptoms.
The KPI That Matters May Be “Incidents Humans Never Saw”
Today, IT organisations rely on metrics such as mean time to detect, mean time to respond, mean time to repair, ticket volume, compliance percentage and patch success.
These remain important measures of operational performance.
Autonomous operations introduce another useful measure: how many problems were detected and resolved before a human needed to intervene?
Imagine an enterprise in which thousands of small operational issues occur every week, but only ambiguous, high-risk or unresolved situations reach an administrator.
The platform handles routine issues within approved boundaries. People focus on the exceptional cases that require judgement, investigation or approval.
This approach could reduce avoidable interruptions and allow IT teams to direct their attention towards work that requires human expertise.
It would represent more than an improvement in device management. It would be a different operating model for enterprise IT.
The goal would not simply be to detect problems faster, but to reduce the number of problems that require manual intervention in the first place.
The Future UEM Console May Look Surprisingly Quiet
Perhaps the clearest measure of success is not more alerts, more dashboards, more tickets or more information demanding attention.
It is less unnecessary operational noise.
A mature autonomous UEM platform might eventually present an administrator with a simple operational summary:
- 12,482 devices operating normally
- 63 issues detected overnight
- 57 resolved autonomously
- 4 remediations awaiting scheduled maintenance windows
- 2 issues requiring human judgement
These figures illustrate a possible future operating model rather than measured results from a specific deployment.
The important idea is that administrators would spend less time processing routine alerts and more time overseeing exceptions, managing risk and improving the environment.
For decades, enterprise management platforms have been designed to give IT greater control over devices.
The next generation may pursue something more ambitious: give IT control over the rules, guardrails and desired outcomes, then allow the infrastructure to operate within them.
That is why the next great UEM platform may look very different from today’s management consoles. It may increasingly resemble an autonomous operations system.
The Bigger Question: Can an Endpoint Operate Autonomously on Its Own?
As endpoint intelligence advances, another question becomes difficult to ignore.
Can an endpoint ever truly operate autonomously if it understands only what is happening on the device?
Probably not.
The endpoint knows part of the story. Network conditions, application services, identity systems and the wider infrastructure contribute the rest.
A device may report that it is healthy while a network failure prevents a business-critical application from working. A network may report normal performance while a device-specific issue disrupts the user experience.
Meaningful autonomy therefore requires more than intelligence at the device level. It requires the ability to interpret context across the systems that collectively deliver an outcome.
The future of UEM will depend not only on how intelligently endpoints can be managed, but also on how effectively endpoint, network, application and security intelligence can work together.
The endpoint knows one half of the story. The network knows the other half.
Bringing those perspectives together may be what ultimately transforms UEM from a device management discipline into a broader autonomous operations capability.
Coming Next: Part 3 of 4
“The Network Knows Half the Story. The Endpoint Knows the Other Half.”
About the Source
This article is based on insights shared by Sunil Sankaramanchi , CEO at Wenable Inc. , in his original article, “Why the Next UEM Platform Will Look More Like an Autonomous Operations System.”
WinnoFusion Technologies | WeGuard | Wenable Inc. | DINESH KUMAR
Original article: https://www.linkedin.com/pulse/why-next-uem-platform-look-more-like-autonomous-sunil-sankaramanchi-b9qkf/
Editorial note: This article has been adapted for CXO Chronicle from the original source. The views and examples attributed to Sunil Sankaramanchi reflect the source article.
