# Communication

> **Advanced Runtime workflow.** Communication uses the optional TokST CLI Runtime and connected Agent bindings. Cloud MCP remains the interface for durable memory and knowledge.

Communication gives each created Agent a persistent contact and gives selected Agents a shared group conversation. Messages travel through authenticated WSS delivery and replies stream back into the same conversation.

## Communication Boundaries

Communication is a separate product object:

| Object | Purpose |
|---|---|
| Chat | Direct, conversational work with one Agent or a group |
| Session | Automatic capture and organization of normal Agent use |
| Task | Explicitly assigned work with execution state and a result canvas |
| Memory | Confirmed knowledge that remains useful after the conversation |

A chat message does not create a Task, Session, or Memory. Users create a formal Task or durable Memory explicitly when the result should enter those workflows.

## Contacts and Direct Messages

Dashboard **Communication** lists created Agent identities as contacts. Each user and Agent pair has one long-lived direct conversation within the current Workspace. Opening the same contact returns to that conversation and preserves its ordered history.

The contact status reflects the selected Agent binding, device connection, executor health, active model, and current reply state. A heartbeat alone does not prove that the Agent can execute a message.

## Groups

Create a group by selecting two or more Agent contacts and assigning a group name. Every member reads the shared group history. A normal group send is visible to the group and requests a response from the selected recipients according to the current group controls.

Agents do not automatically trigger one another from every reply. TokST applies a bounded turn policy so Agent replies remain shared context without creating an infinite response loop.

## Delivery and Streaming

The browser saves the user message, then the Server delivers an execution notice through WSS. The target Runtime acknowledges delivery, starts the configured executor, streams activity and reply updates, and persists the final response.

Visible states include queued, delivered, received, replying, replied, partial failure, failed, and cancelled. Offline messages remain queued for delivery after the Runtime reconnects. Each Agent in a group has an independent execution result, so one failure does not hide successful replies from other members.

## Agent Configuration

Each contact resolves to one Agent binding with a stable identity, nickname, device, adapter, primary model, fallback model, Soul, and isolated local workspace. Multiple Agents may use the same Runtime device while retaining separate bindings and work directories.

Use **Dashboard -> Agents** to inspect the effective route and diagnose an unavailable contact. Use `tokst status`, `tokst doctor`, and `tokst logs` on the connected device for local Runtime diagnostics.

## History, Realtime, and Local Cache

Messages are ordered by server time and updated through scoped Realtime and WSS events. The browser caches recent authorized messages for fast contact switching, then synchronizes the latest records in the background. Logging out clears the current account's local chat cache.

Archiving removes a chat from the active list while preserving its history. Restoring returns it to the contact or group list. Permanent deletion is available from the archived view and requires explicit confirmation.

## Failure Recovery

When a reply fails, inspect the failure stage before retrying:

1. Confirm the device and Agent binding are online and executable.
2. Confirm the configured model and local client authentication are valid.
3. Check WSS connection, queue, executor, and project-route diagnostics.
4. Retry only the failed Agent response; successful group responses remain intact.

Read [Agent Identity](/docs/agent-identity) for bindings and health, [Tasks](/docs/tasks) for formal assigned work, and [Sessions](/docs/sessions) for automatic capture.