AI first-line technician · in production

Most tickets never needed a human.
The rest needed one sooner.

BlueHelp AI sits between a real ERP helpdesk and a real remote-management platform. It reads the ticket, proves what is actually happening on the machine, fixes the things a technician has already signed off on — and escalates everything else into a chat with the groundwork already done.

Every name, host and ticket number on this site is fictional. The shapes of the work are not.

helpdesk · one ticket, as the system sees it
# 02:04  ticket arrives — machine generated, nobody has read it
TICKET/41207  [ALERT] Backup job "Nightly-FS" completed with warnings

# 02:04:30  the verifier reads the device before any model sees text
rule      alert.backup.warnings     matched
host      FS02                      owned by client ✓
probe     BackupAgent events, last 8h
verdict   benign · 3 files skipped, all "in use"

# 02:05:10  approved procedure, auto_enabled, both checks pass
proc      #212 "Backup warnings — in-use files only"
policy    evidence=device · disposition=benign

# 02:05:48  closed, with the reason written on the ticket
stage     Open → AI Closed
human     0 minutes
708procedures approved rules the AI may act on, written as data — not code
1194devices agents the AI can read and act on, all through one channel
90 spoll from ticket landing in the ERP to evidence on the desk
0silent changes every mutating action carries an approval and a rollback line
The whole loop

One ticket, ten steps, all of them observable

Nothing here is a black box: each hop is a recorded action with an input, an output and a reason. If a step cannot be proven, the loop stops and becomes a conversation with a technician.

01

Arrive

Email, portal, or machine alert — all land in the ERP helpdesk.

02

Verify

Code, not model: is this alert real? Who owns the host? What does it say?

03

Triage

The model receives the evidence and one decision to make.

04

Resolve

Client, site, machine, KB article — mapped from data, not guessed.

05

Ask

Unproven? A stateful decision chat with everything already gathered.

06

Learn

Procedure mined, KB updated, spend and minutes written to a ledger.

The two rules that shape everything

Evidence before model. The proof comes from the device, the API, the log — not from the wording of the ticket. A model that only reads the ticket can only guess, and a guess that closes a ticket is the most expensive thing this system could produce.

Nothing changes silently. Reads are free. Writes are gated: by capability, by procedure status, by approval — and every one of them leaves a line on the ticket and a way back.

Read the ten steps →
The measure is not coverage.
A rise in tickets closed together with a rise in wrong closures is a failure, not progress. The system reports what it could not measure as unmeasured — never as zero.
Human in the loop is a position, not a promise.
A close, a customer email, a reboot, a delete: all of these stop and wait for a person to say it in the room. The authorising sentence is written to the ticket, attributed.
Watch it happen

Four runs, sanitised, animated

The same sequences the system produces in production, with the client, the hosts and the numbers replaced.

Run it yourself

Every piece is a container, and the model is swappable

The helpdesk, the RMM, the execution plane and this site are separate containers on one Docker host. Point the AI at a local model on your own GPU, or at Anthropic, OpenAI or xAI — it is one setting, not a rewrite.

  • docker compose up
  • Ollama / vLLM
  • Claude
  • OpenAI
  • Grok
  • no vendor lock-in
Docker & AI setup →
.env — the only thing you change
# local GPU, nothing leaves the building
AI_PROVIDER=ollama
AI_BASE_URL=http://ollama:11434/v1
AI_MODEL=qwen2.5-coder:32b

# …or a hosted API
AI_PROVIDER=anthropic
AI_MODEL=claude-sonnet-5
AI_API_KEY=${ANTHROPIC_API_KEY}

# or openai / xai — same interface, same tools