Sanitised replays

Four tickets, four different kinds of work

Each replay below is an animation of a real exchange pattern: a technician asks a question, the AI proves the answer on an actual machine, and the ticket moves. Client names, hosts, IPs and ticket numbers are fictional; the tool calls and outputs are shaped exactly like production.

Automated Coding Proxmox Decision chat
Replay 01 · automated

A backup warning that closes itself

Machine-generated ticket. Nobody has read it. The verifier reads the device before a model is involved; the procedure matches; both of its conditions pass; the ticket is closed with the reason written on it.

Why it may act

Procedure is approved and auto-enabled, evidence came from the device, and the disposition is benign.

What it could not do

Post a customer reply, or close anything whose probe returned "unknown".

What was recorded

Probe output, procedure id, closure reason, and zero technician minutes.

Replay 02 · coding

The report nobody wanted to maintain

A regular ticket where the fix is code. The AI proves which layer is wrong before editing anything, works in a throwaway container that mirrors the client's stack, runs the tests, and hands back a diff with a rollback line. The technician merges; the AI never deploys to production on its own.

The pattern that matters: data first, code second, proof before either. "Is the report wrong, or is the data behind it wrong?" is answered with a query, not an opinion.
Replay 03 · Proxmox

A VM that fills its disk every Saturday

No SSH, no web console, no password: the hypervisor is an agent like every other device, so the AI reaches it through the same audited channel. It finds the cause inside the guest, refuses to delete anything, grows the disk only after an explicit approval, and files the fix as a procedure that still needs supervision.

Read-only first

Storage, guest config, guest-agent usage — all reads, all recorded.

One mutating step

A 40 GB grow on thin storage: no data touched, nothing deleted.

Filed, not trusted

The cleanup procedure is a draft because it contains a delete.

Replay 04 · escalation

When it cannot prove it

"Everything is slow", from an address nobody recognises. The system resolves the client, finds six candidate machines, and stops — with a decision chat that already knows what it checked. Two questions later the root cause is found without asking the customer anything.

Reading these honestly. The animations show the pattern of work, not a benchmark. The system's own rule is that coverage is not the metric: if closures rise and wrong closures rise with them, that is a failure. Everything that comes back "unknown" is supposed to reach a human, not a guess.
Run the stack in Docker → See the board →