Monitoring is built on thresholds, and a threshold needs an event to fire. It can tell you a backup failed. It cannot tell you a backup was never attempted — the policy quietly stopped covering a volume, the schedule was disabled during a migration, the job was removed with the host it protected. Nothing errors, no page fires, and the gap is found at restore time. Absence is not a louder alert. It is a different question, and it is one an agent watching continuously can hold and a rota cannot.
Seven nights. Six of them produced a job with a result — success or failure, either way a record. On the fourth, nothing was produced at all. There is no alert for that cell, because there is no event to attach one to.
The dashed cell is the incident. It is invisible to every threshold you have.
Every automation programme starts with the same request — write down what you do — and it fails for the same three reasons. The documentation is stale. The people who know are the people with no time. And in a programme whose stated purpose is reducing headcount, asking someone to describe their work has an obvious and entirely rational answer: describe less of it. Discovery that depends on goodwill is discovery built on the one thing the engagement removes.
So we start from evidence instead. Ticket timelines say what was requested and when it closed. Platform audit trails say what was actually executed against which system. Joining them reconstructs the runbook your team practises — including the steps nobody wrote down, and the ones the written procedure gets wrong.
Not the documented one. Each recurring request type, the actions actually taken, in the order they were actually taken, with the timings they actually took.
Every reconstruction is labelled: matched by actor and time window, matched by window only, unmatched — or unobservable, meaning the system in question emits no trail we can read. Unobservable is not the same as "no actions taken", and conflating the two is how automation programmes quietly encode a fiction.
Your engineers review a draft rather than author one. That is a materially different conversation to have with a team that has heard the word "automation" before.
Where procedure is missing or wrong, the reconstruction becomes the new document — and it is regenerated from evidence, so it stops being stale the moment it is written.
Nobody sensible gives an agent write access to a production storage estate on day one, and nobody should ask you to. Each loop moves through the same three stages independently, so the low-risk ones can be autonomous while the destructive ones are still shadowing.
Read-only. The agent builds the inventory, learns the expectations, reconstructs the runbook and reports what it would have done — against real events, with no ability to act.
The agent proposes on every real ticket, and a human decides. The disagreement rate is the number that matters, and it is measured, not asserted.
The agent acts within an explicit envelope, with destructive operations still gated, a stop that is checked on every call, and a signed record of what it did.
Promotion is earned per loop against a measured threshold — not scheduled, and not a judgement call made in a steering committee.
Infrastructure operations is not one job. It is a small number of loops that recur, each with its own rhythm, its own evidence and its own risk profile.
Agents act through the same APIs your engineers use, with credentials scoped per system and per customer. No new agent on your hosts, no new collector in the data path.
Enterprise NAS and scale-out platforms — volumes, quotas, snapshots, replication relationships, cluster health.
Backup policies, schedules, job history, retention, and restores that are validated before they are trusted.
Entity topology, problem feeds and metrics — as a source of truth about state, not as another dashboard.
Incidents, requests and changes: where the work arrives, where it is recorded, and where the agent stays accountable.
Least privilege is derived, not guessed: the permission specification for each system is generated from the operations the agent is actually allowed to perform, and drifts are caught when the two stop matching.
If you operate infrastructure for several end customers from one delivery team, the hard part is not the automation — it is the separation. Credentials, data, evidence and reporting stay partitioned per end customer, and the work an agent does is attributed to the customer it was done for. That attribution is what lets you show each of them what was delivered, and bill for it.
Point it at one platform and one queue. In a few weeks you get the reconstructed runbook, the honest confidence level on each part of it, the gaps the absence guard found, and a measured disagreement rate from shadowing. If the queue turns out to be less automatable than anyone hoped, you will see that too — and that is worth knowing before a programme is committed to.