Why Phantasm

Why use Phantasm when other memory systems already exist?

Most memory tools optimize for storing more context. Phantasm optimizes for keeping the right context attached to the right repository, with local control, predictable runtime behavior, and agent guidance that stays with the project.

Core thesis

Project-scoped memory beats generic cross-project memory

If an agent works across multiple repositories, teams, and prompts, memory quality degrades when everything lands in one global bucket. Phantasm treats memory as part of the repository runtime, so retrieval, guidance, and lifecycle operations stay grounded in the codebase being worked on.

01

Mem0

Mem0 positions itself as a managed memory layer for AI agents, with open-source and hosted options plus broad integrations across agent frameworks.

  • Strong when you want a general-purpose memory platform with many integrations.
  • More platform-oriented than repository-oriented.
  • Phantasm is better when memory should live as project runtime state, not as a generic service layer.

Source: Mem0 docs

02

Zep / Graphiti

Zep focuses on context engineering, agent memory, and temporal knowledge graphs. Graphiti is its open-source temporal knowledge graph framework with hybrid search and MCP integration.

  • Strong when temporal or graph-based retrieval is the core problem.
  • More graph-heavy and operationally ambitious than many teams need.
  • Phantasm is better when the priority is a local-first repo memory runtime with simpler project boundaries.

Sources: Zep docs, Graphiti docs

03

Letta

Letta is built around stateful agents and editable memory blocks that can be attached to agents, shared, and kept in-context.

  • Strong when you want agent-centric state and persistent agent operation.
  • Its memory model is centered on agents and memory blocks, not specifically on repository runtimes.
  • Phantasm is better when the repository is the unit of truth and agent guidance should ship with the codebase.

Source: Letta docs

04

LangGraph Memory

LangGraph documents both short-term thread persistence and long-term user or application-level memory, backed by stores like Postgres or MongoDB.

  • Strong when you are already building directly inside the LangGraph stack.
  • Gives persistence primitives, but not a complete repo-scoped memory product opinion.
  • Phantasm is better when you want a standalone project memory workflow rather than assembling one inside a framework.

Source: LangGraph memory docs

05

OpenMemory

OpenMemory is presented as a persistent MCP memory layer that works across Cursor, VS Code, Claude, and other MCP-compatible coding agents.

  • Strong when you want one shared memory layer across multiple MCP-compatible tools.
  • Optimizes for cross-tool continuity more than repository-owned runtime state.
  • Phantasm is better when each repository should own its own memory lifecycle and agent instructions.

Source: OpenMemory page

Comparison matrix

Where Phantasm is different

Capability
Mem0 / OpenMemory
Zep / Letta / LangGraph
Phantasm
Repository-scoped by default
Usually no
Possible, but not the default product boundary
Yes
Local-first setup
Mixed: hosted-first or shared-layer patterns are common
Framework or graph setups often need extra storage decisions
Yes
Managed agent guidance
Usually separate from the memory layer
Often something you build around the framework
Built into bootstrap flow
Operational lifecycle
Platform APIs or shared memory semantics
Framework- or graph-level primitives
Structured runtime operations
Fits git-oriented workflows
Not as a primary abstraction
Possible, but not central
Yes

Why teams pick it

Clear reasons to choose Phantasm

  • Your agents work across multiple repositories and need hard context boundaries.
  • You want memory to live with the project instead of in a generic agent memory platform.
  • You want bootstrap, runtime behavior, and agent guidance in one repo-owned flow.
  • You care more about project-local clarity and operational control than about cross-tool shared memory.
  • You want a memory system that fits git-oriented engineering workflows rather than abstract agent state alone.

When not to use it

Cases where simpler options may be enough

  • You only need lightweight personal recall across chats, not repository runtime state.
  • You already have a mature external memory platform and do not care about local-first operation.
  • Your agents do not need structured project guidance or project-specific memory review.