Spokes.wiki Search About
Defined Term mechanism updated Tue Jul 28 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Agent memory / state store

The persistent substrate an agent reads and writes as it runs — its accumulated facts, past interactions, working state, and retrievable knowledge — kept across turns, sessions, and (for long-runners) process restarts. It is the storage layer beneath the spoke’s autonomy threads, distinct from the harness logic that uses it.

Why it’s a layer of its own

Memory is the recurring implicit dependency under several existing threads, never before named as its own node:

  • durable-agents separate workflow state from conversation history so an agent can pause/crash/resume — that state has to live somewhere durable.
  • self-improving-agents accumulate memory (and self-authored skills) over time — the “growth” axis is memory that compounds.
  • openhuman ships a local SQLite “Memory Tree + Obsidian wiki” as the agent’s memory; gbrain (cross-wiki) is a personal knowledge base used as agent memory.
  • The retrieval side is the spoke’s RAG/hybrid-retrieval adjacency (research-wiki), reached via the gbrain bridge.

The minimal pole — one markdown file

The layer has a floor as well as a ceiling. auto-company runs a 24/7 multi-agent loop whose only cross-cycle state is memories/consensus.md, a single markdown file read at the start of each cycle and rewritten before it ends — explicitly “forgoing complex vector databases or memory management.” Every cycle is an independent CLI call, so that file is the whole continuity mechanism.

It buys one thing the database pole can’t: the human steers by editing a line (“Next Action”) and the next cycle pivots — memory as a shared file interface, the claude-md logic applied to runtime state. It pays for it in history: a rewrite has no prior version, so a bad cycle can overwrite the thread of work (the repo’s rollback-on-invalid-consensus guard concedes the risk). Neither pole has been measured against the other; the range between one markdown file and seekdb‘s forkable hybrid store is currently unpriced.

So “agent memory” spans two faces: state (mutable working/workflow state) and knowledge (retrievable facts, often vector + full-text indexed). Production systems increasingly want both in one store. zouroboros is a harness-side instance: it layers memory by functionepisodic / procedural / cognitive — over SQLite + vector embeddings, showing the same store carrying both faces, sliced by kind of memory rather than by storage engine.

The infrastructure instance — seekdb

seekdb is the first time this layer appears in the wiki as a standalone database product, not a feature inside a harness: an Apache-2.0 store that is MySQL-compatible, does hybrid vector + full-text search, makes fresh writes immediately retrievable (async index pipeline + two-level HNSW), and adds copy-on-write FORK/MERGE sandboxes so agent state can be branched, explored, and merged/rolled back — version-controlled state rather than a single mutable blob. That branching is the storage-level expression of the reversibility/exploration discipline named in agent-guardrails.

The lightweight instance — memory-vault

memory-vault is the second standalone instance of this layer, and it marks the other end of the weight spectrum from seekdb. It is a small open-source MCP server: stock Postgres + pgvector doing hybrid vector + keyword search, deployed with docker compose up, and — the distinguishing move — handed to the harness over the MCP rather than queried as a database. Its target is concrete: it externalizes the context Claude Code would otherwise lose to lossy auto-compaction, so memory survives /clear, new sessions, and a change of machine. So the layer now has two market poles — a full-featured DB with branch/merge state (seekdb) and a thin MCP-wired store (memory-vault) — and a recurring delivery pattern: the memory store reaches the agent as a tool, the storage-layer reading of “skills × MCP = agency.”

The minimal pole — recall

recall extends the spectrum to its most minimal, local-first end and breaks the MCP delivery pattern: it’s a Claude Code plugin that stores memory as plain markdown files (.recall/history.md + context.md), fired from SessionStart/Stop hooks rather than handed over MCP, and summarizes with a deterministic TF-IDF/TextRank extractor — no embeddings, no LLM, no database, fully offline. It targets the same Claude Code amnesia memory-vault does (lost context across sessions//clear), but trades semantic retrieval for zero dependencies/cost and total locality. So the three poles now read as a clean axis — DB (seekdb) → pgvector-over-MCP (memory-vault) → markdown-files-over-hooks (recall) — and recall’s “memory as committable markdown you own” is the markdown-you-own ethos applied to session memory (the research-wiki gbrain/llm-wiki rhyme).

A second axis — store versus process (iai-pme)

The three poles above vary by weight (database → pgvector-over-MCP → markdown-over-hooks) and they are all the same kind of thing: a store you write to and search. iai-pme varies on a different axis, modelling memory as processes and taking its structure from human memory research — episodic (verbatim, write-once), semantic (summaries induced from episodes during idle consolidation), procedural (learned stable parameters about the user), deliberately kept in separate representations so detail, gist and habit don’t collapse together.

Three behaviours follow that no store here has. Consolidation: the memory reorganizes itself nightly when nothing is asking it anything. Decay: unreinforced links fade on a schedule, with pinning to resist it — the layer’s first design that treats forgetting as a feature rather than a bug. Contradiction surfacing: recall returns the conflicts alongside the matches, so a superseded fact loses out in the open (the staleness problem bi-temporal graphs answer with validity intervals, answered here by handing the conflict to the model).

It’s also the first instance in this layer to publish numbers on a named public benchmark (LongMemEval-S R@10 0.978, and ~350 retrieval tokens against ~2,850 for agent search) rather than asserting that it works. Author-run, so not independent, but a rung above the rest.

seekdb · memory-vault · recall · iai-pme · zouroboros · durable-agents · self-improving-agents · openhuman · gbrain · agent-guardrails · agent-middleware · model-context-protocol