An AI junior sysadmin: what deploying an autonomous infrastructure agent actually involves

A UK business came to Evoloop with a specific idea. They wanted an agent running inside their own environment, acting as a junior systems administrator. Something that watches the infrastructure around the clock, notices when a service starts misbehaving, investigates the cause, and quietly fixes the small stuff before anyone has to get out of bed. The rule they set was clear from the first conversation: the agent handles the routine, and anything that could genuinely break something goes to a person first. This is the story of what that build actually involves, and what an agent like this can and cannot safely do.

The brief: a junior, not a replacement

The framing of "junior systems administrator" did a lot of useful work. A good junior is trusted to restart a stuck service, clear a full disk of old logs, or acknowledge an alert and write up what they found. They are not trusted, on day one, to resize a production database, change firewall rules, or push a configuration that touches every machine at once. The value is real, but it lives inside a boundary. That is exactly the shape you want for an agent with access to live infrastructure.

The agent was built on the OpenClaw agent framework and deployed in the client's own environment, so the data and the decision-making stay where they belong. It reads monitoring signals from Zabbix, which the business already used to keep an eye on their servers and services. And it draws on a vector database as its knowledge store: runbooks, notes from past incidents, and documentation about how the environment is put together. The framework is the engine. Zabbix is the senses. The vector database is the memory.

How the monitoring-to-agent pipeline works

The flow is easier to trust once you can see each step. Nothing here is magic, and that is the point.

• A Zabbix alert fires. A disk crosses a threshold, a service stops responding, a queue backs up. This is the trigger, the same signal a human on-call would get.
• The agent reads context from the vector database. Before touching anything, it pulls the relevant runbook, checks whether this exact symptom has appeared before, and reads the environment notes for the affected system. It starts the way a careful junior would: by finding out what it is looking at.
• The agent investigates. It gathers the current state, correlates the alert with what else is happening, and forms a view of the likely cause rather than reacting to the surface symptom.
• It either fixes within its permitted scope, or it stops. If the problem sits inside the list of things it is allowed to do, it acts and records what it did. If it does not, the agent writes up its findings, states what it believes is wrong, suggests a next step, and escalates to a human.

Every action, and every decision not to act, gets logged. When a person picks up an escalation, they are not starting cold. They are reading a briefing that a junior already prepared, with the context already gathered.

What it can safely do, and what it must never touch

The safe list and the forbidden list are the real design work. Defining them well is most of what makes an agent like this trustworthy. The routine, reversible, low-blast-radius tasks belong to the agent. The consequential and hard-to-undo ones belong to a human, always.

Comfortably within scope

• Restarting a service that has hung, following a known runbook.
• Clearing predictable disk pressure, such as rotating or removing old log files.
• Re-running a failed scheduled job that is safe to retry.
• Acknowledging an alert and gathering diagnostics so a person has a head start.

Always escalated to a human

• Any change to networking, firewall rules, or access control.
• Anything that affects data: deleting it, migrating it, or altering a database structure.
• Changes that touch many systems at once rather than a single isolated fault.
• Anything the runbooks do not cover, or any situation the agent is not confident it understands.

Why the approval gate matters more than the automation

It is tempting to measure a project like this by how much the agent can do on its own. That is the wrong measure. An agent will occasionally be confidently wrong, and infrastructure is unforgiving: some actions cannot be undone, and a bad change applied everywhere at once is far worse than the original fault. The approval gate contains that risk. It lets the agent take real work off a person's plate for the routine cases, while guaranteeing that the decisions with lasting consequences still pass through human judgement.

There is a quieter benefit too. Because the agent escalates with a written investigation rather than a bare alert, the humans spend their attention on judgement rather than triage. The tedious first hour of an incident, working out what is even going on, is already done by the time it reaches them.

Choosing where the model runs

The agent can run on a local LLM hosted inside the business, for full control over data, or on a large cloud provider model. Neither is automatically right. The decision comes down to four honest questions.

• Data sensitivity. An infrastructure agent reads logs, configuration, and system state, which can be revealing. If your obligations or your comfort level mean that information must never leave your walls, a local model settles the question before cost or capability enters into it. Regulated firms often land here.
• Cost. A cloud model is paid per use and needs no hardware. A local model means running and maintaining the machine that hosts it. The economics shift with how busy the agent is and what kit you already own.
• Latency. A local model on the same network answers without a round trip to an external service. For an agent reacting to alerts, quick and predictable response can matter more than raw capability.
• Capability. The largest cloud models are strong at open-ended reasoning about unfamiliar problems. If most of your incidents are well documented in runbooks, a capable local model may be more than enough. If you expect genuinely novel situations, more capability earns its place.

In practice this is rarely a permanent one-way door. A sensible design keeps the choice of model separate from the rest of the system, so a business can start on one footing and move later as its needs, budget, or comfort change.

Where a build like this should start

The hardest part of this work is not the code. It is deciding precisely what the agent may touch, what it must escalate, which runbooks it needs to know, and whether the model should live inside your walls or in the cloud. Get those boundaries right and the agent is a genuinely useful junior. Get them wrong and you have handed a confident newcomer the keys to production. That is why Evoloop scopes builds like this through a Scoping Sprint, so the decisions that matter are made deliberately, before anything is deployed.