> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ngram.space/llms.txt
> Use this file to discover all available pages before exploring further.

# One runtime, many surfaces

> Adapters, delivery, scheduled work, and embodied expression around the Entity.

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](/architecture/autonomous-wake) for tuning and [usage controls](/guides/usage-and-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](/spatial/capabilities) describes these boundaries.

Source: [`presence/daemon.py`](https://github.com/ngramspatial/ngram/blob/main/ngram/presence/daemon.py) and [`ngram_ar/bridge_server.py`](https://github.com/ngramspatial/ngram/blob/main/ngram/ngram_ar/bridge_server.py).