> ## Documentation Index
> Fetch the complete documentation index at: https://differentai-cleanup-ai-gateway-models-replacement.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Cross-chat memory

> How OpenWork can answer questions about past sessions.

OpenWork's cross-chat memory currently comes from saved session history. It is not a separate long-term memory database, and it does not automatically inject every old chat into every new prompt.

When an agent is running inside the OpenWork app, it can use OpenWork's semantic UI actions to look up past chats:

* `session.list_sessions` lists every loaded session across the workspaces the app knows about (pinned first, then newest). Pass `limit` to cap the count or `workspaceId` to narrow to one workspace.
* `session.search` finds sessions by title or transcript text.
* `session.read` reads recent messages from any session by ID, without opening it.
* `session.open` shows a session to you, when you ask to see it.

That means you can ask things like:

* `What did I say in the customer migration session?`
* `Find the session about the pricing page redesign and remind me what we decided.`
* `Open the onboarding bug chat and summarize the next steps.`
* `What did I ask you to do in session ses_abc123?`

## What happens

1. The agent lists or searches sessions and matches by session ID, title, workspace, or topic words you provided.
2. If there is one clear match, the agent reads that session's transcript by ID and answers from the returned messages.
3. If there are multiple likely matches, the agent asks which session you meant.
4. If you asked to open the chat, the agent opens it after reading.

Reading a session (`session.search`, `session.read`) never changes what is on your screen. An agent only opens another session (`session.open`) when you ask to see it.

## How agents manage other sessions

Agents address other sessions by id, and by default nothing on your screen changes. Showing you something is a separate, explicit step.

* **Read**: `session.search` and `session.read` return transcripts without opening anything.
* **Talk**: `session.send { sessionId, text }` appends a prompt to an existing session by id. The message is written immediately; if that session is in the middle of a turn, its run handles the new message at its next step (nothing is rejected or lost). `session.create` starts new sessions the same way.
* **Show**: `session.open` and `workbench.session.focus` are the only actions that move your pane. `session.send { reveal: true }` sends first and then opens that session for you.
* **File**: `session.rename`, `session.pin`, and `session.archive` act by id and do not open the session (archiving the session you are looking at closes its tab).

`composer.set_text`, `composer.send`, and `composer.stop` are different: they type into, send from, or stop whichever composer *you* currently have focused. They are for "type this for me here", never for reaching another session — if you switch panes while the agent is typing, the text goes to the pane you switched to. Agents are told to use `session.send` instead.

## How agents manage other sessions

An agent can start sessions (`session.create`) and file idle ones away (`session.archive`). The rule is check status, then archive, and a warning always goes back through the channel the request came from: you get a dialog, an agent gets a structured result in its own conversation.

1. **Check status.** `session.list_sessions` and `session.read` return `status` and a `working` boolean for every session. `working` is true while a turn, subtask, permission request, or question is still open.
2. **Archive once it is idle.** Archiving a session with `working: false` completes immediately and preserves its context. If an agent tries to archive a session that is still working, nothing happens in the app: the agent receives `target_working` with the advice to ask you to stop it in the app if you want it closed, or to leave it running. A session that tries to archive itself, or its parent, from inside its own turn receives `self_archive_while_working`: it should finish the turn so its conclusions can be reviewed; the reviewer archives. Restoring an archived session never restarts stopped work.

Stopping a session is yours: use the Stop button in that conversation. When you archive a working session yourself, from the sidebar, OpenWork asks a short confirmation naming the session ("Stop the current task and archive?") with **Keep session open** and **Stop and archive**.

### Model and reasoning effort

Every session is bound to a model, and agents can see and set it without opening the session or reading OpenWork's storage:

* `session.list_sessions` entries and `session.read` results carry `model: { providerId, modelId, variant }`. `variant` is the reasoning effort you see as the behavior pill in the composer (for example `low`, `medium`, `high`); it is `null` when the provider default applies. Before a session has a model bound (no `model` at creation and no turn yet), `model` is `null`.
* `session.create` accepts the same shape as `model`, either once for every session in the call or per entry. The model is applied when the session is created and again on its first turn, so the session runs at the requested effort from the start and reads back with that `model`. Sessions created without `model` use the engine default.

Changing the model of an existing session by id is not available to agents yet; the composer's model picker does that for the session you have open.

## Current limits

* Session lookup is based on the sessions OpenWork has loaded for the current app and workspace context.
* Transcript reads return a bounded set of recent messages from the opened session. If an older part of a long chat is not returned, the agent should say that instead of guessing.
* This is not semantic search over every message yet. Clear titles, session IDs, workspace names, or topic clues help the agent find the right chat.
* The agent can only read sessions available to the current OpenWork app and user.

## How to ask

Give the agent whatever clue you have: a session ID, title, person name, project name, workspace, or rough topic. For example: `Use the OpenWork app UI to find the customer migration chat and tell me what I said about customer references.`