Michael Kroes

Running agents against my own infrastructure

Most of what I know about agentic AI I learned by pointing it at my own infrastructure, where the blast radius is mine to deal with. It runs as one git-tracked repository covering a Proxmox host, thirty-odd Docker Compose stacks, Home Assistant and UniFi networking, with a single deploy path and a commit before and after every change, so anything is one command from being reverted. Claude Code works in that repo under rules I'd want in production anyway: irreversible or shared-state actions like firewall rules and DNS need an explicit human confirmation, and read-only investigation runs through permission-scoped subagents that structurally cannot write.

On top of that sit around forty monitoring checks rolled up into a single health signal. When that signal flips from healthy to broken, an autonomous session starts on its own and attempts the repair. The interesting engineering there isn't getting an agent to fix something. It's deciding when it is allowed to try. So the launch sits behind explicit quality gates: a written authorization scoped to container-level recovery only, a problem-class filter that refuses to act on anything touching firewalls, DNS, disks or data, a concurrency check, a rate limit of three attempts per twenty-four hours, and a global kill switch. Out of scope, it is required to investigate and report rather than improvise, and it leaves its session open and remote-controllable so I can take over from my phone.

Two rules keep that honest. Alerting is deliberately independent of the fixer, so a disabled or crashed agent can never quietly suppress a page: the worst case is being told about a problem nobody tried to fix, never a problem going unreported. And no severity tier is allowed to become a silencing mechanism. Downgrading something from blocking to minor changes what the overall status means, not whether it still notifies.

The same approach carries into side projects: a daily-refresh content pipeline for a local events aggregator runs as a scraper → verifier → QA-reviewer agent chain rather than a single unsupervised job, and a shipped bilingual mobile app uses a cost-tuned visual-QA subagent for UI regression checks. I've also introduced Claude Code tooling into an existing open-source medical-device codebase (Trio, an automated insulin-delivery system) without disrupting its established contributor workflow.

The thing I keep relearning: an agent is useful in proportion to how well you've bounded what it can break. That turns out to be a management problem more than a technical one, which is probably why I find it interesting.