A browser game knows about wins, damage, choices, and session state, while chat knows about conversation and identity. Directly sharing every object couples the game to internal prompt structure and risks sending noisy or sensitive state.
A bridge translates important moments into compact events. Those events can be rate-limited, labeled with the game, and turned into optional companion reactions.
What was actually going wrong
Passing raw game state into chat made prompts large and tied both systems to each other's implementation details.
What I tried
- Sending an event on every animation frame
- Letting the companion choose game actions automatically
- Embedding chat internals directly in each game
A narrow event contract reports meaningful milestones and lets the presence layer decide whether to respond.
Why it worked
Both sides depend on stable event names rather than private runtime objects.
A companion game bridge should convey meaning, not mirror the game engine.
Where EACI uses this today
Main games can surface companion presence while remaining playable on their own.
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.