Conversations, projects, and sharing
Bergur DavidsenUpdated 2026-07-14
Usable Chat can preserve conversations so you can return to work, group related chats in projects, branch from an earlier point, or share a snapshot where those features are enabled.
Persistence improves continuity, but it also creates records. Choose context and sharing settings as carefully as you choose the prompt.
Conversation history
A stateful first-party conversation stores its message tree and associated conversation state under your authorized account. Open it from the conversation list to continue.
Chat titles can be generated or edited to make history easier to scan. Use a title that describes the goal without exposing sensitive content in navigation.
Some surfaces are intentionally temporary or stateless. An embedded assistant can let the host own persistence, and a developer API caller must implement its own state unless the API explicitly says otherwise.
Organize work in projects
Projects group related conversations and can supply project-level context. Use a project when several chats share an ongoing goal, source set, or working convention.
Before adding a conversation, check that its content belongs inside the project's permission and retention boundary. Moving or copying a chat into a project should not be used to broaden access to information from another workspace.
Project behavior and controls can vary by account. If project context is not visible, use explicit workspace and fragment context instead.
Long-conversation compaction
Long message histories eventually exceed practical model context limits. Released Chat behavior can compact earlier history into a shorter representation and continue the conversation.
Compaction preserves continuity, but detail can be lost. Chat should surface a notice when this happens.
After compaction:
- restate the current objective and non-negotiable constraints;
- reattach or reselect authoritative sources if needed;
- ask Chat to identify assumptions inherited from earlier work;
- start a new conversation when exact historical wording matters.
Do not rely on a compacted summary as the only record of an approval or decision.
Branch a conversation
Branching creates a new path from an earlier message where enabled. It is useful for testing an alternative prompt, model, or approach without overwriting the existing path.
A branch copies relevant prior conversation content into another message path. Review inherited files, sources, and secrets before sharing or continuing it.
Use a new conversation instead when the new task should not inherit the original context.
Share and clone
Where enabled, sharing creates a view or snapshot that another person can open. Cloning lets an authorized viewer continue from copied content in their own context.
Treat a shared conversation as a deliberate publication step:
- Read the complete message path that will be shared.
- Remove or avoid secrets, credentials, private URLs, personal data, and confidential attachments.
- Check generated output and tool results, not only user prompts.
- Confirm the intended audience and link controls.
- Open the shared result as a viewer and verify what is exposed.
A shared snapshot does not grant access to the original private workspaces or live tools. Conversely, a copied message can still disclose information that was generated from private context. Permissions on the source do not redact prose already present in a snapshot.
Prevent secrets in shared snapshots
Never place access tokens, API keys, bearer credentials, session cookies, or private embed keys in a prompt. Use placeholders in examples.
If a secret entered a conversation:
- Stop using the secret.
- Revoke or rotate it in the issuing system.
- Do not share, clone, or branch the affected path.
- Delete or restrict the conversation according to available retention controls.
- Report the exposure through your organization's security process.
Editing a later message does not make an exposed credential safe again.
Host-owned embed persistence
An embed can run statefully through Usable Chat or statelessly with the parent application storing history. In a parent-owned design, the host must preserve message order, branch identity, tool results, and user authorization.
Do not store embed conversation data in browser storage when the content requires stronger controls. Use an authenticated backend and a documented retention policy.
Troubleshooting
A previous chat is missing
Confirm the signed-in account and whether the chat was stateful, temporary, shared, or host-owned. Search by a stable title if available.
A long chat forgot a constraint
Look for a compaction notice, restate the constraint, and re-add its authoritative source. Start a new chat if exact detail is critical.
A viewer cannot open a shared link
The link may be disabled, expired, or restricted. Confirm the current sharing controls without broadening access to the source workspace.
A clone lacks tools or context
Cloning copies conversation content, not every permission or runtime capability. The viewer needs their own model, tool, and workspace access.