The Assistant Kept Blaming the Hardware
A voice assistant stopped responding for the second time in a week. This time it wasn't the mic — it was an AI reaching for its last known answer instead of checking its own recent changes.
Last week I wrote about a genuinely defective smart speaker — three hours of debugging that ended with a refund, because the streaming audio path was dead on arrival. This week, the same device broke again, on the same assistant, and Claude kept telling me it was the hardware. It wasn't. Watching it insist on that answer twice, for two different wrong reasons, taught me more about working with AI on live systems than the actual fix did.
The setup: a Home Assistant Voice Preview Edition speaker with the wake word "Hey Jarvis," running through a pipeline that also talks to Kith, the family-assistant app I built. Earlier that night I'd added a firewall rule to let Kith's timer state sync back to Home Assistant. A few hours later, the speaker started blinking red on every wake word.
First pass went clean: debug logging on, wake word tested, and the log line showed exactly what broke — intent-not-supported: conversation.google_ai_conversation is not found. The firewall change had cut outbound access for the Google AI integration, so the conversation agent had gone unavailable and every pipeline run died on the same step. A config reload brought it back. Real root cause, real fix, maybe fifteen minutes.
Then it broke differently. Wake word worked, chime played, no spoken response. And this is where it got interesting: Claude's first instinct was to reach for the same conclusion as last week's actual hardware defect — a dead streaming-audio path. I pushed back, because I knew what I'd actually just changed. It backed off, checked more carefully, and found a real config problem: it had spent ten minutes testing whether Piper (the local TTS engine) was healthy, when the pipeline was actually configured to use ElevenLabs. Piper being fine was irrelevant. It had been debugging a component that wasn't even in the request path.
After fixing that assumption, a new theory showed up — a qos_policy_applied field on the device's network attributes, which looked like traffic shaping might be strangling the audio stream. I let it chase that one for a few minutes before it checked the raw UniFi client record and found the field didn't exist there at all. It was something Home Assistant's own integration had synthesized from something else and mislabeled. Another dead end, minutes not hours, but still a hallucinated lead treated as evidence.
At that point I told it directly: it kept reaching for hardware, kept re-deriving the same investigation from scratch, and wasn't writing any of it down — so every new theory competed with old assumptions instead of its own recent findings. It agreed, and started logging live to an Obsidian vault mid-session instead of after the fact. The actual fix, once it stopped guessing, was almost anticlimactic: a factory reset earlier in the night had silently reverted the wake word from "Hey Jarvis" back to the device's default, "Okay Nabu" — so I'd been saying the wrong phrase the whole time — and a full Home Assistant restart cleared whatever stale state was left over from the network changes.
The pattern that generalizes: an AI assistant debugging a live system doesn't carry forward its own actions by default. Ask it what changed in the last hour and it will answer from whatever pattern matches best — often the most recent memorable failure, whether or not it's actually relevant — rather than from an audit of what it actually did. That's not a model-capability gap; better reasoning doesn't fix a missing changelog. What fixes it is treating "write down what changed, as you change it" as a hard requirement, not a nice-to-have you get around to after you've already burned twenty minutes on the wrong theory twice in the same night.