Ticket automation is usually scoped as a language-model problem: classify the request, draft a reply, set a status. Classification is cheap. Resolution is a short workflow across a PSA, an identity plane, documentation, an RMM, and whatever customer app the ticket actually names. Those systems were never one platform. The bottleneck is the vendor contract.
APIs are missing
Even mature APIs omit operations that appear daily on an L1 board. An agent that can only issue REST is scoped to writes that are documented and tenant-portable. That subset is real. It is not the queue.
| Surface | What the API covers | What still needs a console |
|---|---|---|
| Microsoft Graph | Identity and mail for a large fraction of L1 | Remaining Exchange / Entra work, including some MFA method changes |
| PSA | Create a ticket and a note | Tenant-specific status maps and custom fields |
| RMM | Device inventory | A durable endpoint ↔ user ↔ customer join |
| Customer SaaS | Often none — a session and a form | Spam allow-lists, distributor licences, printers, admin consoles |
The APIs that exist are often not robust
Presence is not reliability. Treat every vendor as a clean resource server and you leave state inconsistent. A technician retries, re-reads, and continues in the console. An unattended graph treats the first non-2xx as terminal, or double-applies a non-idempotent POST.
| Failure class | What you observe | If the client is naive |
|---|---|---|
| Ambiguous commit | Timeout after a write; partial write with no compensate | Retry a mutation that already landed, or skip one that did |
| Stale or incomplete read | Dropped pagination page; 200 on update, stale GET immediately after | Decide from a partial or outdated view of the tenant |
| Non-portable contract | Duplicate webhooks; 403 in the next tenant (SKU, role, sovereign cloud) | Double-apply, or a run that only works in the tenant you tested |
Computer use closes the gap — if it is reliable and tested
Absence of a method does not end the work. The operational fallback has always been the browser. Computer use is that fallback inside the agent loop: a remote session that performs the mutation the API cannot, then returns a typed outcome the rest of the turn can use (PSA note, close, halt). An unsandboxed jump box is not that.
| Control | What it enforces |
|---|---|
| Isolation | Per-client profiles and credentials; prefer the API when the contract is sufficient |
| Bounds | Explicit timeout and retry budget on a deterministic script, not an unbounded session |
| Observability | Recording (or an explicit skip) and the same audit log as Graph or PSA — not a side channel |
| Human path | Cancel and sign-in hand-off when unattended auth cannot proceed; fail closed if a selector dies |
Reliability here is not a prompt. Scripts are functions against a session — selectors, step ledgers, known-issue classification, timeout and retry, recording lifecycle, rescue after technician sign-in — unit-tested like any other action. If a console changes, the run fails closed with a recorded artifact. It does not silently skip the mutation.
Computer use does not replace APIs. It makes the missing and unreliable ones a tested path instead of an escalation.
That is what makes end-to-end resolution scalable
Scale here is not “more workflows on a canvas.” It is covering the combination of tenants and vendors without a new graph for each hole in a contract. Typed actions handle the API surface (in Theo, 500+ actions across identity, mail, licensing, groups, devices, plus Datto RMM or NinjaOne where those agents exist). Computer use handles the remainder under the same policy: autonomy starts at zero, MFA method changes stay gated, every call is logged.
End-to-end then has a precise meaning: the mutation landed in the client tenant, the PSA record is in a terminal status, and an engineer can reconstruct the run from the audit log — including any browser session — without opening five admin consoles. Without a reliable computer-use path, that definition only holds for tickets that already had a sound API.