English | 中文

interest-memory — Long-term memory for AI agents

One ~50MB process instead of a Postgres + Redis + vector DB stack.

Agents forget everything between sessions. Not the model's fault — they lack a real memory layer. interest-memory is a standalone memory backend: at the end of a session it extracts interest points from the transcript, verifies and cleans them, and writes them into a local knowledge base; at the start of the next session it recalls and injects relevant context. The entire footprint: one 18MB binary + one SQLite file. The unit of memory is the interest point: semantically similar ones are merged automatically, and each one is written into the knowledge base as a wiki page by an LLM-driven agent loop — the knowledge base converges with use instead of bloating.

Quick start

One-command install (curl)

curl -fsSL https://raw.githubusercontent.com/djasdh/interest-memory/main/scripts/install.sh | bash

Auto-fetches the source → checks/installs dependencies → guides setup → optional systemd.

Configure the LLM (let your agent fetch and run it)

curl -fsSL https://raw.githubusercontent.com/djasdh/interest-memory/main/scripts/install_llm.py | python3 - --provider <provider>
# --help lists all providers; hand to your agent: it reads --help (its operating instructions) and configures itself

Pre-built binary (optional): Release v0.1.0 (linux / mac / windows)

Resource usage (measured)

session_transcripts keeps full raw text — trim externally to bound disk growth; fork.max_concurrency / verify.max_concurrency cap peak memory.

Integration

Multiple agent frameworks are supported out of the box, sharing one env set (INTEREST_BASE_URL / INTEREST_AGENT / INTEREST_TIMEOUT); a down service never blocks a session:

Every bridge offers the same capabilities: session-start recall injection, session-end transcript push, and memory_search / memory_logs consumer tools. See bridge/README.md.

Architecture

internal/store/      SQLite (interest points/wiki pages/edges/claims/transcripts/change_log)
internal/vec/        sqlite-vec vector index (FTS fallback)
internal/llm/        OpenAI-compatible Chat/Embedding
internal/fork/       sliding-window split + parallel candidate extraction
internal/verify/     3-stage verification (check/claims/contradictions)
internal/wiki/       per-point agent-loop writer + related-page reconciliation
internal/recall/     recall injection + structured queries
bridge/hermes/       Hermes MemoryProvider plugin

Docs

• REST API — POST /api/v1/{agent}/sessions, GET /api/v1/{agent}/recall, search / logs / stats / jobs (table below)
• Config — fully commented config.example.yaml (llm / embedding / fork / verify / wiki / recall / namespaces / interestmemory.kanban_exclude)
• Development — CGO_ENABLED=1 go test -race ./...; plugin tests node --test bridge/...; e2e bash scripts/e2e.sh

API quick reference

Namespaces

Each agent ({agent} path segment / INTEREST_AGENT) has an isolated namespace; cross-namespace reads are configured via namespaces:

namespaces:
  mode: isolated   # isolated (default) | all | custom
  visible_to:      # custom only: one-way visibility declarations
    codex: [opencode, pi]

Shared results are annotated with origin ([from: <agent>] on recall lines, result.agent in search/get).

Kanban board exclusion

Kanban worker sessions push their full transcripts into memory. To keep certain boards (internal projects, transient orchestration cards, …) out of the memory base, list them in interestmemory.kanban_exclude — they are dropped at the ingest boundary: not stored, not embedded, not token-accounted.

interestmemory:
  kanban_exclude: ["default", "t_90c0c7ab"]   # exclude by board name or ID

Dependencies

my-agent-core, mattn/go-sqlite3 (cgo static), sqlite-vec, goldmark-obsidian (wikilinks). All MIT-compatible.

License

MIT — Contributions are welcome whether written by a human or an AI — quality is what counts.