An Ops Agent for an Audience of One

I run a handful of machines, some at home, some rented in the cloud, and for a long time the only thing standing between something breaking and me finding out about it was whichever alerting rule happened to fire. The alert would land, I’d open a terminal, check logs, remember what that particular service actually does, and decide whether it mattered. Do that often enough and most evenings turn into a small triage exercise before you get to do anything else.

The obvious objection is that I’m the only user of this infrastructure. Nobody else gets paged. There’s no on-call rotation, no service-level agreement, no team to hand context to. So why bother building an agent for an audience of one? Because the fatigue is real regardless of audience size. An alert doesn’t know it’s only ever going to be read by the person who wrote the rule that fired it. It still needs someone to remember the system, check whether the number is actually bad, and make a call. I wanted something to handle that part for me, or at least the diagnosis half of it.

I called the result Magatama. The first version was deliberately narrow: diagnosis brain only, no autonomous execution power. It could tell me what was wrong. It could not touch anything. That was a conscious choice going in, not a limit I ran into later and worked around. I didn’t trust myself to get the guardrails right on the first attempt, so I built the version where getting them wrong couldn’t actually cost me anything.

Mechanically it’s fairly simple. When the alerting system fires, a small diagnosis service takes the alert’s name, its severity, which machine it’s on, and whatever summary or description came attached to it, and turns that into a prompt. That prompt goes to a small language model running on hardware I own at home, not a hosted API somewhere. The model reads the alert roughly the way I would and writes back a plain-English guess at what’s going on, which gets pushed to me as a notification. Most days that alone saves me the step of opening a terminal just to remember what a given service is for.

One detail I’m fond of: before the service asks the model anything, it checks whether that same hardware happens to be busy training another model at the time. If it is, the diagnosis still goes ahead, but the notification gets a line added telling me the answer might be slower because the GPU is occupied. It’s a small thing. It only exists because the whole system is built around one real box with finite capacity, not an abstract API that never admits to being busy.

Diagnosis-only held up fine for a while, and I genuinely assumed I’d leave it there. Then I noticed a pattern in my own behavior: I’d read the diagnosis, agree with it, and go do the identical remediation by hand, again. At that point the no-execution rule stopped feeling like caution and started feeling like a chore I kept volunteering for on purpose.

So I reconsidered the scope, and two options were on the table. One was full autonomy: let the agent diagnose and act on anything it judged safe, with no human anywhere in the loop. The other was a whitelist: pre-approve a set of actions and let it execute the moment something matched, again without asking anyone. I turned down both. Full autonomy means trusting a diagnosis I haven’t even seen yet with actions I can’t take back. A blind whitelist doesn’t get rid of that risk. It just moves it earlier, to the day I wrote the list, when I was reasoning about categories of problems instead of the specific one in front of me.

What I landed on sits between the two. The agent still diagnoses first. If it also has a fix in mind, it proposes that fix along with a specific, named playbook for carrying it out: an actual documented procedure, not a vague suggestion to restart something and hope. Then it waits, either for me directly or for a narrow, pre-approved rule that covers genuinely low-risk cases, the kind where being wrong just means a service restarts a few seconds sooner than it needed to. Only after that does anything execute, and every step gets logged so I can go back and check its reasoning later, when I have the time to read it.

I think of the six pillars of the platform’s autonomy work as separate strands of an ongoing project rather than a finished checklist I get to close out. And I want to be honest that the question of how much it should be allowed to decide on its own doesn’t have a permanent answer for me. A clean run of correct diagnoses makes me want to loosen the rule for that category. One confidently wrong guess makes me tighten it back. I’ve caught myself extending trust based on a streak that had nothing to do with the actual risk of the next action, which is exactly the kind of reasoning that gets people in trouble with systems far more consequential than a home server fleet.

There’s a version of this post that ends with a tidy rule for where the line should sit permanently. I don’t have one. What I have is a system that tells me what’s wrong, sometimes proposes how to fix it, and only acts once I, or a rule I wrote in a calmer moment, says it’s fine. I keep watching to see whether that rule still deserves the trust I gave it.