Shared coding-agent memory comes with a service to operate
agentmemory is aimed at developers who want coding context to survive sessions and client changes. The README describes one memory server shared through hooks, MCP and REST, with a viewer for session inspection. The decision is whether that shared store is useful enough to justify operating and checking another persistent service.
Our recorded run supports a narrower conclusion than the README's product promises: the source checkout completed dependency setup, built successfully and returned a successful test-command result. We did not measure retrieval quality, cross-client continuity, provider costs or long-running workloads.
What our September 27 run established
The recorded run started on September 27, 2026 at commit bcf4f0d00d1c71e9221287a4778e4122ce2d7574. Its configuration lists 3 CPUs, 8 GB of memory and image lab-node:22. That image label does not establish the actual Node runtime version.
Dependency setup completed in 96 seconds with exit code 0, but its output first records npm ci failing because it required a suitable lockfile. Later output says "added 267 packages". The stored dependency metric is 294, and the recorded install size is 1,193 MB. We retain both counts with their labels rather than describing 294 as packages added. Successful dependency setup does not establish that the published CLI was installed or launched.
The build step completed successfully in 15 seconds. The test step completed successfully in 27 seconds. Its Vitest summary reported 1,812 passed, 0 failed and 1 skipped out of 1,813, with 170 test files passed and 1 skipped. The local-embedding smoke test was skipped. These are recorded summary counts: no new execution or complete-log reconciliation established exhaustive unique test coverage. The runner's 27-second step time also differs from Vitest's own reported duration of 19.78 seconds.
Npm audit recorded 11 advisories: 2 high and 9 moderate, with 0 critical and 0 low. The audited-package coverage is unknown. The record does not identify production reachability or establish the dependency state of a newer release, so these counts cannot support a current safety verdict.
The checkout metrics were 684 files, approximately 94,430 source lines and 35.8 MB. The record also identified two CI workflows, a tests directory and a compose file, with no Dockerfile. Those inventory facts do not verify a deployment path.
What first launch still needs to prove
The README requires Node.js 20 or newer with npm and npx. It describes interactive setup that selects integrations and a provider or keyless mode, starts the memory server and pinned iii-engine v0.22.1, and offers a global installation. Our source-checkout checks did not independently verify those first-launch steps, an installed-binary check, engine download or a running daemon.
The documented default ports are 3111 for REST/MCP HTTP, 3112 for iii streams, 3113 for the viewer and 49134 for the worker WebSocket. Automatic engine installation on macOS/Linux requires curl, a POSIX shell and tar. Native Windows requires manual installation of the pinned engine; the README also describes WSL2 and Docker Desktop routes.
Keyless mode disables vector embeddings. The README says memory_recall uses BM25, while memory_smart_search can also use structural graph matches when graph data exists. Local semantic recall requires EMBEDDING_PROVIDER=local and a restart; the first embedding request downloads Xenova/all-MiniLM-L6-v2. A configured LLM provider alone does not enable observation compression: AGENTMEMORY_AUTO_COMPRESS=true is also required. None of these modes received a measured retrieval workload in our run.
State normally lives in a platform-specific directory outside the repository. There is an important exception: existing ./data/state_store.db or ./data/iii-config.yaml takes precedence over the platform default for instance 0. An explicit --data-dir or AGENTMEMORY_DATA_DIR setting wins over legacy discovery. Resolve that location before planning backups or assuming that deleting a checkout removes its history.
Historical reports need version boundaries
The supplied issue pages provide reasons to test specific behavior, but they do not establish that every reported defect remains present.
Issue 911 reported secrets being preserved verbatim by the remember skill. It is now closed; on October 8, 2026, the maintainer said v0.9.30 scrubs write inputs and other stored text. That is a maintainer's fix statement, not a security result from our September run. Review capture and stored records using synthetic data before retaining private work.
Issue 1432 concerned a custom container running the v0.9.29 CLI with iii-engine v0.11.2. The reporter explicitly did not test the published engine image. The issue therefore does not establish that the supplied compose deployment was broken. The maintainer closed it on October 5, saying the fix would ship in 0.9.30, that compose already selected the Docker engine configuration, and that custom CLI containers should set AGENTMEMORY_III_CONFIG to the appropriate configuration file. Verify host-side health and restart persistence for the deployment you actually choose.
The September run predates those October statements. Its successful checks neither reproduce the historical reports nor verify the later fixes. The supplied v0.9.29 release page is a historical release reference, not evidence that v0.9.29 remains the latest release.
How to decide after a small trial
Use a disposable repository and an explicit data directory. Confirm that your client captures an event, saves a synthetic memory and recalls it in a fresh session. Check separation between two projects, then restart the service with the same directory and verify persistence. Finally, delete the trial data and check the result. These are recommended acceptance checks, not tests we performed.
Choose Mem0 when you are integrating a memory layer into an application: its own README documents SDK, self-hosted and managed routes. Choose Letta when you want the agent harness and runtime to own persistent memory; its repository now points active development to letta-ai/letta-code. Neither alternative was installed or benchmarked in our run, and neither is established here as a drop-in capture replacement.
How the ratings work
The scores are editorial judgments on a 1-to-5 evidence scale: 1 means substantial documented barriers, 2 means limited support for confidence, 3 means a workable basis with material checks outstanding, 4 means strong documented support within the stated scope, and 5 requires broad corroboration across that category. Unknown adoption or compatibility earns no positive evidence.
Setup ease is 3 because source setup and build completed, while first launch, four-port operation and persistent-state management remain separate work. Documentation is 4 for explicit requirements, search-mode distinctions, state-path precedence and validation steps; that rates the supplied documentation, not every integration's correctness. Community is 2 because the supplied issue exchanges show participation but do not establish response-time consistency or adoption. Maturity is 3 because successful repository checks and maintainer follow-up support a trial, while current audit status, workload behavior and recovery remain unverified.
Proceed when shared coding history solves a concrete problem in that trial. Keep the service's captured history, storage location and deletion behavior visible before expanding its use.