The board

Which tickets run themselves — and which must not

Automation is granted per client, per procedure, per action class. Below is a live-shaped board of a working day, followed by the exact boundary the system enforces.

Inbound 0
Verifying 0
Working 0
Resolved 0

The board is a demonstration loop, not live data. Every card on it is fictional.

The boundary

What the AI may do alone, and what it may never do

This table is the contract. It is enforced in code, not by prompt.

Allowed unattended

  • Read anything on a device in the client's scope, and record it
  • Close an alert whose evidence is benign and whose procedure is approved + auto-enabled
  • Write internal notes, and attach what was found
  • Append to the client's KB with the ticket as provenance
  • Propose a procedure as a draft
  • Create follow-up tickets, deduplicated

Never unattended

  • Send a customer-visible reply, or close a person-filed ticket
  • Delete data, remove an account, wipe or reinstall
  • Reboot a server, or take a service offline
  • Change anything whose evidence came back unknown
  • Touch a device owned by another client on shared infrastructure
  • Reveal a credential: values are injected into a tool, never into a model
Lifecycle

Two state machines, and the ERP wins

The helpdesk owns the ticket. The AI keeps its own shadow state so it knows what it has already done — and never to contradict the helpdesk.

ERP ticket stage

Set by people, and by the AI only through a permitted transition:

New → In Progress → Waiting on Customer → Resolved
Cancelled · AI Closed (a distinct stage, so "closed by the machine" is auditable)

AI shadow state

new → claimed → triaging → working → resolved
  ↳ awaiting_customer  ↳ escalated  ↳ handed_off
skipped · error

Keyed 1:1 on the ticket reference. Deleting the ticket in the ERP deletes the shadow.

Volume

A day, as the ledger records it

26tickets polled all origins, before any filtering
11closed with evidence procedure-backed, benign, no change
7device actions each with an approval and a rollback
4procedures mined drafts waiting on a technician
And the hours. The ledger separates minutes saved, minutes spent supervising, and work it genuinely cannot attribute. It reports the last category as unmeasured. A quiet day cannot be read as a lazy one.

What happens on a ticket the AI is not allowed to touch

It still gets triaged

Evidence is gathered, the client and machine are resolved, and the KB is searched — so the technician opens a ticket that is already half done.

It becomes a chat, not an email thread

A decision chat holds the session that paused. Everything the AI checked is visible, and asking "which machine?" is answered with data instead of a reply.

It closes the loop afterwards

Whatever the technician decides becomes a procedure draft and a KB line, so the same ticket shape is cheaper next time — with a human still in the loop until it has been right, supervised, more than once.

See it in motion → Deploy it →