Shared memory
Shared memory keeps knowledge you deliberately want to carry into future sessions: decisions, preferences, project context, and reference material. Ask your agent to save or recall it in ordinary language. CLI setup connects supported agents to this memory.
Memory is useful for recording a decision as you make it. For turning accumulated evaluation findings into reusable instructions, prefer Docs and skills.
Choose where the memory applies
Section titled “Choose where the memory applies”A memory has a place that determines where it is relevant:
| Place | Use it for |
|---|---|
| Repository | Conventions or context specific to one codebase. This is the default when you work inside a repository. |
| Project | Decisions shared across the repositories in a project, such as a service contract or release process. |
| Organization | Practices and reference material relevant throughout the organization. |
Use a project home for knowledge spanning that project’s repositories. Use an organization home when the knowledge applies more broadly. This keeps a local convention from becoming guidance for unrelated work.
Choose who can use it
Section titled “Choose who can use it”Audience determines who can see and edit the memory. Choose yourself, a team, the organization’s members, or a project’s members.
Place and audience are independent. A memory relevant throughout the Checkout project can be restricted to the Operations team. Giving it a project home does not automatically share it with the project’s members; say who it is for as well.
A private memory can also be restricted to the current machine, for example when it describes a local development setup. Broader sharing and changes to existing memories depend on your permissions.
Save a repository memory
Section titled “Save a repository memory”Be explicit about the knowledge and audience:
Remember that this repository uses pnpm and that changes to checkout need the integration tests. Keep this relevant to this repository and visible to everyone in the organization.
The current repository supplies the default place. If Capacitor cannot identify it, name a project or explicitly request an organization-wide home.
Save a project memory
Section titled “Save a project memory”Use a project for decisions that should follow work across its repositories:
Remember that the Checkout project’s API and web releases must remain backward compatible for one deployment cycle. Make this relevant throughout the Checkout project and visible to its members.
For a narrower audience in the same place:
Save our Checkout deployment checklist as a memory for the Operations team, relevant across the Checkout project.
Future work in that project’s repositories can find the memory, subject to its audience. Scope selector + Projects explains how projects group repositories.
Save an organization memory
Section titled “Save an organization memory”Specify both an organization-wide home and the intended audience:
Remember that every production release needs a rollback procedure. Make this relevant across the organization and visible to everyone.
An organization home is useful for shared practices, terminology, and reference material that should remain relevant when someone switches repositories or projects.
Recall, update, or retire a memory
Section titled “Recall, update, or retire a memory”Ask the agent for the knowledge you need:
What do we already know about deploying the Checkout project?
Find our organization-wide release guidance and use it when preparing this release.
Update the existing Checkout release memory: compatibility must now last two deployment cycles.
Archive the old staging-access instructions; they no longer apply.
Reuse or update the existing memory when the knowledge changes, rather than saving another copy. You can also ask to share an existing memory with another audience or move a repository memory to a project when it becomes relevant across repositories.
Review memories in the web UI
Section titled “Review memories in the web UI”Choose All Repositories, a project, or a repository in Scope, then open Knowledge → Facts and select Memories. Search for the wording and use Audience or State to narrow the results.
Review the memory’s place and audience as well as its content. If it belongs in a different context or needs updating, ask your agent to make the specific change. Users with permission can Archive memory or Unarchive memory from the row. Use the Archived memories state to find retired entries.
The session-start index
Section titled “The session-start index”Capacitor gives agents a compact index of relevant memory descriptions at session start. Repository, project, and organization memories can contribute, subject to audience and machine context. The agent can read a full memory or search for more when the task needs it.
The index contains descriptions, not every memory body. It is a starting point for recall rather than the entire memory store. A session can still start if the index cannot be fetched.
To disable this index for a profile:
kcap config set disable_memory_index trueThis is independent of disable_session_guidelines, which controls guidance retained from evaluations. See Docs and skills for that guidance, and Session recap and recall for searching earlier conversations.
