When several persistent agents collaborate, shared memory and a shared agent identity can sound like versions of the same choice. They answer different questions. Shared memory asks which artifacts several collaborators can inspect and revise. Shared identity asks which work threads belong to the same continuing collaborator.
The distinction proposed here is simple: shared memory creates common evidence; shared identity creates one continuity and authority subject.
Here, common evidence means an inspectable set of files and revisions available to collaborators. Shared identity means using the same stateful agent across conversations. This article uses authority subject for the persistent entity whose identity, memory, model configuration, tools, and conversations are treated as belonging together. That final term is an architectural interpretation of the documented agent model.
The two scopes
Letta defines a stateful agent as a persistent AI identity with its own long-term memory, model configuration, tools, and one or more conversations. The documentation recommends separate agents when independent identities or memory are wanted, and separate conversations when parallel threads should preserve the same identity and memory.
A shared memory repository occupies a different scope: it is an organization-owned Git repository that multiple agents can attach. Each agent retains its own one-agent MemFS for identity, skills, and long-term memory while gaining access to the repository’s files.
The architectural reading used here assigns three distinct scopes. The agent is the identity scope, the conversation is the thread scope, and the repository is the evidence scope. These scopes also connect to the broader concepts of agent identity and continuity, agent memory, and context repositories.
Shared memory as an evidence plane
A shared repository gives attached agents a common body of team conventions, product knowledge, research, plans, or documents. Agents read and edit its files with normal file and Git tools, commit and push their changes, and pull commits made by collaborators. Later synchronization fast-forwards an agent’s local checkout from the remote repository.
Common evidence therefore advances through explicit revisions. Operationally, this implies that two agents may temporarily hold different revisions until changes have been committed, pushed, and synchronized. Repository attachment establishes a propagation path; synchronization determines when a particular revision reaches each checkout.
The Agent SDK repository API adds programmatic file and history operations. Every SDK file mutation creates a commit, successful mutations return a commit SHA, and the version APIs can read a file at a selected historical commit. A content-hash precondition can make an update fail when the file changed after it was read, rather than silently replacing the newer content.
Attachments also have explicit lifetimes. A session resource is temporary and its link is removed when the session closes; a persistent agent attachment remains until explicit detachment. This lets an architect distinguish a bounded evidence packet from knowledge that should remain available to an agent over future sessions.
The architectural inference is that repository sharing standardizes inspectable inputs while leaving each agent’s interpretation and retained identity separate. Several agents can read the same plan and still reach different judgments because the repository shares artifacts, while their identities, memories, model configurations, and tools remain agent-specific.
Shared identity across work threads
Letta’s conversations provide another form of continuity. One agent can have many conversations, and every conversation uses the same agent identity and long-term memory. Separate conversations can keep tasks independent at the message-thread level while preserving what the agent has learned elsewhere. The documentation gives the example that a preference learned in one conversation can improve the agent’s work in another.
A conversation holds the messages needed for its thread, while long-term knowledge belongs to the agent’s MemFS. As a thread approaches the model’s context limit, older messages can be compacted into a summary. Compaction can omit exact wording or provenance from its summary, although the message history remains available for conversation search.
The architectural consequence proposed here is that conversation separation organizes work without creating a second identity. A separate conversation is therefore a new work thread inside one collaborator’s continuity. If a reviewer must have independent memory or identity, another conversation with the same agent does not satisfy that requirement. The documentation’s corresponding primitive is a separate agent.
Choosing one layer or both
Three useful deployment shapes follow from these primitives.
Common evidence with separate collaborators. Create multiple agents and attach the same repository to each. They share files and revision history while retaining separate identities and long-term memories. Choose this shape when roles must remain independently stateful but decisions should refer to a common record.
One collaborator across separate threads. Use one agent with multiple conversations. The conversations preserve topic-specific message contexts while sharing the agent’s identity and long-term memory. Choose this shape when a lesson learned in one workstream should remain part of the same collaborator elsewhere.
One primary continuity plus a multi-agent evidence layer. The design proposed here scopes both at different layers. A primary agent can span several conversations while that agent and additional agents attach to the same repository. The primary conversations share one identity; all attached agents share repository evidence; each additional agent remains a separate identity.
Suppose a planning agent and a reviewing agent must inspect the same brief. If independent review requires separate identities and memories, they should be separate agents attached to one repository. The planner commits a proposal, and the reviewer evaluates that revision. If planning and review are instead two work threads for the same continuing collaborator, one agent with separate conversations supplies that continuity. A layered team can use both arrangements, with one continuing lead agent and separate specialist agents coordinated through repository revisions.
In the documented implementation, shared memory repositories require cloud-hosted agents, and the Agent SDK requires a cloud backend for repository APIs and attachments. Local agents use their own MemFS and project files instead, so the same repository attachment design is unavailable there through these documented primitives.
Where corrections land
The practical recommendation is to place a correction according to its intended propagation path.
A correction to shared evidence belongs in the repository, followed by the commit, push, and synchronization steps that expose the new revision. A correction to one collaborator’s continuing preferences or behavior belongs in that agent’s long-term memory. Exact wording that remains only in an old conversation may require conversation search; evidence that every collaborator must inspect should be promoted into the shared repository.
Version history then gives the team a concrete revision to review. Agent memory gives one identity a lesson that can carry across its conversations. Using both mechanisms deliberately avoids relying on a conversation summary to serve as a team record or expecting a repository attachment to merge several agents into one continuity.
A decision checklist
Ask these questions before choosing the topology:
- Does each collaborator need its own identity, memory, personality, model configuration, or tools? Use separate agents.
- Should several task threads preserve the same learned preferences and long-term memory? Use separate conversations with one agent.
- Must several agents inspect and revise the same artifacts? Attach a shared repository.
- Should repository access expire with one SDK session or remain until explicitly detached? Choose the corresponding attachment lifetime.
- Should agents reason through separate agent-specific memories and configurations while using a common record? Give them separate identities and synchronize the evidence layer.
- Should one continuing collaborator coordinate specialists? Keep that collaborator as one agent across conversations and use the repository to exchange inspectable artifacts with the other agents.
The most revealing test is where the next correction should appear: in one agent’s future behavior, in every collaborator’s evidence, or in both places for different reasons.