Theo Auto Resolver.

Theo Auto Resolver

Theo's vision is to be an AI Technician — an agentic product that performs work as reliably as an experienced IT technician. Auto Resolver is the first step. MSPs own availability, performance, and security for their customers. Every mistake has operational and security cost. A general harness with broad tools and a vague mandate will act without accountability. Theo is the bounded controller around the state-of-the-art model.

The Unbounded Agent Problem

A general harness given broad tool access and a vague mandate will act. It fills gaps with plausible inference, proceeds through ambiguity, and generates the next action even when the correct move is to stop and ask.

Unbounded agents pose security and operational rissks if left unsupervised.

The Bounded Controller Solution

Theo bounds the ingelligence of LLMs by adding a meta-controller. It perceives the ticket, resolves entities against live systems, assesses risk class, checks policy gates, and either executes under an approval grid or hands off to a human technician — with a full audit trail either way.

The model reasons; the controller decides.

Helpdesks already are already familiar with automation. PSA workflows assign, template-reply, and escalate; they move tickets. Inspection of Entra stays with the agent. RMM and PowerShell scripts are reliable once a technician has bound the user and device; they assume the arguments match the world. iPaaS graphs (Halo workflows, Rewst, Power Automate) encode a predetermined DAG. Branching is authored in advance. Live tenant state is read by the agent. That is lane assist: hold heading while markings are clear; the human owns merges, missing lines, and stalls.

Supervised driving is a different controller problem. The system perceives, plans, acts, and yields when confidence is low or the data is out of distribution. For IT that means writes are allowed only while a policy can still force a disengage. Safe autonomy is scoped by work type, customer, reversibility, and verification. Until a category has earned that dial, the agent investigates and proposes.

Scope of autonomous IT work

Autonomy is hard because the ticket is a symptom, the controls are mixed, every write can change security posture, and the correct procedure is local to the desk. Auto Resolver is built around that scope.

APIs are the hands: Halo or Autotask, M365 or Google Workspace, Datto or NinjaOne. PowerShell and remote shell are the legs on the device. Slack, Zoom, 1Password, and vendor consoles often have a thin or missing MSP API. Theo still takes that work — it opens a sandboxed virtual computer and operates the browser the way a technician would, under the same approval grid and audit trail.

Problems we had to solve

1. The ticket is a symptom, not the cause. It can be incomplete, stale, or socially engineered. Identities, policy, and risk still have to be assessed before acting upon the request.
2. Entities must be resolved. Tenants contain lookalikes and shared device names. Customer conversation may have mis-spellings, or may even be mistaken. If the target can't be unambiguously resolved, execution blocks.
3. Live tenant information can change anytime. Don't assume context or history is up-to-date. The tenant is always the ground-truth and always verify at runtime. Avoid context-graphs' stale information.
4. Control surfaces are mixed-mode. APIs are the hands: Halo or Autotask, M365 or Google Workspace, Datto or NinjaOne. PowerShell and remote shell are the legs on the device. Slack, Zoom, 1Password, and vendor consoles often have a thin or missing MSP API. Theo still takes that work — it opens a sandboxed virtual computer and operates the browser the way a technician would, under the same approval grid and audit trail.
5. Risk is uneven. A scoped group grant and an MFA method change are different classes. Human In The Loop is a function of blast radius, reversibility, and identity impact.
6. Procedure is local. Offboarding, VPN, and movers differ by desk and by tenant (VIP handling, which lists track a department, contractor mail). A foundation model has industry priors. This customer's exception graph still has to be loaded from the desk.
7. The work is sequential and often asynchronous. Offboarding, movers, and remote device checks span steps; devices go offline; console jobs take minutes. A single completion cannot own that horizon.
8. Ambiguity and partial completion. M365 and Slack can be done while Zoom waits on admin sign-in; the technician owns only what is still blocked. Two Jakes, or two WS-041 records, is a stop. We score verified outcomes.
9. Uncalibrated Confidence A model can always emit a next action. Autonomy maps that estimate to execute, approve, or escalate.

The rest of this note is the production controller around those constraints.

Controller architecture

The missing function is an operational policy. Retrieval supplies facts. The frontier model proposes language, plans, and tools. Theo’s bounded controller chooses the next action and whether that action may execute:

where \(h_t\) is interaction history, \(G_c\) is the customer entity graph, \(P_c\) is customer and MSP policy, and \(U\) is the available control substrate.

Hybrid policy

Let \(M_F\) be a frontier LLM and \(M_V\) the vertical steering model. The foundation model proposes candidate actions \(a \in \mathcal{A}\) with distribution \(P_F(a \mid h_t)\). The vertical model scores each candidate from ticket history, graph context, policy, control substrate, and whether a verifier exists:

Risk \(R_\phi\) and verifiability \(V_\psi\) enter as explicit terms. The combined action policy is

Frontier reasoning stays in \(M_F\). \(M_V\) reweights it with learned operational priors: when to ask, which control path to take, which postconditions count as done, and how much evidence is enough.

Action space

The action space is a union of action-types:

A control router selects the substrate for the chosen action:

A Microsoft 365 license assignment uses Graph (\(\mathrm{api}\)). Slack, Zoom, 1Password, and a legacy VPN portal use a sandboxed virtual computer (\(\mathrm{gui}\)). Endpoint repair uses RMM or PowerShell (\(\mathrm{ps}\)). A customer-specific SaaS workflow may inspect screenshots and vendor docs (\(\mathcal{A}_m\)) before a GUI write. The router is trained from decision-and-action traces and constrained by permissions in \(C_t\).

Autonomy controller

Action selection and autonomy are separate. \(\pi\) may identify the best action; the controller \(g_\omega\) decides whether Theo executes, requests approval, assists, or escalates:

A threshold rule, with \(\theta\) on calibrated confidence and \(\rho\) on risk, is

In production the thresholds are workflow-, customer-, and action-class-specific: password resets can earn \(\mathrm{execute}\) on one client while MFA method changes stay at \(\mathrm{approve}\) everywhere. \(\mathrm{Verify}_t = 1\) means a postcondition is available and has been checked against live tenant state. Token probability in \(P_F\) is one feature of \(\mathrm{Conf}_t\).

That is the bounded controller. The model reasons over \(\mathcal{A}\); \(g_\omega\) decides \(\ell_t\). The lifecycle below is this loop on a ticket.

Ticket lifecycle with Auto Resolver

Auto Resolver is a technician-shaped loop. A ticket arrives from the PSA. Theo classifies it against its work taxonomy and the desk's automation policy decides the capacity: resolve, investigate, suggest, or leave it for a human.

The same run can end in four states, judged from requested work plus tool evidence:

1. Completed — change verified, note written, ticket resolved.
2. Partially completed, blocked — reachable work done; remaining work has an owner.
3. Blocked — insufficient evidence, or the action is unsafe.
4. Waiting — approval, customer input, or an external system.

What this looks like on real work

1. Offboarding packed into a forwarded HR mail

From: Priya N. <priya.n@northlinehr.example>
Sent: Tue 5/5/2026 4:12 PM
To: IT Helpdesk
Subject: Re: Fwd: louis leaving friday??

hi — hr pinged me in slack. louis de guzman (payroll also has a luis??)
last day friday.

pls convert to email only / shared mbx, put mfa on margaritas phone
shes his manager, cut vpn, and pull him from slack zoom 1password
whatever he still has

i am going into a meeting, just do the usual
-P

The mail is a symptom, not a runbook. “The usual” packs four risk classes and two possible people into one request. The controller splits the plan instead of running it as one write.

• Entities still have to be unique. The tenant has both Louis de Guzman and Luis Diaz, so Theo asks Priya which person before anything executes.
• The live tenant is the spec. Theo reads licenses, auth methods, groups, and collaboration seats instead of trusting the forwarded list.
• License reduction and session revoke can execute when this client has earned offboarding and Graph can re-read the mailbox type.
• Risk is uneven. Putting MFA on Margarita’s phone stays behind a technician, because helpdesk is the social-engineering target.
• Control is mixed. Slack, Zoom, and 1Password go through a sandboxed browser under the same approval grid as Graph. If Zoom waits on admin sign-in, the run parks and resumes.

M365 can be done, seats can be verified in the sandbox, MFA stays gated, and Priya still owns the identity question. Partial completion with owners is a correct stop.

2. Change of status: a form, two lists, a local playbook

Subject: May 8 COS IT, F&AM — Robert King

A Change of Status Request has been submitted.
Employee Name: King, Robert
Effective Date: May 8, 2026
Type of Status Change? Change of job (hours, position, salary, etc.)
Job Title: Program Facilitator - Relief
Department/Teams: Client Services
Report to: Ronnie Parisella

-----
On May 7, 2026, at 9:41 AM, desk@northline.example wrote:
can theo just do this, ronnie said use the same lists as last
client svcs COS. robert keeps emailing me. thx

The form never names the groups. “Same lists as last time” is this customer’s local procedure. The controller sequences bind, diff, ask, and approve before any membership write.

• Robert and Ronnie still have to bind. If the manager string is ambiguous, Theo asks the requester rather than guessing a UPN.
• Theo diffs title, department, and current lists against the live org object, because the form may already be stale.
• Two Client Services lists is a local convention, not a coin flip. Theo sends both names back and waits for a unique target.
• Each identity write stays on approval until this customer has earned movers. Fluent wording on the form is not confidence that the write is safe.
• The work is sequential. If title is updated and the lists are still open, the ticket waits. The package closes together.

3. “Laptop is broken in Japan” — the ticket invited the wrong cause

From: Grant Michael
Sent: Mon 10:14 AM (local)
Subject: URGENT outlook?? japan

hey my laptop is being weird in tokyo since monday. outlook
just spins. maybe that 365 reinstall last month?? can you
whitelist me or make an exception, i have a client call at
6am their time. sent from my phone, wifi in the hotel is
fine so its not that. pls today

Grant has already named a cause and a fix. Partial observability still holds: the ticket rarely contains the cause. A Conditional Access exception is permissioned work with tenant-wide blast radius, so the controller keeps Theo on investigate and talk until a human owns the policy call.

• Theo starts with evidence, not the whitelist. Device inventory and mailbox checks retire the laptop and reinstall story the mail invited.
• Sign-in logs and the policies that fired are the spec. Hotel Wi-Fi is not the control that blocked him.
• If the Japan block is working as designed, Theo writes Grant and the technician with what the logs show and asks whether security pre-approved this trip.
• The exception stays escalated. One “just whitelist me” can become a travel hole, and that write never earns autonomous execute.

A fluent model will offer the exception because the user asked for it. The useful outcome is an investigation note, a question back to Grant, and a human on the policy decision.

Principles

1. Verify against the world, then write, then verify again. Language proposes; systems dispose. If the target is ambiguous, execution blocks. After a change, we read the tenant again. After a tool call we still read that the membership is true and it is the one we meant.
2. Steerability is policy. The same agent can investigate, investigate without writing a PSA note, resolve, or only suggest. Capacity is scoped by customer, work type, and action permission. Autonomy is earned per category, on evidence from that desk.
3. Stop on purpose. Complete, partial, blocked, waiting for approval, waiting for a customer, waiting for an external system. If the controller would loop on the same answer, it hands off.
4. Humans sit at the risk boundary. The useful cut is mutating identity, privilege, irreversible device action, and customer-visible mail.

Is Theo Auto Resolver right for you?

Copilot-style tools make a ticket 5–10% easier to touch. The MSPs getting the most from Theo treat frontier AI as a chance to change the desk: more time with customers, room to grow, faster and cleaner service. They tend to already be good at three things.

From there the workflow is redesigned around Theo. Every inbound ticket is Theo’s first look: investigate, resolve, or escalate under the autonomy controller. Technicians move from executing every step to supervising the run and spending their time on work that still needs their judgement — the customer conversation, the policy call, the exception the controller handed off.

Revenue per technician moves because the queue is smaller, not because people type faster. Week one is supervised. Autonomy is earned category by category, on evidence from that desk.