Two weeks ago, I deleted n8n from my server. I felt a clean, almost spiritual satisfaction. No Docker containers. No Python virtual environments. No YAML files that somehow break between 2 AM and 3 AM. Just my Mac’s built-in job scheduler, launchd, running 10 AI agents with zero external dependencies. It was beautiful. It was terrifying.
You’ve probably felt the same creeping complexity. Every new AI agent framework promises to be the last one you’ll ever need. Then you’re maintaining three different orchestration tools, each with its own networking quirks, and your agents are spending more time talking to each other than doing actual work. The minimalist in you screams: there has to be a simpler way.
There is. And it’s been sitting in your operating system the whole time.
But here’s the thing nobody tells you about going pure OS-level: Keeping an agent alive at the process level is fundamentally different from keeping it useful at the application level. launchd’s KeepAlive flag will restart a crashed agent within milliseconds. It won’t know if that agent is now rambling about conspiracy theories, emitting hallucinated JSON, or stuck in a loop asking itself the same question.
Let me show you what I mean.
Day one, everything hummed. My agents processed customer support tickets, generated marketing copy, and updated a product database — all through launchd’s rock-solid process management. I felt like a god of minimalism. Then one agent, after 14 hours of continuous uptime, started producing output that looked like a Markov chain trained on a manifesto. launchd dutifully kept it running. It was auto-restarting a broken agent, over and over, as if that would fix anything.
That’s the moment the satisfaction turned to anxiety.
Auto-restarting a hallucinating agent just institutionalizes the failure. You’re not solving the problem. You’re building a factory that produces the same broken output, faster.
So what do you do? You need a watchdog. Not a process watchdog — that’s launchd’s job. You need an application-level health check. Each of my agents now exposes a simple HTTP endpoint that returns a JSON object with a status field and a sanity_score (a number from 0 to 1, computed from recent output coherence). A separate monitoring script, also running under launchd, pings those endpoints every 60 seconds. If an agent’s sanity score drops below 0.3, the script kills it and marks it for human review.
Is this more work? Yes. But it’s my work, not the work of debugging someone else’s orchestration layer. The dependencies are zero. The complexity is bounded. I know exactly what each piece does.
One of the top comments on my original post asked: “Without a watchdog that monitors agent output for hallucinations, you might be auto-restarting agents into degraded states.” They were right. The beauty of this approach is that it forces you to confront the real problem: AI agents don’t fail like normal processes. They don’t crash. They just get dumber, slowly, until you notice.
So here’s my challenge to you: if you’re running AI agents, try stripping away the orchestration frameworks for a week. Use launchd, systemd, or whatever your OS gives you. It’ll feel liberating. Then build the one thing you actually need: a health check that measures output quality, not just uptime. You’ll end up with a system that’s both simpler and more honest about what your agents are doing.
And if you think that’s too much work? Remember: the safest system is one you understand completely.
FAQ
Q: Why not just use n8n or a similar orchestration tool?
A: You can, and for many teams n8n is the right choice. But if you value minimalism, zero external dependencies, and complete control over your infrastructure, native OS process managers like launchd are more reliable and simpler to audit. The trade-off is that you lose built-in observability and have to build your own application-level health checks.
Q: What's the practical implication of this approach for a developer?
A: You'll spend less time debugging orchestration layers and more time writing code that actually monitors your agents' output quality. The burden shifts from infrastructure management to building custom health endpoints that check for state drift, hallucinations, and degraded performance. It's a net win if you're comfortable with that trade-off.
Q: Isn't this just a contrarian take? What about the complexity of building your own watchdog?
A: It's contrarian because it challenges the default assumption that you need a heavy orchestration framework for AI agents. The complexity of a custom watchdog is far smaller than the complexity of maintaining n8n, Docker, and all the associated networking. Plus, you own the entire stack — no surprises when a third-party tool updates and breaks your flows.