hermes-agent/plugins/memory/supermemory
Ben Barclay 1289f12812 fix(memory): lazy-install supermemory + mem0 SDKs like honcho/hindsight
The supermemory and mem0 memory providers shipped third-party SDKs
(supermemory / mem0ai) that are not core dependencies, but — unlike the
honcho and hindsight providers — they imported those SDKs directly with
no tools.lazy_deps.ensure() preflight and had no LAZY_DEPS allowlist
entry. On the published Docker image the agent venv is sealed
(HERMES_DISABLE_LAZY_INSTALLS=1) and lazy installs are redirected to a
writable durable target (HERMES_LAZY_INSTALL_TARGET). honcho/hindsight
route through ensure() and install fine there; supermemory/mem0 never
called it, so their SDK was never installed on a hosted instance and the
provider silently reported itself unavailable even with the API key set.

Fixes:
- Add memory.supermemory + memory.mem0 to the LAZY_DEPS allowlist
  (tools/lazy_deps.py), pinned to current PyPI releases.
- Call ensure('memory.<x>', prompt=False) at each SDK-import chokepoint
  (_SupermemoryClient.__init__; Mem0MemoryProvider._create_backend),
  mirroring honcho's wrapped try/except shape.
- Drop the SDK-import gate from supermemory's is_available() — it was a
  chicken-and-egg trap (provider never loaded on a sealed venv, so
  ensure() never ran). Now key-presence only, like honcho/mem0.
- Add matching pyproject extras [supermemory]/[mem0]; update the
  lazy-covered-extras contract test (excluded from [all] by policy).

Tests prove each path fails without the fix and the real sealed-venv
durable-target gate accepts both features.
2026-06-29 00:25:36 -07:00
..
__init__.py fix(memory): lazy-install supermemory + mem0 SDKs like honcho/hindsight 2026-06-29 00:25:36 -07:00
plugin.yaml refactor(supermemory): session-level ingest + kebab aliases (salvaged from #32487) (#38756) 2026-06-04 11:50:02 +05:30
README.md feat(memory): add Supermemory setup connection summary 2026-06-27 15:07:34 +05:30

Supermemory Memory Provider

Semantic long-term memory with profile recall, semantic search, explicit memory tools, and full-session conversation ingest (one ingest per session) for richer profiles.

Requirements

Setup

hermes memory setup    # select "supermemory"

Or manually:

hermes config set memory.provider supermemory
echo 'SUPERMEMORY_API_KEY=***' >> ~/.hermes/.env

Config

Config file: $HERMES_HOME/supermemory.json

Key Default Description
container_tag hermes Container tag used for search and writes. Supports {identity} template for profile-scoped tags (e.g. hermes-{identity}hermes-coder).
auto_recall true Inject relevant memory context before turns
auto_capture true Store cleaned user-assistant turns after each response
max_recall_results 10 Max recalled items to format into context
profile_frequency 50 Include profile facts on first turn and every N turns
capture_mode all Skip tiny or trivial turns by default
search_mode hybrid Search mode: hybrid (profile + memories), memories (memories only), documents (documents only)
entity_context built-in default Extraction guidance passed to Supermemory
api_timeout 5.0 Timeout for SDK and ingest requests

Environment Variables

Variable Description
SUPERMEMORY_API_KEY API key (required)
SUPERMEMORY_CONTAINER_TAG Override container tag (takes priority over config file)

Tools

Kebab-case names are registered for the agent; snake_case aliases remain supported.

Tool Alias Description
supermemory-save supermemory_store Store an explicit memory
supermemory-search supermemory_search Search memories by semantic similarity
supermemory-forget supermemory_forget Forget a memory by ID or best-match query
supermemory-profile supermemory_profile Retrieve persistent profile and recent context

Source attribution

All Supermemory API calls send x-sm-source: hermes, and document writes stamp metadata.sm_source: hermes. This is a functional routing key, not telemetry: it groups Hermes-written memories into a dedicated "Hermes" Space in the Supermemory app, so you can filter, browse, and bulk-manage them per source agent (alongside Codex, Claude Code, etc.) from the Supermemory UI.

Behavior

When enabled, Hermes can:

  • prefetch relevant memory context before each turn
  • buffer the full conversation and ingest it as one session at session end (or on /reset, branch, compression, or shutdown)
  • ingest the full session to the conversations endpoint for richer profile/graph updates
  • expose explicit tools for search, store, forget, and profile access

The session is written once via the conversations endpoint, which drives Supermemory's entity extraction and profile building while keeping a clean, retrievable full transcript.

Profile-Scoped Containers

Use {identity} in the container_tag to scope memories per Hermes profile:

{
  "container_tag": "hermes-{identity}"
}

For a profile named coder, this resolves to hermes-coder. The default profile resolves to hermes-default. Without {identity}, all profiles share the same container.

Multi-Container Mode

For advanced setups (e.g. OpenClaw-style multi-workspace), you can enable custom container tags so the agent can read/write across multiple named containers:

{
  "container_tag": "hermes",
  "enable_custom_container_tags": true,
  "custom_containers": ["project-alpha", "project-beta", "shared-knowledge"],
  "custom_container_instructions": "Use project-alpha for coding tasks, project-beta for research, and shared-knowledge for team-wide facts."
}

When enabled:

  • supermemory-search, supermemory-save, supermemory-forget, and supermemory-profile accept an optional container_tag parameter
  • The tag must be in the whitelist: primary container + custom_containers
  • Automatic operations (turn sync, prefetch, memory write mirroring, session ingest) always use the primary container only
  • Custom container instructions are injected into the system prompt

Support