Sessions and runs

A session is the conversation and its saved history. A turn is one message or trigger that d5s accepted. A run is the model and tool work for that turn.

A conversation lasts longer than any single run in it.

Sessions keep continuity

The session holds its project link, title, model defaults, messages, activity history, uploads, downloaded channel files, outputs, unread state, and usage. A named agent can answer individual requests in a Project chat while keeping its separate Home conversation. Each response retains its responder name. 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 keeps one continuing conversation across chats, wakeups, and connected channels; people who can open it can review retained email activity and activity from its currently connected Slack channels, while provider actions still require their own permissions;
• each automation run has its own history;
• an app dashboard keeps builds, refreshes, and agent contributions in its shared conversation; existing widget boards retain their build histories;
• delegated work remains linked to the task that requested it.

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 reset an idle agent conversation through the API. The visible conversation history is cleared, while the agent, its project settings, files, model choice, and connected channels remain. Reset is refused while work is active. Content already delivered to an external provider is not removed by a d5s reset.

Runs have a lifecycle

Sending a message queues a turn. It starts when the session is available; otherwise d5s shows the waiting messages inside the composer, above the text box. The queue shows three messages by default. Choose N more to show the rest, and select a message to read it in full.

Choose Steer on a waiting message to move it ahead of other queued messages and ask the active run to stop. Completed tool actions and partial output from that run remain in the conversation. The selected message runs next after the current run stops. Choose Edit to take a queued message out of the queue and back into the composer. Choose × to delete a queued message before it starts. These actions can change a message that has already started.

While work is active, the conversation shows progress, tool activity, approvals, and results. A direct web run can also ask you to choose a next step; that choice continues the same conversation. The run ends as completed, failed, cancelled, or stopped. Usage and activity remain available for review.

A persistent agent can also leave an 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. Unattended automation, dashboard, and agent work uses its creator or owner's selection. A named agent's dashboard contribution also respects the agent 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.

A saved catalog model follows its family: a new turn uses the newest version allowed by the organization's plan, provider and privacy requirements. Messages already sent keep the model version they used. Light, Medium, High and Auto use d5s's current choices on new turns, including when saved on an agent.

If no eligible version of the selected family can run under the organization's plan and privacy requirements, d5s refuses the work. See Security and trust for model availability and provider boundaries.

A run stops when it reaches the overall run time limit, including while tools work. It also stops as timed out when the model sends no text, reasoning, or tool request for 2 minutes while no tool works. Text and tool results it already produced stay in the conversation, so you can send the message again to continue.

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 partial agent text, remain in the conversation history. A later turn can therefore use completed work from the stopped run without repeating it.

AWS operations keep a receipt in tool history, without parameter values or raw AWS results. The agent's written answer can still include requested data. Check current AWS state before repeating an operation with an uncertain outcome.

A Pentest VM belongs to its conversation and can support several messages. Its temporary files must be exported before cleanup. Read an existing command result when its outcome is unknown; do not repeat the command to recover output. See Start a security test.

A failed run keeps its completed tool calls in the conversation history in the same way, with a short note that the run failed. A later turn can see, for example, that a reply was already delivered, so it does not need to send the reply again.

If a service restart or unexpected interruption stops an eligible chat or agent run, d5s can continue the task automatically from saved history. The agent checks uncertain actions before repeating them. If it cannot verify an action’s outcome, it asks you before repeating it. Stopped work stays stopped, and recovery requires current access. If recovery cannot complete, the run ends as failed. Check recorded activity before retrying, because completed actions are not undone.

Approved videos can finish after a reply

If the agent reports that an approved video is processing in the background, its reply can finish while generation continues. You can leave the conversation and return later. The video card keeps its status, and the agent reports the result when it is available. Stopping the chat reply does not cancel that video.

Social drafts outlive the drafting run

When an agent prepares an X or LinkedIn post, it creates a draft that waits for approval. It does not publish immediately. The draft stays in the conversation after the drafting run ends. Its preview shows one revision: the exact destinations, copy, and optional image.

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. After approval, the card shows each destination as publishing, published, failed, or uncertain. One destination can succeed while the other fails.

You can retry a failed post a limited number of times. d5s does not retry an uncertain post. Check the provider first, then decide 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, regular chat, or sub-agent conversation 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. A named request retains its original recipient during retries. Changing the next recipient does not change a request already accepted.

Credit checks

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. Purchased credits can fund work after a subscription pace window is full; member spend limits still apply. See Plans and credits. A blocked request does not start. Queued work that becomes ineligible is stopped instead of leaving the conversation active. A message queued for an agent waits instead: the queue shows Waiting for credits, and the message starts after credits are added.

A run that has started is not stopped by its cost. These checks apply when new work starts. Work done by sub-agents counts toward the organization's credits and pace windows.

History and the live tail

A long conversation first opens its recent messages and live progress. Scroll upward to load earlier messages without interrupting current work.

If recent messages cannot load, use the displayed retry action. Reloading does not send another message or remove the saved history.

During a service update, live progress can briefly reconnect while the agent continues working. Keep the conversation open. Check its history before submitting the same request again.

The conversation overview shows markers for nearby messages; select one to jump to it.

Replace a mistaken message

Message editing replaces a message you sent in d5s and the conversation after it. Active work stops before the replacement starts. Messages covered by a saved context summary cannot be edited. Newer messages can be replaced only when the edit leaves summarized history intact. Superseded messages and responses are removed from visible history and future conversation context. Earlier conversation and its valid summary remain 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 older context, even before d5s compacts automatically. The full conversation record stays, and the agent does not send a normal reply. 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;
• wakeups, Slack messages, and email all continue the agent's one conversation. Each reply goes back where the message came from;
• an automation's runs can be compared without merging their transcripts;
• a completed response can be branched into a new chat unless the copied history includes named-agent context;
• you cannot delete a project while a run in it is active.

An agent with approved browser access can start its saved browser under either Ask for approval or Allow all. Startup continues with the original browser request, including opening another tab; the browser panel can stay closed. A private or deliberately paused browser waits for you to return control. Website permissions still apply. See Browser access.

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, an organization has a selected d5s data region. A session cannot choose another region per request. API clients must use that organization's regional base URL rather than silently switching 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.

Google data in a running conversation

After connecting Google, start a new turn to use the connection. Tasks using AI may send relevant Google content to the AI providers used by the workspace. Disconnecting does not erase information already retrieved into a conversation. See Google data protection for AI processing and stored-data guidance.