Background sessions

Background apps activate without a live chat turn. State is held in background sessions (per user / app), routed by channel providers, and executed by digitorn-background + the daemon.

Session limits

runtime.session_mode is accepted (mono default, or multi) but has no runtime effect on its own - the real controls are two separate caps:

Field	Meaning	Default
max_sessions_per_user	Hard cap on open sessions per (app, user). New session creation is refused once the cap is hit.	0 (unlimited)
max_concurrent_activations	Hard cap on concurrent turns running for this app at once, across all users.	0 (unlimited)

yaml

runtime:
  mode: background
  max_sessions_per_user: 5
  max_concurrent_activations: 20

For per-user routing - each user's events landing in their own session instead of one shared thread - that's a per-provider concern, not a top-level runtime setting: set activation.session to a template (e.g. "{{event.payload.user_id}}") and activation.owner on the channel provider. See Channels → Activation.

Wiring

1. Declare tools.modules.channels.config.providers.
2. Users create / fill sessions via the API / UI your deploy exposes.
3. Activations inject a message and run the entry agent.

Exact REST paths and payload fields: verify against the running daemon's own OpenAPI docs. See Channels for the YAML shape.

Session wake-ups from an agent turn: scheduler.schedule.

Related

• Channels
• Primitives