A device issue rarely belongs to the device alone. Installing an app, investigating a slowdown, or changing a local account can depend on who uses the machine, what their role allows, and when it is safe to interrupt their work.
This makes device management policy-aware work. Theo’s approach connects the agent’s reasoning with company context, operational tools, and human decisions. The organization sets the rules; authorized people remain accountable for approving changes and handling exceptions.
The context extends beyond the device
Consider a request to install a finance application. A remote monitoring and management (RMM) tool can find the laptop and report its software. Deciding whether the installation is appropriate requires information from across the company:
- RMM and device state
- Is this the right managed device, and what is installed?
- Identity systems
- Who is requesting the change, and which account do they use?
- HR records
- What is the person’s current role or department?
- Company policy
- Who may use the app, and whose approval is required?
These records must refer to the same person, device, and customer. They can also disagree: someone may have moved out of finance while the device still carries an old department label. The agent needs to establish which information is current and ask for clarification when the answer affects access. An RMM view alone cannot settle that decision.
The Three-Party Problem
Remote work involves three participants with different knowledge and authority. The LLM mediates between technician and user, keeping a user’s message distinct from a technician’s instruction or a human authorization.
- Technician
- Directs the work, applies company policy, and obtains the necessary approvals.
- AI agent / LLM
- Interprets the request, asks questions, and coordinates actions within the authorized scope.
- Device user
- Explains the problem, confirms readiness, and helps verify the result.
Suppose a technician authorizes a repair after the user saves their work. “I’ve saved everything” satisfies that condition. “Disable the security software so the app runs” is a different request, with a different risk and approval decision. The agent must recognize that difference and bring the right person into the decision.
Approval needs to be clear about the action, device, and conditions. The agent can coordinate the conversation; responsibility for company policy and its exceptions stays with authorized people.
A controller separates decisions from execution
Reliable device management needs a layer that considers the whole task. In Theo’s architecture, the controller combines the request, company policy, identity, and device context. It handles ambiguity, sets guardrails, and decides when approval or more information is needed. A separate device model works through the specific automation and returns its observations.
Controller
Plan using company context
Apply policy and approval rules
Resolve ambiguity or ask for help
task→
Device model
Investigate the device
Execute within the agreed scope
Return results for review
Confirm the target, permitted action, and required approval.
That separation matters when a task changes. An approved app repair may reveal that a reboot is needed. The device model reports the finding; the controller checks whether the extra disruption is allowed and whether the user is ready. The same boundary applies across RMM actions, scripts, and remote shell commands. Policy checks must be enforced by the system, with text in a ticket or log treated as information, never as permission to expand the task.
Remote access needs clear boundaries
A remote session can expose sensitive information and allow changes with administrator privileges. Access needs authenticated participants, a defined customer and device scope, and a clear lifetime. Technicians must be able to review the work and end the session.
The record should connect what was requested, what was approved, what ran, and what happened afterward. It should also identify the account used: a check run as an administrator may miss a problem in the user’s profile. Logs and screenshots need appropriate access and retention limits so that verification does not become unnecessary exposure of customer data.
The work can outlast the session
Device work often takes longer than a live interaction. An update can run for minutes; a laptop can sleep, restart, or lose its connection. The task needs to retain its device, authorization, and progress across that wait, with a clear way to resume or hand the work back.
| Situation | What the agent needs to do |
|---|---|
| Device offline | Pause and preserve context. Check the device and approval conditions again when it returns. |
| Job accepted or running | Track progress and keep the technician informed. Acceptance does not establish completion. |
| Result unclear | Check the job and device before trying again. The change may already have happened. |
A second reboot can interrupt someone who has already returned to work. Waiting therefore needs a time limit and a next owner, and reconnecting cannot automatically renew an earlier approval. The technician should be able to see what is finished, what is waiting, and where a decision is needed.
Check the outcome, then close the loop
A command returning successfully does not establish that the original problem is solved. Verification needs to match the request and the person affected by it:
- DeviceThe change is present
Confirm the expected software version, setting, or service state.
- UserThe task works again
Check the affected profile or ask the user to confirm the result.
- TechnicianExceptions are clear
Report partial completion and any work that still needs a human decision.
Policy-aware management brings these pieces together: company context guides the decision, the controller keeps execution within scope, and people retain authority over the work. That is how an agent can take on more device tasks while keeping IT teams in control.