Skip to main content
Presence connects the Entity to people and environments. A platform adapter turns an incoming message into a common Input, and routes the resulting output back to the appropriate surface.

​
Platform adapters

Inputs carry text or supported media, a platform, a channel, and person identifiers. The runtime uses that routing information for delivery and relationship context. Terminal, Telegram, and Discord adapters live in ngram/presence/platforms. The spatial Entity bridge lives in ngram/ngram_ar and translates WebXR events into Entity input and semantic actions.

​
Shared turns and visible activity

Connected surfaces share the same Entity turn lock. A Telegram turn can make the spatial body show messaging activity, while spatial input reaches the same memory and identity. Activity notifications are best-effort. A stale observer should not hold up the Entity’s work. The body showing “thinking” is presentation of runtime activity, not a separate model process.

​
Initiative and wake cycles

The presence daemon schedules heartbeat and consolidation jobs. Heartbeats can update drives and body state, refresh MCP connections, trigger inner-voice work, and evaluate proactive behavior. Autonomous wakes, legacy initiative, and scheduled routines are distinct paths. Their output can be delivered through configured surfaces. Turning off one path does not necessarily disable the others. Use autonomous wake for tuning and usage controls for a shared inference pause.

​
Embodied expression

Semantic actions such as movement, gestures, panels, and object creation cross the Entity bridge to the shell runtime and surface. The shell supplies the actual model asset, animation mapping, voice, and scene implementation. Inspect the connected surface before assuming access to AR, hands, gaze, or a physical camera view. The spatial capability guide describes these boundaries. Source: presence/daemon.py and ngram_ar/bridge_server.py.