In my home lab, Home Assistant doesn’t directly control Zigbee radios. The Zigbee coordinator doesn’t store historical state. The inventory system doesn’t speak to Sonos. The photo pipeline doesn’t publish directly to WordPress.

Everything has boundaries. Everything has a role. Everything hands off responsibility to another layer.

The result is a system where individual components can fail without taking the whole house down with them.

Then I started looking at AI agent frameworks. And suddenly I was seeing the opposite philosophy everywhere.

A huge prompt gets handed to a model. The model decides what to research. The model decides when it’s done researching. The model decides what files to create. The model decides what to edit. The model decides when it’s finished.

The model is effectively expected to be the application, the workflow engine, the state manager, and the project manager all at once.

As somebody who spends his free time separating services across servers, that immediately felt wrong.

To be fair, the approach works remarkably well when you’re using frontier models. The big models are smart enough to compensate for architectural shortcuts.

Give them a wall of instructions and they’ll often figure out the workflow on their own. They know when to stop researching. They know when to start building. They know when they’re stuck.

Most agent frameworks quietly depend on those abilities.

But my interests tend toward local infrastructure. Which means my attention eventually turned toward local inference. And that’s where things got interesting.

Running local models reminded me of working with highly capable services that only do one thing.

A 30B-class model can write code. It can analyze specifications. It can reason surprisingly well. But it doesn’t always possess the same instinct for workflow management that larger frontier models exhibit.

A frontier model might naturally decide: “I’ve gathered enough information. Time to start implementing.”

A local model often decides: “Research is important. Therefore I shall continue researching until the heat death of the universe.”

The problem wasn’t intelligence. The problem was orchestration. And suddenly I found myself facing a challenge that felt remarkably similar to building the rest of LAWNET.

The breakthrough came when I stopped asking how to make local models behave like frontier models. Instead I asked: what if the harness owns the workflow?

What if the model only owns the task?

In a healthy infrastructure stack, services don’t wake up and decide what role they perform today. The architecture decides that. Pi-hole doesn’t randomly become a media server. Home Assistant doesn’t decide it wants to become a DNS resolver. The workflow already exists before the service starts.

So why not apply the same thinking to AI? Instead of asking the model to determine the next step, make the workflow deterministic. Instead of asking the model when to transition phases, make transitions explicit. Instead of storing project state inside prompts, store state inside the system.

The model becomes a component. Not the entire architecture.

Looking back, I don’t think I was trying to build an AI agent. I think I was accidentally building another infrastructure layer.

The same patterns that show up everywhere else in my environment started appearing again.

A control plane. Defined interfaces. Observable state. Execution logs. Deterministic transitions. Bounded responsibilities.

The result looked less like an autonomous AI and more like a distributed system that happened to contain AI components. Which is honestly how most successful systems end up looking anyway.

Once the workflow became deterministic, another question emerged.

Could the agent improve the harness that runs the agent?

Not in a science-fiction sense. In an engineering sense.

Could it participate in designing the next version? Could it implement approved changes? Could it verify those changes? Could it gradually improve the system that orchestrates it?

That question eventually became SPINE. An experiment in running Spec Driven Development on local models. A coding agent designed specifically around the strengths and limitations of 30B-class inference. A system intentionally built so it could participate in developing future versions of itself.

The surprising part wasn’t that the AI could write code. Everybody already knows AI can write code.

The surprising part was discovering how much reliability comes from structure.

Every successful improvement made the system more constrained. Not less. Every successful improvement reduced ambiguity. Not increased it. Every successful improvement made future improvements easier. Not harder.

The bottleneck wasn’t model capability. It was architectural clarity.

The AI industry spends enormous energy arguing about model intelligence.

I’m increasingly convinced that’s not where the interesting problems are.

The more interesting question is whether we can build systems that remain understandable as they evolve. Can improvements compound safely? Can workflows remain deterministic? Can execution remain observable? Can future versions understand why previous versions made certain decisions?

Those feel like infrastructure questions. Not AI questions. And infrastructure questions are often the harder ones.

SPINE exists because I wanted to find out where that boundary actually is. Not by theorizing. By building.

The repository is simultaneously the tool, the test, and the evidence. Every improvement leaves a trace. Every failure leaves a lesson. Every iteration becomes part of the argument.

And maybe that’s the most interesting thing I’ve discovered so far.

I started by exploring AI-assisted development. I ended up applying home lab engineering principles to agent design. Which, in hindsight, is probably the most predictable outcome imaginable.

When all you have is infrastructure, eventually every problem starts looking like a control plane.