The EC2 Klaus incident from earlier this year had a shape I recognized. Two vCPUs, Ollama and the gateway fighting for the same headroom, response times climbing. A known problem with a known shape.
So when HP Klaus started acting sluggish one day in May, I opened the debugging session with what felt like useful context. “I’m having similar issues with HP Klaus as we were having with EC2 Klaus.” We’d already mapped that territory. No reason to start from scratch.
The investigation went where the framing pointed. SSH through Tailscale, hop through the EC2 box to reach the HP machine, resource metrics pulled, process priorities checked. About ten minutes of the right diagnosis for the wrong problem.
Then I pasted the actual error.
openclaw gateway start was returning MODULE_NOT_FOUND for openclaw.mjs. The gateway couldn’t find its own entry point. Corrupted npm package. Nothing to do with CPU, nothing to do with Ollama. Completely orthogonal to the EC2 incident, except that both problems had the word “Klaus” in them and both made things slow.
Here’s what I keep thinking about. The analogy wasn’t wrong, exactly. HP Klaus and EC2 Klaus run similar stacks. The EC2 incident was recent. Pattern-matching to known shapes is how debugging usually starts, and there’s nothing dumb about it.
The mistake was treating the analogy like evidence before any evidence had arrived. My AI took “this is like EC2” as a constraint on what to look for, not as a hypothesis to test. The investigation moved into EC2-shaped territory before the actual failure had been read. The error was sitting right there. The framing made it invisible by pointing somewhere else first.
Past me should’ve pasted the output before describing what it looked like.