Memory

Memory is context that persists across AI conversations. It allows the AI to remember decisions, terminology, and patterns specific to your workspace or team.

How Memory Works

Memory is stored as files in cloud storage via the sync API. The AI reads and writes memory during interactions using the cosmo_workspaces_update_memory, cosmo_workspaces_get_memory, and cosmo_workspaces_list_memory tools. You can view and edit memory files directly from the Hub — see Managing memory in the Hub below.

Workspace memory files are persisted server-side at the path workspaces/{workspaceId}/memory/{fileName} in your org's blob container, and indexed in the database with kind: WORKSPACE_MEMORY for fast listing.

File names must match ^[A-Za-z0-9 _-]+\.md$ (a bare markdown filename, no path separators or ..) — both the client and server reject anything else, since fileName originates from LLM tool-call input. Fetching a workspace memory file that doesn't exist returns 404 Not Found; an existing-but-empty file returns 200 with content: '', so "missing" and "empty" stay distinguishable.

Types of Memory

• Workspace Memory — scoped to a single workspace (decisions, terminology, context). Supports multiple named files (e.g. project-context.md, jira-rules.md).
• Team Memory — scoped to a team, shared across all workspaces in that team (conventions, patterns)
• Hub Memory — org-wide (preferences, conventions, cross-workspace patterns)

Managing memory in the Hub

Open a workspace in the Hub and expand the Memory section to see what Cosmo has remembered about it. Entries written by the AI and entries you write yourself look the same and live in the same place, so an edit you make is the same note the AI reads next time.

The list shows the beginning of each note, when it was last updated, and its size. Click one to read or edit it in full. While a note is open the list is hidden, so the note you are working on is the only one on screen.

• Add an entry — click Add entry, name it, then write the content.
• Edit — click an entry, change the text, then Save. Save stays inactive until something actually changes. While editing, a running byte count next to the file name shows how big this workspace's memory is as a conversation reads it — all of its notes together, with your edit in place — against the 8 KB a conversation can take. Past that amount the count turns amber as a heads-up, with a line saying so, but you can still save; only the amount within the bound is what's carried into future chats, the rest is not lost or trimmed from storage.
• If the note changed while you had it open — because Cosmo or a teammate edited it — Save is refused with a message saying so, instead of combining the two copies. Your text stays in the box: reopen the note to see the latest version and apply your edit again.
• Rename — hover an entry and click Rename, type a new name, then Rename again. The content is carried across unchanged. If a note is open when you rename it, it closes — its old name no longer exists, so saving under it would recreate the note you just renamed away from.
• Remove — hover an entry and click Remove, then confirm. Deleting asks twice on purpose: the AI may have written that note, and there is no undo.

Entry names may use letters, numbers, spaces, dashes and underscores. Anything else is tidied up automatically — type Q3 / planning and you get Q3 planning. A name already used by another note is refused rather than merged into it, so renaming can never overwrite a second note.

Each workspace's memory is its own. Switching workspaces in the Hub reloads the section for the workspace you moved to — you never see one workspace's notes under another's name.

Who can change it

The same rules as documents in that workspace. If a workspace was shared with you read-only, you can read its memory but not change it, and the editing controls are not offered.

How much memory reaches a conversation

Every message carries your memory with it, so each kind has a ceiling:

The note is counted inside the ceiling, so what reaches the conversation never exceeds it. Nothing is removed from storage — only what a conversation reads is bounded.

Team memory is read in the same order everywhere — your personal team first, then your other teams from newest to oldest — so the team that gets cut is the same one whichever way you look. When a team's memory is deleted, or you leave a team, the app stops using its memory the next time it syncs.

Seeing exactly what is in effect

GET /api/v1/memory/effective?workspaceId=<id> returns the memory your next message would carry, built by the same code the app uses, as { sections: [{ scope, teamId?, bytes, truncated, content }], totalBytes }. There is one section for each kind that has memory (teamId appears on team sections only), truncated is true for a section that was cut, and totalBytes is the sum of the sections. Leave out workspaceId to see what a chat outside any workspace gets. It needs your sign-in token, and only ever reads your own organization.

Memory the AI writes during a chat

When you ask Cosmo to remember something, it writes the same notes this panel shows. The panel updates as soon as it does, and the new content is used from your next message on — so asking about it again in the same conversation returns what was just written, not what was there before.