Squad & Shared Memory

How Shared Memory Works

By TermSquad · Last reviewed

Shared memory stores selected project knowledge that supported agents can recall later. It helps preserve decisions, conventions, and useful discoveries when a conversation ends or you switch agents.

The shared store belongs to the agent user on the computer. Memories should be scoped to the correct project.

Good things to save

  • An architectural decision and the reason for it.
  • A non-obvious bug cause and its fix.
  • A reliable build or test command.
  • Project conventions and constraints.
  • A concise summary of completed work and the next step.

Include enough context for another agent to understand when the information applies. Do not save credentials or a complete stream of terminal output.

How recall works

A supported agent identifies the current project, reads recent context, searches for the relevant topic, and opens the full observation when needed.

You can request this directly:

Recall the saved context for this repository. Tell me which decisions are relevant and check them against the current files before making changes.

A shared store does not mean that every project’s memories are relevant to every task. Old observations can also become outdated.

What memory does not replace

Memory is not a full conversation transcript, a source-code repository, or a disk backup. It does not make another provider inherit the first provider’s private reasoning or exact conversation.

It also is not automatic synchronization between separate TermSquad computers.

See Save, Find, and Update Project Knowledge and Memory Storage and Recovery.