Skip to main content
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.