For a long time, I thought of Klaus as something I talked to. A very good chat interface, one that remembered things, closed GitHub issues, and helped me plan my week.
That’s not wrong. But it’s incomplete in a way that took two months to become obvious.
Last week I asked Klaus to build an update checker. The task felt small: write a script that checks each morning whether Monica, N8N, and Ollama have new versions available. Monica is my AI frontend. N8N handles workflow automation. Ollama serves the local models. All three run on the same EC2 instance, updating on their own schedule, without asking.
The script came out at 178 lines. I set it to run at 8:05 AM PT, not 8:00. Same instinct I have for production jobs at work: stagger the start times so you’re not hitting the same resources all at once. I ran a live test. It worked.
Then I sat back and looked at what I’d just done. I had asked my AI to build a monitoring tool for my other AI services. I had written a cron schedule the same way I’d write one for any production health check at work. I was thinking about alert thresholds.
This is not how you use a chatbot. This is how you operate a service.
The first signal came earlier, back in March. The EC2 instance hit its memory ceiling at 3 AM, OOM killer fired, and Klaus went down. I found out when I woke up. Fixed it with a 2GB swapfile and a resize from t3.small to t3.medium. Standard ops.
But after that I started watching the system differently. Disk at 83%: 12GB out of 14GB, five-minute sync cycles adding up faster than I’d designed for. rotate-logs.sh in the cron queue. sleep-inhibitor.sh with an unbound variable. sync-kanban.sh with a UTF-8 encoding bug. Quiet failures, all of them. Caught and fixed the same way you fix any production code, which is to say: after the fact.
You don’t deal with any of that with a chatbot. You deal with all of it when you’re running a system.
Somewhere in month two I stopped asking “what can Klaus do for me today” and started asking “what does Klaus need to stay healthy.” That’s a sysadmin question, not a user question. Nobody puts it in the brochure.
It’s worth it. The system does more because it’s always on. It can run an update check at 8:05 AM whether or not I’m thinking about Ollama. It closed 42 GitHub issues while I was on a cruise in February. The autonomy is the value. The maintenance is what you pay for the autonomy.
If you’re building your own AI setup, know going in that you’re signing up to be the operator, not just the user. Schedule the health checks. Watch the disk. When something breaks quietly at 3 AM and you find out at 8, don’t be surprised. That’s not a bug in the system. That’s the system.