Create and manage shared memory — git-tracked repositories hosted on Letta Cloud that are attached to one or more agents and projected into their filesystems. Use when the user wants to share memory or files across agents, store context outside your own MemFS, attach or detach shared memory, or inspect its file history.
72
87%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Shared memory is memory created independently of any single agent, designed to be dynamically attached to or detached from multiple agents. Each unit of shared memory is a shared memory repository: a git repository hosted on Letta Cloud, owned by your organization rather than by one agent, reachable from any environment (sandboxes, remote machines, sessions).
Shared memory works like your MemFS: attached repositories are real git checkouts on disk, and you read, edit, and commit with ordinary git. The harness pushes clean committed changes after each turn. Each repository has its own projection root (next to your memory directory, not inside it) and its own remote origin, and other agents may be writing to it too.
Create a shared memory repository when:
Attached shared memory is mounted next to your memory directory, one git checkout per repository:
ls "$MEMORY_DIR/../" # attached repositories appear here by name
cat "$MEMORY_DIR/../<repo-name>/<path>" # read like any fileEdit files with your normal file tools, then commit with git. The mount's origin and credentials are already configured:
cd "$MEMORY_DIR/../<repo-name>"
git add <files>
git commit -m "describe the change"The harness pushes clean commits from read/write attached repositories after the turn. If a push collides with another agent's work, it pulls with rebase and retries once. Dirty files and conflicts are not changed automatically; the harness adds a reminder to the next turn instead.
To pick up other agents' changes:
git -C "$MEMORY_DIR/../<repo-name>" pull --rebaseIf a push is rejected (another agent pushed first), git pull --rebase then push again.
History is ordinary git history:
git -C "$MEMORY_DIR/../<repo-name>" log --oneline -- <path>Use the letta shared-memory subcommand. It uses your harness auth (works even when LETTA_API_KEY is not in the shell env) and inherits the agent id from AGENT_ID, so --agent is only needed when targeting another agent.
# List org repositories (marks which are attached to you)
letta shared-memory list
# Create a repository
letta shared-memory create --name shared-notes
# Attach to yourself: attaches via the API, clones the local mount at
# $MEMORY_DIR/../shared-notes, and recompiles the system prompt projection
letta shared-memory attach shared-notes
# Attach to another agent (its mount materializes in that agent's environments)
letta shared-memory attach shared-notes --agent agent-...
# Detach (leaves the local mount directory in place)
letta shared-memory detach shared-notes
# Repair/refresh mounts: clone or pull every attached repository. Use this when
# the system prompt references a repository that is missing on disk (e.g. after
# it was attached from another surface while this session was running).
letta shared-memory sync
# Commit history via the API (works even without a local mount)
letta shared-memory history shared-notes --path docs/plan.md$MEMORY_DIR/../<name> is missing — the repository was attached without materializing the mount. Run letta shared-memory sync.sync reports "mount path already exists and is not a git repository" — a plain directory (usually created by hand before the mount existed) is occupying the mount path. Inspect it, salvage anything worth keeping, move or delete it, then re-run letta shared-memory sync.letta shared-memory sync so every session and other agents see the same checkout.letta shared-memory sync to get your own mount.letta shared-memory attach waits for the attachment to be visible before cloning.@letta-ai/letta-agent-sdk exposes these operations as client.repositories (with files and versions helpers), and shared memory can be attached for a session's lifetime via resources: [{ type: "repository", repositoryId }] on cloud sessions. The REST resource is /v1/repositories.7a4337e
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.