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.
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 function — episodic / 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.”
Related
seekdb · memory-vault · zouroboros · durable-agents · self-improving-agents · openhuman · gbrain · agent-guardrails · agent-middleware · model-context-protocol