At 14:05 a technician types “restart apache on web-03” into the assistant. Nothing is planned. No model is called. The request matches a capability the platform already knows, the vetted action runs, and the result comes back in the time it takes the service to restart. At 14:20 the same technician types “web-03 is out of disk, sort it out”. That one is different. There is no single action for it, so the assistant plans with the model, shows the plan with a risk level on each step, and waits. Two requests, fifteen minutes apart, two completely different paths. This post is about why the split exists.
Capability matching is the first thing Guardian Plus does with a request in plain language: if it recognises the request as one of the actions the platform already has, it routes straight to that vetted action, with no model call at all. The result is faster and fully deterministic. Only a request that does not match a capability goes on to the model to be planned.
Most of what a technician asks for on an ordinary day is not novel. Check disk space on a host. Restart a service. Show the last hour of a check. These are the same actions discovery bound to checks when the agent was installed, and the same actions a workflow would call. Capability matching is simply the assistant recognising that the sentence you typed is one of them.
Because a model is the wrong tool for a request you already understand. For a recognised request the deterministic path wins on every count that matters in operations.
Latency. A vetted action runs immediately. A planned request waits for the model to produce a plan and then for a person to read it.
Determinism. The same sentence produces the same action every time. There is no plan to vary between Tuesday and Thursday, and nothing to re-read for the two-hundredth restart.
Auditability. The action that ran is the action that was vetted. The trail records which capability matched, not a generated command that has to be reviewed after the fact.
Exposure. A request that never reaches a model never sends its context anywhere. For the boring majority of requests there is nothing to have a data-handling conversation about.
It goes to the model, and everything about governed automation applies to it. The assistant plans the work and shows you the objective, each task, its risk level and the exact command before anything runs. You choose the approval mode per conversation: approve every step, approve the plan once, or unattended. You can skip a task, reorder the plan, redirect it or stop it without starting over, and when a task fails corrective steps are proposed under it for your approval. The out-of-disk incident, minute by minute.
Yes. Destructive commands stop for a human either way. A vetted action is vetted precisely because someone decided what it does and what it is allowed to touch, and a planned command carries a risk level that stops it at the floor if it is destructive. A recognised request that happens to be destructive does not get a shortcut past the floor because it was recognised. The point of matching is speed and predictability for safe work, not a way around the controls.
On the vetted-action side. Guardian RMM ships with 58 detection plugins that build a check per real resource and bind each to an action that can repair it, runs standard Nagios plugins and imports NagiosQL configurations, and lets you build remediation actions in Python for application-specific monitoring. An action you wrote sits beside the built-in ones as something the platform knows how to do, rather than something a model has to invent a command for each time. That is the distinction that makes the deterministic path grow with your estate instead of staying a fixed list.
It is an open-weight model on infrastructure we operate, or on your own if you would rather host it. There is no OpenAI, Anthropic or Azure OpenAI account anywhere in the platform, so even the requests that do reach a model do not leave for a vendor. Every tool the assistant calls re-derives the permissions of whoever asked, so it cannot see a record you cannot. Actions that change things are hidden from the assistant entirely and need a person to confirm, and your most sensitive documents are never fed to a model at all. How to find out what your current tool does.
A model round-trip and a plan to read for a request you have typed two hundred times. On a busy day that is minutes per technician spent approving the obvious, and it is the fastest way to train a team to click approve without reading, which defeats the entire purpose of showing the plan. Reserving the model for the requests that need one keeps the approval step meaningful for the requests that deserve it.
First, the “80%” in the title is a way of speaking, not a measurement we have published. The share of your requests that match a capability depends on your estate and on how many actions you have added; we have not counted yours. Second, the trail that records which capability matched and which command ran is append-only, enforced by the database, but it is not hash-chained. No interface can alter it. We will not call it tamper-proof, and we say the same on the security page.
Discovery that builds the checks, capability matching for the recognised requests, and a plan you read before you approve it for everything else.