Magatama, From the Beginning — Part 3: What the Execution Gate Couldn't See

Part 2 left Magatama running under a gate: propose a fix, name the playbook it wants to run, wait for a yes, then execute and log the result. This part covers a stretch of days when that gate held up exactly as designed, and still turned out not to be the whole answer.

I've already written the full story of what happened elsewhere on this blog, so I'll keep the summary short here. I found a duplicate training process running outside the pipeline I thought was the only one, and separately discovered that a fresh batch of weights for Magatama's own diagnosis model had come back completely corrupted, every value non-numeric, the result of a training run gone wrong in a way I hadn't seen before. It came close to reaching production before I caught it.

What stayed with me afterward wasn't the corruption itself. It was what the corruption exposed about where I'd drawn the line on safety. The execution gate from Part 2 was built to stop a bad decision from reaching a real server: wrong command, wrong target, wrong timing. It does that job well. But a gate only inspects what crosses it. It has no way to ask who, or what, generated the proposal in the first place. If the model behind a diagnosis is broken, the gate will still faithfully ask for approval to act on its output, in the same calm format it uses for a correct fix. Nothing in propose, confirm, execute, log checks whether the thing doing the proposing is sound.

I hadn't been thinking about that at all. I'd put real effort into controlling what Magatama was allowed to do with its conclusions and none into whether those conclusions came from a working model to begin with. Those turned out to be two separate problems, and I'd only been solving one.

So the fix wasn't another rule bolted onto the execution gate. It meant moving a checkpoint earlier, into the pipeline that trains and ships the model Magatama runs on. New weights don't get promoted just because a training job exits without an error anymore. They get a basic sanity pass first, checking that the values look like a model rather than a wall of garbage, before they're anywhere near a position to produce a diagnosis Magatama could act on. It's a smaller, less interesting gate than the one in Part 2, and it sits further upstream, but it closes a hole the first gate was never built to see.

Those were the more stressful days of this whole project so far, more than any single technical fix in the series. I don't think that was really about the corrupted weights on their own; a bad training run is a known, recoverable thing. It was realizing I had a category of risk I hadn't modeled at all, sitting quietly upstream of a safeguard I'd been fairly pleased with. Gating what an agent does is necessary. It isn't sufficient if nobody has checked whether the reasoning behind the gate can be trusted.

Part 4 turns that question outward and points it at the agent itself: a proper audit of what Magatama had access to, what it could see across the fleet, and what a serious look at its own attack surface would turn up.