Magatama, From the Beginning (Part 1): Diagnosis Only

Part one of a short series retracing how Magatama went from nothing to what it runs today starts here, with the very first version, the one that could only talk.

Before I built anything, triaging alerts from my own server fleet meant the same small ritual every time, no matter what the alert said. Something would fire, I'd get pinged, and then I'd open a terminal, ssh into whatever machine was complaining, pull up the logs, and try to remember what that particular service was even for. Sometimes that took thirty seconds. Sometimes I'd stare at a log line for a while before remembering I'd set that service up months earlier for a reason that no longer applied to anything I was currently running. None of it was hard, exactly. It was just slow, and it had a way of pulling me out of whatever else I was doing at the moment an alert happened to land.

At some point I got tired of being the alert parser myself and decided to offload that one specific step: reading an alert and explaining, in plain language, what it meant and whether it was worth caring about. I already run a small language model on my own hardware at home, mostly for smaller projects like this one, and it seemed like a reasonable fit. I didn't have a grand plan for an autonomous system sitting behind it. I'd just noticed that explaining a log line in plain English was a narrow, well-bounded task, small enough that a local model could probably handle it without much fuss.

That narrowness stayed deliberate for longer than I expected it to. The first version of what became Magatama had exactly one job: diagnosis. It could read an alert and tell me, in a sentence or two, what was going on and why it might matter. It could not restart a service or touch a config file, and it had no way to act on the machines it was watching at all. Talking was the whole feature set, and I kept it that way on purpose. I didn't build it that narrow because I hit a wall trying to give it more power early on. I built it narrow because I didn't trust myself to get the guardrails right on a first attempt, and a system that can only explain things can't do much damage if I got that wrong.

Mechanically it was almost embarrassingly simple, at least compared to what came later. When the alerting system on the fleet fired, a small diagnosis service picked up the event, pulled out the alert's name, its severity, which machine it was running on, and whatever summary text came with it, and stitched those into a prompt. That prompt went to the local model. Whatever came back, a plain-English guess at what was wrong and why it might matter, got pushed to me as a notification.

No remediation, no ticketing, just a plain-English read on the situation. Even at that small scope, it saved me something real: the step of opening a terminal just to remember what a given service was for in the first place. A surprising share of the value never had anything to do with how clever the diagnosis was. Most of it came from skipping the context switch into a shell for something a single sentence could already answer, which turned out to matter more than I expected on a day with more than one alert going off.

I named the whole project Magatama. Back then it was one small service watching one alert stream, with no ambition beyond doing that single thing reliably. Looking back now, after everything it has become, what stands out isn't the model or the prompt structure, it's the decision to keep it powerless on purpose, before it had earned any right to more. Every autonomous piece that came later had to earn its way past that first, deliberately narrow gate.

Part two picks up from there, at the point where diagnosis alone stopped being enough.