Mohamed Kafsi

Head of AI Innovation

Victor Bonnet

Software Engineer

AI agents can now take control of a machine, write code, execute it, observe execution feedback, and retry without human intervention.  

That makes autonomous IT troubleshooting possible. It also turns the agent into something enterprise IT treats as high risk: a system that can generate and run arbitrary code on managed endpoints. 

In this article, we introduce a lightweight prototype for autonomous IT troubleshooting. We use it to show how these agents must evolve to become useful and safe in enterprise IT. Our argument is simple: local autonomy alone is not enough. Enterprise deployment requires a 

auto-ai-agents.png

What made autonomous agents more capable?

Since late 2025, LLM coding capability has stepped up, driven by post-training with verifiable rewards (RLVR). Unlike traditional RLHF, which relies on subjective, expensive human preference judgments, RLVR trains on domains where correctness is automatically verifiable. The model gets a binary or graded reward: Code either passes the tests or it doesn't. 

Combining this with a better use of execution feedback (errors/logs), and agentic loops (edit → run → fix) turns code generation from a one-shot prediction problem into a dynamic system that can explore and adapt while solving the task. This is why agents can now act as smart IT technicians. 

Why local autonomy is not enough for enterprise IT

For a single endpoint, the AI agent can autonomously inspect the device state, generate Bash or PowerShell on the fly, run diagnostics, and iterate toward a fix. That expands the range of issues an it can remediate but increases risk. Arbitrary code execution on managed endpoints is one of the most sensitive operations in IT. This requires sandboxing.    

The plot above shows the trade-off between safety and usefulness for IT remediation under different sandboxing models. An agent with no sandbox and full system access is highly capable, but is also the least safe. A fully isolated virtual environment is much safer, but it lacks the access to real device state required for effective diagnosis and remediation. 

The goal is therefore not to maximize autonomy, but to find the right operating point on the curve. Read-only and user-level sandboxes provide stronger safety guarantees, though at the cost of lower remediation power. Human review helps shift that boundary: it allows higher-impact actions to be approved and executed safely, without granting the agent full autonomy. 

Enterprise deployment therefore needs a 

layer to constrain execution and provide governance and auditability. Moreover, we argue that we also need an 

 layer to turn one successful repair into a reusable capability across the fleet, making the system smarter with every incident. 

We built the prototype as a lightweight agent runtime embedded in the Nexthink Collector. The runtime is written in Rust and adds less than 4 MB to the collector binary footprint. 

The core runtime consists of a main agent that process requests and routes them to specialized sub-agents. Each sub-agent is configured remotely by the IT administrator through a dedicated UI with four main controls: 

The diagram below illustrates a read-only agent handling an IT issue  

Screenshot 2026-04-02 at 13.36.12.png

This is how the architecture extends agent capabilities without giving up safety, governance, or auditability. Validated actions can then be promoted into the enterprise catalog for reuse across similar incidents. This is where enterprise learning starts. 

When AI agents operate in isolation and rely only on local memory, they are likely to repeat the same mistakes across devices and lose the opportunity to learn from related incidents. They cannot build the shared knowledge needed to improve the system. 

The strongest architecture pairs secure local execution with a central enterprise learning layer. The local agent handles the immediate incident. The central layer creates the compounding value of enterprise learning. It captures the incident context, the actions taken, the outcome, and any human validation, then uses that evidence to identify reusable patterns across the fleet. 

Consider a VPN failure on one laptop. A local agent may find that the issue is a stale client configuration and repair that machine safely. The central system can then detect similar incidents across the fleet, correlate them with a recent policy or version change, and promote a validated remediation into a reusable script. What was a single repair becomes a reusable capability that enables proactive remediation.  

We already see value in a pragmatic first generation of enterprise learning. Teams at Nexthink are building capabilities around memory and reusable skills that help agents retain context and apply past successful resolutions. 

However, the broader problem requires deeper research. The challenge is deciding which local fixes generalize, under what conditions they are useful and safe, and how they should be governed before reuse. That is an active research track, and we will cover it in a follow-up post. 

AI agents can now autonomously investigate and remediate IT issues, but autonomy alone is not enough for the enterprise.

Our research explores the layers required for enterprise deployment: a safe runtime layer that makes local code generation and actions secure, and a learning layer that enables a self-improving system that turns individual remediations into enterprise knowledge. 


AI agents can now take control of a machine, write code, execute it, observe execution feedback, and retry without human intervention.  \nThat makes autonomous IT troubleshooting possible. It also turns the agent into something enterprise IT treats as high risk: a system that can generate and run arbitrary code on managed endpoints. \nIn this article, we introduce a lightweight prototype for autonomous IT troubleshooting. We use it to show how these agents must evolve to become useful and safe in enterprise IT. Our argument is simple: local autonomy alone is not enough. Enterprise deployment requires a \nruntime safety layer\n and an \nenterprise learning layer\n. \n\n\n\n\nWhat made autonomous agents more capable?\nSince late 2025, LLM coding capability has stepped up, driven by post-training with verifiable rewards (RLVR). Unlike traditional RLHF, which relies on subjective, expensive human preference judgments, RLVR trains on domains where correctness is automatically verifiable. The model gets a binary or graded reward: Code either passes the tests or it doesn't. \nCombining this with a better use of execution feedback (errors/logs), and agentic loops (edit → run → fix) turns code generation from a one-shot prediction problem into a dynamic system that can explore and adapt while solving the task. This is why agents can now act as smart IT technicians. \nWhy local autonomy is not enough for enterprise IT\nFor a single endpoint, the AI agent can autonomously inspect the device state, generate Bash or PowerShell on the fly, run diagnostics, and iterate toward a fix. That expands the range of issues an it can remediate but increases risk. Arbitrary code execution on managed endpoints is one of the most sensitive operations in IT. This requires sandboxing.    \n\nThe plot above shows the trade-off between safety and usefulness for IT remediation under different sandboxing models. An agent with no sandbox and full system access is highly capable, but is also the least safe. A fully isolated virtual environment is much safer, but it lacks the access to real device state required for effective diagnosis and remediation. \nThe goal is therefore not to maximize autonomy, but to find the right operating point on the curve. Read-only and user-level sandboxes provide stronger safety guarantees, though at the cost of lower remediation power. Human review helps shift that boundary: it allows higher-impact actions to be approved and executed safely, without granting the agent full autonomy. \nEnterprise deployment therefore needs a \nruntime safety \nlayer to constrain execution and provide governance and auditability. Moreover, we argue that we also need an \nenterprise learning\n layer to turn one successful repair into a reusable capability across the fleet, making the system smarter with every incident. \nRuntime safety layer\nWe built the prototype as a lightweight agent runtime embedded in the Nexthink Collector. The runtime is written in Rust and adds less than 4 MB to the collector binary footprint. \nThe core runtime consists of a main agent that process requests and routes them to specialized sub-agents. Each sub-agent is configured remotely by the IT administrator through a dedicated UI with four main controls: \nSandbox\n the execution scope the agent is allowed to operate in. For example, a read-only sandbox can inspect system state but cannot modify files or access the network.  \nWindows\n: we run PowerShell scripts in a hardened environment that restricts language complexities and allows a safe subset of diagnostic cmdlets. \nMacOS\n: each command runs inside Apple's built-in Seatbelt kernel sandbox, where an SBPL profile enforces deny rules at the OS level before the process executes. \nCapabilities\n package skills and a list of tools (e.g., CLI commands) available to that sub-agent and aligned with its operational role.  \nTrigger\n is a schedule or system conditions that activate the agent. \nAssigned model\n: the LLM selected for that role, balancing latency, cost, and capability. In our prototype, the main agent uses a frontier model (Opus 4.6), while lower-tier support agents use smaller models optimized for speed (Haiku). \n\nThe diagram below illustrates a read-only agent handling an IT issue  \nA user reports an issue: “I can’t access salesforce”. \nThe agent has read-only access and begins with diagnosis to identify the issue \nIt checks whether a pre-approved secure action already exists in the enterprise catalog: \nWhen such an action is available, it is executed locally and safely.  \nWhen it is not, the agent generates a new fix, which passes through guardrails and human approval before it is deployed.  \n\n\nThis is how the architecture extends agent capabilities without giving up safety, governance, or auditability. Validated actions can then be promoted into the enterprise catalog for reuse across similar incidents. This is where enterprise learning starts. \nEnterprise learning layer \nWhen AI agents operate in isolation and rely only on local memory, they are likely to repeat the same mistakes across devices and lose the opportunity to learn from related incidents. They cannot build the shared knowledge needed to improve the system. \nThe strongest architecture pairs secure local execution with a central enterprise learning layer. The local agent handles the immediate incident. The central layer creates the compounding value of enterprise learning. It captures the incident context, the actions taken, the outcome, and any human validation, then uses that evidence to identify reusable patterns across the fleet. \nConsider a VPN failure on one laptop. A local agent may find that the issue is a stale client configuration and repair that machine safely. The central system can then detect similar incidents across the fleet, correlate them with a recent policy or version change, and promote a validated remediation into a reusable script. What was a single repair becomes a reusable capability that enables proactive remediation.  \nWe already see value in a pragmatic first generation of enterprise learning. Teams at Nexthink are building capabilities around memory and reusable skills that help agents retain context and apply past successful resolutions. \nHowever, the broader problem requires deeper research. The challenge is deciding which local fixes generalize, under what conditions they are useful and safe, and how they should be governed before reuse. That is an active research track, and we will cover it in a follow-up post. \nConclusion  \nAI agents can now autonomously investigate and remediate IT issues, but autonomy alone is not enough for the enterprise.\nOur research explores the layers required for enterprise deployment: a safe runtime layer that makes local code generation and actions secure, and a learning layer that enables a self-improving system that turns individual remediations into enterprise knowledge. 


Why Autonomous AI Agents Need Safety and Learning