Why your AI operator should be allowed to do nothing
An agent that can intervene on its own feels powerful — and that is exactly why it is unreliable. On the separation between observing, reasoning, acting and remembering, and the guardrails that are the bare minimum around it.
The demo is always the same. An AI agent reads a monitoring alert, reasons out loud about the cause, restarts the service and proudly reports that the problem is solved. It looks like the future. And it works — until the agent draws the wrong conclusion once and makes that same fluid move toward an action you never wanted.
The temptation: an agent that gets to act on its own
Autonomy is appealing because it removes the last step. You no longer have to look, no longer have to click, no longer have to lie awake. The system repairs itself. That is exactly the image agent frameworks are sold with: give the model tools, and it will solve the problem.
The problem is not the reasoning. Modern models are surprisingly good at recognizing patterns in logs, connecting the dots and formulating a plausible diagnosis. The problem sits in the jump from plausible to executed. A diagnosis that is 80 percent right is useful as advice and dangerous as an action — because the action is irreversible and the uncertainty is invisible.
Why autonomy and reliability work against each other
An operations system is judged by a different standard than a chatbot. With a chatbot, a mediocre answer is annoying; you simply ask again. With an operations system, a mediocre action is an incident. The value is not in the average, but in the tail: what happens in the one percent of cases where the model gets it wrong?
On top of that, an autonomous agent amplifies its own mistakes. If it restarts a service based on a false signal, the state of the system changes. The next observation is therefore contaminated by its own intervention. What starts as a single misinterpretation ends as a chain of actions that justify one another. That is not a model problem, it is an architecture problem.
Reliability in agent systems does not come from a smarter model, but from a stricter separation between thinking and doing.
The separation: four layers, four roles
The setup we run is built on four separate layers, each with exactly one responsibility and exactly one set of permissions.
Observing. Monitors collect signals: container status, error messages, system load, events from the infrastructure. This layer has no opinion and no authority. It records.
Reasoning. The AI brain reads those signals, connects them and formulates a proposal. The crucial point: this brain may only propose. It cannot mutate anything itself. No access to executing commands, no workaround, no exception for emergencies. What the brain produces is text — a reasoned proposal, nothing more.
Acting. One separate, small component is actually allowed to mutate. That component is deliberately dumb: it does not reason, it executes what has been approved, and only within its own guardrails. Because this layer contains no language model, its behavior can be read entirely from code instead of from a prompt.
Remembering. Everything that happens ends up in a single append-only log — a log from which nothing is deleted or rewritten. Signal, reasoning, proposal, approval, execution and refusal all get the same correlation ID. That lets you read an incident back as one story, instead of as loose lines across five systems.
The guardrails that have to be there at a minimum
In our setup the executing layer sits behind a chain of checks. Every link can still stop the action. This list is deliberately concrete, so you can adopt it as is:
1. Whitelist. Only explicitly permitted actions are possible. Anything not on the list does not exist for the agent. This is a deny-by-default model, not a filter after the fact.
2. Deny-list. On top of the whitelist sits a second list of actions that are never allowed under any circumstance, not even if they technically fall within a permitted category. Two lists instead of one, because the most dangerous mistake is always the edge case.
3. Load guardrail. When system load is too high, every mutation is refused. This is the most important and most counter-intuitive rule: precisely at the moment the system is under the heaviest load — and therefore raising the most alarms — nothing may be changed. Heavy load is often legitimate, and an intervention only makes it worse.
4. Maintenance mode. A switch that freezes all mutations because heavy or manual work is deliberately under way. Without it, your automation fights your own maintenance.
5. Cooldown. After an action, a waiting period applies before a comparable action is allowed again. This is the brake on restart loops: the system gets time to show whether the intervention worked.
6. Backup before every action. The state is captured before anything changes. Not because we expect to have to roll back, but because the cost of a backup is negligible and the cost of data loss is not.
On top of all that sits the human link. Every proposal from the brain becomes an approval card on a dashboard. Only after a human signs off does the executing layer carry it out. That card is not a formality: it forces the reasoning to be readable before anything happens. A proposal you cannot assess in a single screen is a proposal you should not have approved.
Real-world example 1: the timeout under heavy load
A health check ran into a timeout while the system was under heavy — but entirely legitimate — load. Nothing was broken. There was simply a lot of work going on.
A naive automation does something predictable in that case: the check fails, so restart the container. Still failing, so try again. And again. After three failed attempts the system escalates to an AI diagnosis, which then goes looking for a cause that is not there — at exactly the moment the system has the least room for extra work. You end up with three unnecessary restarts, a disrupted workload and a diagnostic round on a fictional problem.
In our setup something else happens. The load guardrail refuses the restart, because load is above the threshold. The escalation to AI diagnosis is suppressed, because there is no executed action to follow up on. What remains is one line in the log, with the full reasoning attached: this signal came in, this was the thought, this was the proposal, and this is the reason it was not executed. No incident, but a trail.
Real-world example 2: the monitor that looked too broadly
The second example is less spectacular and instructive for exactly that reason. A monitor checked whether containers were running by matching on container name — but not exactly. The result: false-positive alerts that a container was offline, while it was running perfectly well under a name that was just slightly different from what the monitor expected.
The fix was banal: use exact names instead of partial matches. But the point is what would have happened if the agent had been allowed to act on its own. A sloppy string comparison would have led to restarts of healthy services. Not because the model reasoned badly, but because the input was wrong. An agent is never more reliable than its observation layer, and a human approval step is the only place where that kind of nonsense still gets caught before it does damage.
These two cases are not exceptions we patched up after the fact. They are the reason the architecture is the way it is. If you want to see this setup running in practice, take a look at the Sentinel showcase.
Conclusion: the value is in the refusal
An AI operator earns its place not through what it solves, but through what it refuses to do. Every restart refused under heavy load, every action that falls outside the whitelist, every escalation suppressed because nothing happened — those are the moments where the architecture does its job.
That does not mean such a system is flawless. Guardrails can be tuned wrong, thresholds can be set too loose or too strict, and an approval card is only useful if someone looks at it critically. But the difference between an agent that advises and an agent that acts is the difference between a mistake you read and a mistake you have to repair.
Anyone considering an AI operator would do well to turn the question around. Not: which actions is the agent allowed to perform? But: which actions can it demonstrably not perform, even if it very much wants to? The answer to that question determines whether you have an operations system or a risk. More on how we build systems like this can be found under our services.