Key Takeaways

  • Dependability trumps 'wow' factor: Alex Finn chose Hermes over Open Claw not for superior features, but because Open Claw frequently broke, demanding “half an hour fixing it” weekly.
  • Agents are inherently unstable: Finn estimates that out of his five core agents (three Hermes, two OpenClaws), “three are always down for one reason or other” at any given time.
  • Redundancy is non-negotiable: To counter constant failures, Finn runs a diverse fleet of redundant agents, including Opus, ChatGPT, and local models across both Open Claw and Hermes harnesses.
  • Design for self-healing: His strategy includes a "lifeguard" agent, leveraging the fact that even if multiple agents are down, he always has "two that can go and fix the others."

The Method: Building a Self-Healing AI Agent Fleet

Alex Finn isn't just running AI agents; he's running a full-blown agent fleet, built with the hard-won wisdom that every piece of software eventually breaks. For ambitious builders, his approach to agent management comes down to two principles: prioritize stability and prepare for failure.

First, choose dependability over flashy features. Finn openly admits, “if both were like 100% dependable, never broke... I'd probably be using Openclaw because I think I've had the most wow, impressive, big bang moments with Openclaw.” But raw capability means nothing if it’s constantly down. Open Claw's frequent breakage – a “run for like a month straight where every update I did broke it” – drove him to Hermes. It lacks the same "wow" factor, but Finn notes, "Hermes, I've never had that issue. It seems to be a much more dependable application."

Second, architect for ubiquitous failure. Finn's key insight: AI agents will break. Not sometimes, but constantly. To combat this, he builds extensive failover into his operations. His setup is intricate: “I have so much failover. So, I have uh I think three Hermes agents I'm running, uh an Opus one, a ChatGPT one, and on one on a local model, and then two Openclaws, an Opus and a ChatGPT one.” This isn't just for backup; it's because these systems are fundamentally unstable. He estimates that “at any point of those five agents, like three are always down for one reason or other.”

The final layer of this method is proactive self-repair. Instead of manually intervening every time an agent goes offline, Finn designs his system for resilience. His "lifeguard" agent concept means that his operational agents aren't just redundant; they're mutually supportive. "The good news is," he explains, “I have two that can go and fix the others.” This creates an autonomous software factory where downtime is minimized not by perfect code, but by intelligent system design.

Where This Breaks Down

While Finn's approach champions resilience, it's not a silver bullet. The initial overhead of setting up such a diverse, multi-agent fleet can be substantial. For a small team or a solo founder, the time and expertise required to configure, integrate, and monitor several distinct agent harnesses and models might outweigh the benefits, at least initially. Debugging agent-to-agent interactions, especially when agents are tasked with fixing other agents, can introduce new layers of complexity. Furthermore, the cost of running multiple API-based models (like Opus or ChatGPT) concurrently, or maintaining the hardware for local models, quickly adds up. This method best suits critical, continuous tasks where agent uptime directly impacts revenue or core operations, rather than experimental side projects.

What to Do With This

Stop thinking of AI agents as single tools; start building them into a resilient system. For your most critical, automatable task (e.g., code security review, market research, autonomous dev work), deploy at least two distinct agents tomorrow. Run one on a more stable harness like Hermes with a robust model (e.g., a commercial API), and a second as a failover, perhaps a local model or another API. Then, implement a simple monitor to alert you if the primary agent goes offline, ensuring you can quickly switch to the backup. This isn't about perfect agents; it's about reliable output.