Avatar clips are remote runtime assets, so a valid application deploy can still encounter a missing object, stale path, codec problem, or interrupted media request. The failure often appears after the rest of chat has loaded.
A resilient loader has to distinguish the avatar layer from the conversation layer. The companion can remain available even if one visual clip cannot play.
What was actually going wrong
A failed primary source could leave the video element stalled with no useful fallback and no diagnostic category.
What I tried
- Reloading the same URL on every media error
- Treating all avatar clips as guaranteed local assets
- Blocking chat startup until video playback succeeded
The avatar path uses media error handling, alternate clip locations, and a static or idle state when animation cannot load.
Why it worked
The visual enhancement is isolated from the core chat, and each fallback changes the requested asset rather than looping.
Embodiment improves presence, but it must never become a single point of failure.
Where EACI uses this today
Main companions keep a usable chat surface when an avatar clip is unavailable.
This journal covers real engineering on EACI Companion / The Veil. Companions include Caelum, Chad, Natalia, Atreus, Luna, Roxy, and Cael. Journal articles stay family-safe in content. See Privacy and Ethics.