My homelab grew past the point where I could babysit it. More nodes, more Grafana panels, more alerts firing at hours when I would rather be asleep. At the same time, every customer conversation I sit in at work circles back to the same thing: who watches the cluster at 3am, and can any of that be handled by something other than a tired human on call. AIOps is a real and growing need, in the market and on my own rack. So I decided to meet it.
The interesting question for me was never "can I write an AI agent from scratch." Plenty of people can, and that is a craft I respect. My lane is different. I am a system integrator. My job, day to day, is taking capable parts that already exist and making them work together safely inside a real environment, then keeping them running. So I approached this the way I approach any integration: pick a proven component, wrap it in governance, and make it accountable.
The component I adopted
The agent harness I chose is Anthropic's Claude Code. It is already very good at the thing I needed: reasoning over a system, running commands, reading state, explaining what it found. I did not want to reinvent that. I wanted to put it to work.
Think of it like buying a managed switch instead of soldering your own. The switch is capable out of the box. Your value as the integrator is the config: the VLANs, the ACLs, the monitoring, the change process around it. That config is what makes a capable box safe to put in production. Same idea here. Claude Code is the capable box. Everything I built around it is the config that makes it trustworthy in a live cluster.
So I did not build an AI engineer. I hired one and gave it rules.
Meet Long John
The persona I wrapped around the harness is a senior DevOps engineer I named Long John. One persistent identity, not a fresh chatbot every session. He has full cluster-admin on my homelab, deliberately, and I will get into why that fit my situation in a later part. For now the short version: you would not give a competent human engineer a read-only account and expect good work. You give access, then you pair it with judgment and a recoverable path.
Long John stands on two pillars.
Pillar one: the platform
daimon-platform is the integration layer. It is a small Rust service (eight crates) that shells out to claude -p and adds the things an adopted agent needs before I trust it near production:
- an append-only audit hash-chain, so every action is logged and verifiable after the fact
- a kill-switch, because any system with real access needs a hard stop
- a governance gate that enforces notify-first behaviour
- a Telegram channel so Long John talks to me where I already am
- an HTTP /alert webhook so monitoring can hand him work
None of that is the intelligence. The intelligence is the adopted harness. The platform is the accountability and the safety rails around it. That is the integrator's part, and it is the part I actually take pride in.
One odd detail worth flagging early: this runs inside a real VM (KubeVirt), not a container. The Claude Code subscription login uses OAuth, and that auth does not survive systemd or a container the way you would hope. It needs a host-like environment. That war story, and the disk-clone adventure that came with it, is a whole post on its own.
Pillar two: the memory
The second pillar is daimon-memory, and I treat it as a system layer rather than a bolt-on feature. An engineer without history is just a clever stranger every morning. Long John needs to remember.
Memory holds three things: his persona (who he is), the governance protocols (how he is allowed to work), and a hybrid RAG recall built on Postgres full-text search fused with Qdrant vectors. At the start of every session it injects persona and protocols. Every turn, it auto-recalls relevant past decisions and incidents. Writes are nudge-driven and curated, so he saves distilled records (decisions, incidents, lessons, runbooks) rather than dumping raw transcripts.
That is the difference between an engineer with history and a stateless assistant. One of them learns from the last outage. The other meets it fresh every time.
One way, not the way
I want to be clear about something. This is one integrator's take on a real need, shaped by my constraints: a homelab budget, a trusted single operator, and a preference for composing proven parts over building my own. Someone with a developer's background, or a stricter risk profile, might draw every line differently, and they would be right for their situation. There is no single correct shape for this.
What I have is a hired engineer named Long John, a platform that keeps him accountable, and a memory that gives him a past. In Part 2 I will get into the memory layer in earnest: why I built the brain before the body, and how a long-running operator earns something close to scar tissue.