Sessions and runs

A session is the durable conversation or execution record. A turn is one admitted input. A run is the active model-and-tool execution for that turn.

The distinction matters because continuity, queueing, and execution do not have the same lifetime.

Sessions keep continuity

The session holds its project link, title, model defaults, messages, activity history, uploads, downloaded channel files, outputs, unread state, and usage. Downloaded channel files remain available for later work even after the coding environment stops.

Session shape depends on the work mode:

• a chat reuses one session across its conversation;
• an agent normally reuses one continuing workspace session for chats, wakeups, and connected channels; everyone who can open the agent can audit retained email cards and activity from its currently connected Slack channels there, while Slack actions still apply their own identity and membership checks, and connected channels share the agent's bounded context;
• every automation occurrence gets a new session;
• every dashboard build or refresh gets a new session;
• a sub-agent runs in its own child session linked to the parent.

A conversational agent-creation draft has its own private setup history. Those replies help configure the agent and use workspace credits, but they do not start the agent’s working conversation or execute the requested task. After activation, the creator can review that record in Agent settings → Setup history.

An integration can explicitly reset an idle persistent agent through the API. This keeps the eternal session and clears its transcript events, child runs, and compacted context in place after preserving billable usage. The agent identity, session ID, home-project memory and capabilities, files, sandbox, model preference, mailbox, and Slack or Telegram setup remain. A reset is refused while the conversation or one of its child runs is active, and it does not remove content already delivered to an external provider.

Runs have a lifecycle

Sending a message queues a turn. It starts when the session is available; otherwise d5s shows its queue position. You can cancel a queued turn before it starts.

While active, the run streams events such as sandbox readiness, tool calls and results, reasoning steps, sub-agent activity, research progress, connector approval requests, and agent context compaction. A direct web run can also end with a choice card; the user's selection starts the next turn in the same conversation. Unattended and external-channel turns do not wait for this web-only interaction. The run ends as completed, failed, cancelled, or stopped. The event log also supplies token, tool-call, duration, and context-window aggregates.

A persistent agent can also leave a durable attention item after it completes or parks work. Unlike a question card or tool approval, this does not pause the run and does not require someone to be watching the conversation. Open items point back to the exact agent conversation and appear on the workspace landing page until dismissed or expired. Seeing an item is recorded per workspace member, so one person's visit removes their visual cue without closing the shared item for everyone else.

An organization Owner or Admin who can also view the source conversation can open Settings → Usage → Activity to inspect an available run. Review its model, usage, outcome, and recorded activity alongside the conversation.

Interactive work uses the initiating user's model privacy selection. Automation, dashboard, and agent work uses its creator or owner's selection. A linked Slack or Telegram sender and the agent owner are protected by the stricter of their selections. Automation results retain their creators' no-training protection when an agent uses them later.

If the selected model cannot run under the organization's plan and privacy requirements, d5s refuses the work. See Security and trust for model availability and provider boundaries.

Once a model response starts, a period without new output does not by itself stop the run. The overall run time limit still applies, including while tools are working. Tools and context preparation keep their own execution timeouts.

Stopping may take a moment while active work finishes stopping. The conversation shows the stopping state and then its final status. Stopping does not delete the session.

Tool calls that completed before the stop, together with any recorded partial assistant text, remain in the conversation history. A later turn can therefore use completed work from the stopped run without repeating it.

Social drafts outlive the drafting run

When an agent prepares an X or LinkedIn post, the tool call creates a durable approval record rather than publishing immediately. The record remains in the originating conversation after the drafting run ends. Its preview is bound to one revision: the exact destination set, copy, and optional image snapshot.

A signed-in human can edit, reject, withdraw, or approve a pending revision. Editing creates a new revision, so an earlier approval view cannot publish the changed copy. Approval records the decision before provider delivery begins, then the same card reports each destination as publishing, published, failed, or uncertain. Partial success is preserved when one provider succeeds and the other does not.

Only definite failed deliveries offer an explicit retry, with a bounded number of attempts. An uncertain result is never retried automatically because the provider may already have published it. Check the provider before deciding whether to create a new draft. Connector Allow all, schedules, API keys, and agent or service identities cannot approve a social post for a person.

Acceptance and interrupted sends

Acceptance means d5s received your message; the agent may still be working. A lost network response does not prove that the message failed to arrive. Check the conversation's history before creating another copy.

Integrations sending to a persistent agent can use the optional request identity described in the developer retry guidance. Replaying the same supported request recovers its original acceptance receipt rather than sending another copy. The receipt is not the current run state: use history and live events to find out what happened after acceptance.

Credit admission and run limits

Before model work starts, d5s checks the organization's available balance, pace windows, and the initiating member's spend limit. These limits apply to chats, manual compaction, dashboard builds and refreshes, automation runs, and agent work. A blocked request does not start. Queued work that becomes ineligible is stopped instead of leaving the conversation active.

Plan limits apply to the root run and its sub-agents together. When a run reaches its plan limit, d5s stops further model-backed work and preserves the work already completed.

History and the live tail

The conversation shows recent history and live progress together. Scroll upward to load earlier turns without interrupting current work.

The conversation overview is a separate lightweight index across all authorized turns. The rail displays up to 40 consecutive entries around the part of the transcript you are viewing and spaces them evenly in a group centered on the page height. Near the top it omits newer entries; near the bottom it omits older entries. Selecting a marker loads any required history pages before focusing that turn.

Replace a mistaken message

Message editing replaces a native message you authored and the conversation after it. Active work stops before the replacement starts. Superseded messages and responses are removed from visible history and future conversation context, including previously compacted context. Earlier conversation remains available.

Editing changes the conversation, not the effects of completed work. Existing external actions, generated files, and usage charges remain in effect.

Compact older context manually

In an existing chat, project conversation, agent conversation, or dashboard chat panel, type /, choose /compact, then submit again to confirm. The command runs only while the session is idle.

Manual compaction uses the session's selected model to summarize eligible older context even when the automatic threshold has not been reached. It preserves the durable conversation record and does not ask the model for a normal assistant response. The conversation shows Compacting context while the summary is running, then keeps Context compacted in the timeline. If there is not enough older context to summarize, d5s reports that nothing needs compaction and does not start a model call.

Why the distinction matters

This model explains several product behaviors:

• another message can queue behind active work without creating a second chat;
• waking an agent, a bound Slack message, and authenticated inbound email all append audience-attributed turns to its continuing conversation; the owning agent keeps its configured communication toolbox and bounded shared context, while the audience routes the reply, and a supported email attachment joins the session-owned file record only when the agent reads it;
• an automation's runs can be compared without merging their transcripts;
• a completed assistant response can be branched into a new chat at that point in history;
• deleting a project is blocked while a run still owes a terminal event.

Personal local file permissions are an exception: they apply only to authorized Desktop-started turns, not scheduled, browser, or connected-channel turns.

For API integration and event handling, see the Developer guide.

Regional placement is not a session toggle

Where regional service is available under your contract, the organization is assigned to a deployment before customer data is created. Its sessions, runs, files, connector results, and model traffic then use that deployment's authenticated API origin. A session cannot switch region per request, and SDKs must use the organization's assigned base URL rather than silently falling back to another geography.

Identity, payment processing, transactional email, model providers, and customer-selected connectors may process data outside the organization's region. Subscription, credit, and usage records remain associated with the organization in its assigned region. Confirm the provider and residency scope in your contract; a regional storage choice does not itself guarantee regional model inference.