At 03:12 the root filesystem on web-03 crosses 91% used. The on-call technician’s phone buzzes once. By 03:18 the disk is at 61%, the check is green, the ticket is resolved and there is a two-line article in the knowledge base linked to the host. The technician typed one sentence and clicked once. This is the whole thing, start to finish, as it happens on a real box. Nothing here is a demo script; it is what discovery, the assistant and the service desk do when they share one database, with every decision the automation made and every one it left to a person.
Because discovery built it when the agent was installed. Guardian RMM runs 58 detection plugins against each host and builds a check per real resource it finds, bound to an action that can repair it. On web-03 that meant an ext4 root mount got a disk_root check with a vacuum_journal action beside it, a TLS certificate got a cert_expiry check bound to renew, the link got link_state, the drive got smart_status. Nobody wrote a configuration file. When the root mount passes its threshold the check goes critical, and because the check name and the host group are known, the intake rule routes the ticket to the Linux queue with the machine attached, live. No email was parsed. What discovery finds, in detail.
The sentence is “web-03 is out of disk, sort it out”. It is an open request rather than a recognised one, so it does not match a capability outright; if it had been “restart apache on web-03” the platform would have routed straight to a vetted action with no model call. Instead the assistant plans four steps with an open-weight model running on infrastructure we operate, gives each a risk level, and shows the exact commands before anything runs. Why the two paths are different.
One. Two commands are read-only, carry no risk and run immediately; they find that the journal is using 3.1 GB. The vacuum changes things, so it stops for a person. The technician reads the command, sees “low risk”, and clicks. If they had chosen “approve the plan once”, the whole list would have run after one read-through. On unattended, the vacuum would still have run, because it is low risk rather than destructive; a command that deleted data would have stopped in every mode, because destructive commands hit a floor that no setting can lower. The three modes and the floor.
The last step re-runs the check rather than trusting the command’s exit code. disk_root comes back OK at 61%. The recovery is announced once, not once per check on the host, because recovery bursts are held back on purpose. The intermediate flaps while the vacuum ran were damped, and each suppression is recorded with its reason, so if anyone asks later why the host did not page three times between 03:12 and 03:15, the answer is written down.
Into the ticket, and from the ticket into the knowledge base. The technician writes two lines of resolution and publishes them from there, as themselves, already linked to the client and to web-03. The next time this host fills up, the article is on the ticket before anyone opens a terminal. Nothing was copied between tools because there was only one.
The password. The terminal session was opened with a credential injected from Guardian Vault, server-side; the plaintext never reached the browser. The event in the audit trail records who, when, from where and which permission allowed it, and it records a use rather than a reveal. One trail has the whole story in order: the alert, the routing, the plan, the approval, the commands, the recovery with its suppressions, the article. The same night from four logs instead.
Walk it. The monitoring tool emails the desk. A keyword rule guesses a queue. The technician copies the hostname into the ticket, opens the documentation tool, reveals the root password, pastes it into an SSH client, runs the same four commands from memory, closes the ticket, and means to write it up in the morning. Ten minutes of copying and looking up on a good night, an audit trail that ends at the reveal, and a knowledge base that never hears about it. Repeat for every host that fills up the same way every month.
On anything the agent cannot be installed on. A switch, a firewall or a printer reached through a collector can be watched from the outside: whether it is up, its ports and HTTP endpoints, SNMP polling and traps, a vulnerability scan across the network. What a collector cannot do is run a script on it, inventory its software, or open a terminal to it. The incident above needs the agent on the box. That is the honest boundary of “fixes itself”, and we would rather draw it here than have you find it at 3 am.
Thirty minutes on your noisiest host, walked through one system. No slides unless you ask.