Yoda worked on our bench. On stage, the venue WiFi stalled and the companion stopped listening.

We finished Top 5 at Dell InnovateDash. The failure still bothered me because blaming the network was only half true.

The product had no screen to hide behind

Yoda was built for an elderly user who may never open an app. The interface was a small ESP32 companion with an on-device wake word. A Python MCP server exposed eight voice-callable tools, while a caregiver dashboard approved sensitive actions.

That constraint shaped the system. A request could reach community services or a family member, but the agent could not act alone. Every consequential action became a caregiver approval first.

Yoda's early breadboard, camera and speaker hardware
The first hardware pass put the camera, audio and wake-word path on one constrained device.

The postmortem found our own bottleneck

The camera relay opened a new TLS connection every two seconds. On weak WiFi, that polling loop occupied enough of the device's attention to starve the wake-word detector. The companion looked offline because it could no longer hear the user reliably.

Yoda voice request flowing from the ESP32 companion through eight MCP tools to a caregiver approval gate
Voice could start the request, but the agent could not complete a sensitive action without caregiver approval.

We throttled the idle poll to 15 seconds and kept the wake-word path responsive. A production version should go further: persistent connections, explicit offline behaviour and a local queue for anything that can wait.

The stage failure was painful, but useful. Hardware demos do not fail at clean API boundaries. The network, firmware and user interaction all compete for the same small device.