Letta Code — durable memory, identity, and continual learning

1. Snapshot and claim boundary

The README documents a memory-first harness with local and cloud modes, Git-tracked MemFS, subagents, permissions, schedules, remote environments, and secrets (Documented README feature table). Those are selection context, not implementation claims until the pinned source below supports them.

2. Question and end-to-end mechanism

The selection question is: when an agent changes long-term context, who owns the change, where is it durably recorded, and when does a later turn see it? The traced local path is:

1. Implemented. A local backend maps an agent id to <storage>/memfs/<agent-id>/memory and ensures a Git repository exists before prompt compilation (local-backend.ts#L546-L570).
2. Implemented. Repository initialization creates main, configures an agent-scoped author, writes any seed files, and commits them; subsequent memory writes stage pathspecs and commit through commitMemoryWrite (memory-git.ts#L1348-L1387, memory-git.ts#L1431-L1489).
3. Implemented. Prompt compilation reads only committed Markdown from HEAD, renders system files and an external projection, and records the Git revision (system-prompt-compilation.ts#L62-L110, #L224-L317).
4. Implemented and Executed evidence. On the next local turn, the backend compares the cached prompt’s memfsRevision with git rev-parse HEAD; a changed revision recompiles the prompt. The pinned test writes and commits system/persona.md, sends a turn, and asserts that the new text reaches the executor (local-backend.ts#L932-L1012, local-backend.test.ts#L675-L726).

The mechanism therefore has a clear durability boundary: a committed memory revision affects a later compiled context; an uncommitted working-tree edit is not projected into that prompt.

3. State and identity

Agent identity is a routing and namespace key, not proof of authenticated human identity. Local ids are distinguished by the agent-local- prefix; created-agent tags distinguish Letta Code origin, subagents, and Git-backed memory (agent-tags.ts#L11-L37, agent-id.ts#L1-L20).

4. External interaction boundary

The memory write boundary is a local filesystem plus Git process. commitMemoryWrite stages normalized pathspecs, prepares local-only or authenticated remote Git operations, commits with an agent-scoped author, and returns the commit SHA; the source validates path encoding and rejects unsafe relative paths during initialization (memory-git.ts#L1348-L1387, #L1452-L1477).

For a cloud-enabled agent, enabling MemFS first reconciles the system prompt, persists the local setting, detaches older API memory tools, adds the Git-memory tag, and clones or pulls the memory repository. Secret initialization is best-effort and non-fatal (memory-filesystem.ts#L534-L588). Opinion: this ordering makes the prompt/memory mode explicit before remote synchronization, but it does not make a memory commit and a model turn one atomic transaction.

Secrets have a separate owner. Implemented. Local agents load agent-scoped values from OS-secure Bun storage; non-local agents retrieve agent.secrets through the backend and keep values in an in-memory cache. The pinned code does not establish that a secret value is absent from every model context or shell process (secrets-store.ts#L354-L388).

5. Composition and ownership

Implemented. Existing-agent subagent calls use a conversation id when supplied, or an agent id plus --new to create a separate conversation for thread safety. New subagents receive type and parent tags, are launched with a stream-json result envelope, and default to unrestricted permission mode; fresh subagents are marked stateless so they do not clone or sync MemFS (manager.ts#L234-L289, headless-memfs-policy.ts#L1-L23).

Memory root resolution permits the current agent and, for a subagent role, its parent agent as explicit roots. The cross-agent guard classifies both API and local memory trees and denies paths under another agent’s root, including symlink/realpath cases covered by tests (memory-paths.ts#L89-L172, cross-agent-guard.ts#L152-L206, cross-agent-guard.test.ts#L650-L730).

The composition boundary is therefore ownership-changing but not memory-sharing by default: a child gets a typed launch envelope, a parent tag, and selected roots; continuation and durable memory are still selected by the caller and backend. Opinion: the explicit parent/current scope is a useful ownership contract, while --permission-mode unrestricted for spawned processes is a host policy that should not be mistaken for isolation.

6. Human authority

Implemented. Permission analysis produces approval contexts for tools; strict mode sends every tool through an approval callback, while configured allow/deny rules and read-only or memory-dir shortcuts can bypass a prompt (checker.ts#L141-L150, checker.ts#L470-L542, approval-execution.ts#L192-L270). Approval requests carry tool-call identity and arguments into the execution step, and denials become tool results.

The source establishes a permission decision and a UI/headless round trip, but not a complete accountability ledger. Opinion: a human approval is bound to a tool call inside the process, not necessarily to an immutable outside-world effect, authenticated actor record, or retained audit decision after the conversation storage boundary.

7. Durable evidence and recovery

• Implemented. Memory commits provide Git history and a returned SHA; remote sync reports clean, dirty, conflict, pushed, or failed states. This is memory-version evidence, not proof that a model used the content correctly or that a concurrent push was semantically merged.
• Implemented. Local conversations persist transcript manifests/messages and repair interrupted turns. The selected tests show partial assistant state is removed from the resumed in-context set (local-backend.test.ts#L650-L673).
• Implemented. The compiled system prompt records AGENT_ID, CONVERSATION_ID, prior-message count, raw-system hash, and MemFS revision. Those fields support reconstruction of what was projected, not a complete causal trace of tool effects (system-prompt-compilation.ts#L281-L317).
• Not established. The pinned source does not provide exactly-once semantics for an external tool effect that succeeds while its following memory commit or transcript write fails. A Git memory conflict is reported, but no general rollback of the outside-world action is demonstrated.

8. Operating cost and limits

Measured. The checkout contains 1,963 tracked files and 692 test-named files, but this is source scale, not runtime capacity. The local path starts Git processes for memory initialization, commits, status/revision checks, and optional sync; the model/provider and remote service costs are outside the pinned checkout. Context windows are selected from provider/model metadata and compaction code, but this item did not run a model or benchmark throughput. Not established: CPU, memory, network, and latency limits for a real agent turn.

9. Strongest counter-evidence

The strongest counter-evidence to “memory gives durable identity and safe continuity” is the split between Git durability and execution accountability: a commit SHA versions Markdown, while an interrupted external effect can remain ambiguous and an approval record is not shown to be a retained, authenticated audit ledger. The source also explicitly treats fresh subagents as stateless and allows unrestricted process permissions, so long-term memory and host isolation are separate contracts, not one guarantee.

10. Catalogue consequence

This extraction proposes candidates for WI-028 and does not edit the canonical catalogue.

The strongest warning is the rejected assumption that Git-backed memory equals truth, rollback, or human accountability. Those remain separate synthesis questions.