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 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."

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.

The managed pole — cloudflare-agent-memory

Every pole above is something you run. cloudflare-agent-memory (private beta, 2026-04-17; ingested 2026-08-22) is the first here that nobody self-hosts: extraction, verification, classification, embedding and synthesis all execute on cloudflare's network, and the agent gets back a five-verb API — ingest, remember, recall, list, forget — reached by Worker binding or REST. So the axis is no longer only weight; it now has a hosted/self-hosted dimension, and the two ends state opposite bets. Recall says memory should be plain markdown you own; Cloudflare says the constraint is the product — "tighter ingestion and retrieval pipelines are superior to giving agents raw filesystem access," better for temporal logic, supersession and instruction following.

It is also the most mechanically specified entry in this layer. Ingestion runs content-addressed message IDs (idempotent re-ingest), two parallel extraction passes, an eight-check verifier that passes/corrects/drops each memory, and classification into facts / events / instructions / tasks. Retrieval runs five channels in parallel — full-text, exact fact-key, raw-message safety net, direct vector, and HyDE — fused by Reciprocal Rank Fusion with fact-key matches weighted highest. Date arithmetic is computed by regex and injected as pre-computed fact, never asked of the model.

Two things it shares with iai-pme despite different vocabulary: staleness is handled by supersession, not deletion (a normalized topic key, a version chain, a forward pointer — where iai-pme surfaces the contradiction and bi-temporal graphs use validity intervals), and asynchronous reorganization is the stated roadmap, framed as sleep consolidation. Its four types are not Tulving's, though: facts/events/instructions/tasks is closer to a document taxonomy, and tasks are explicitly disposable — excluded from the vector index by design, a tier no other entry here has.

And it publishes no numbers. The post names LoCoMo, LongMemEval and BEAM, says scores improved each iteration, and reports none — so the layer's best-documented architecture is among its least-measured claims, while a much smaller project (iai-pme) prints LongMemEval-S R@10 0.978. It also does not settle beyond-pass-at-1: a gated, synthesized retrieval service is precisely the configuration that study did not test.

Consolidation ships — claude-dreams (2026-08-22)

Consolidation was, until today, one project's internal behaviour (iai-pme's nightly idle pass) and one vendor's roadmap sentence (cloudflare-agent-memory promising background improvement "similar to how the human brain consolidates memories by replaying… during sleep"). anthropic has shipped it as a billable endpoint and named it after the same metaphor: claude-dreams reads a memory store plus 1–100 past sessions and emits a new store with duplicates merged, contradicted entries replaced and patterns surfaced. Research preview, own beta header, pending → running → completed, minutes to hours.

Three properties make it a different kind of object from the poles above:

It never modifies its input. The output is a separate store you review and can discard — the copy-on-write instinct seekdb put in storage, applied to the consolidation step instead, and the direct answer to auto-company's one-rewritten-file risk.
It is a session you can watch. The dream's session_id streams events while it runs, and the transcript is archived rather than deleted. Every other consolidation here is invisible.
It is process without a store. Dreams holds no memory; it operates on memory something else holds and hands back an ordinary store. So consolidation becomes a separable stage rather than a property baked into the engine — the opposite of iai-pme (internal, scheduled) and of Cloudflare's plan (background, inside the service).

Nothing published shows a dreamed store retrieving better than its input; the docs put evaluation on the customer ("scale up once you're satisfied with the curation quality"). Two vendors converging on sleep as the model is the finding. The measurement gap is unchanged.

The first measurement, and it is negative (2026-08-21)

beyond-pass-at-1 is the corpus's first study to run a memory scaffold against a no-memory baseline with repeated runs. Over 23,392 episodes at k=3, the scaffold reduced long and very-long-horizon Graceful Degradation Score for 5 of 9 models, worst on the strongest (Llama 3.3 70B Δ = −0.13), with one model improving slightly. Its abstract claims the effect is universal across all ten; its body does not support that, and the body is what to cite.

The proposed mechanism is a budget argument rather than a memory argument: the scratchpad's extra tool calls and context injection "tax capable models' step budgets more than it benefits them." What is disconfirmed is naive episodic memory as a reliability intervention. Curated, retrieval-gated and summarized memory are untested here — but this page can no longer treat persistence as free.

Three scopes, and the project scope is the agent's (KOT, 2026-08-23)

KOT splits durable notes into project (.kot/agent-memory, committed with the repo), user (all projects on this machine) and local (this project, this machine), auto-loaded at every session start. The tiering matches claude-md's, with one difference worth keeping: the project tier is a directory the agent writes into, not a file a human curates. Shared-through-git memory becomes agent output that lands in review rather than human input the agent reads — the same move auto-company makes with its consensus file, now as a harness default. Stated design only; the repository ships binaries and no source, and there is no measurement.

Three tiers, one of them a logic store — omega-framework (2026-09-20)

Omega splits memory by what reads it: pin, a single volatile slot overwritten every cycle; remember / query, embeddings in ChromaDB that survive restarts; and the AtomSpace, where facts live as truth-valued atoms that the NAL/PLN engines reason over. The third tier is the new shape here — memory that is not retrieved into a prompt but computed over outside the model. The doc is also blunt about the first: working state kept in pin or /tmp is lost on restart, so "anything you need to keep across sessions must go through remember" — the same lesson the markdown-file pole learned the other way round. Memory export is off by default and import works only inside Docker.

The hosted/self-hosted axis splits from the app — company-brain (2026-09-28)

Every entry above ties one deploy decision to two things at once: who runs the agent and who runs its memory. company-brain separates them. The agent is self-hosted — a one-click deploy to the user's own Cloudflare account, Workers/Durable Objects/D1 all under the operator's control — but its memory is stored on supermemory, the vendor's own hosted service, reached with an API key like cloudflare-agent-memory's Worker binding. So "self-hosted" and "owns its memory" turn out to be independent choices, not one axis: an operator can run every other part of the stack themselves and still depend on a third party for the one thing recall and the markdown pole treat as the whole point of self-hosting. No architecture is documented on the supermemory side comparable to cloudflare-agent-memory's eight-check verifier or iai-pme's LongMemEval numbers — the maker's README states a 95% Recall@15 / ~720-token figure on its own docs site, not in this repo, and unverified here.

agentkot · seekdb · memory-vault · recall · cloudflare-agent-memory · claude-dreams · iai-pme · zouroboros · durable-agents · self-improving-agents · openhuman · gbrain · agent-guardrails · agent-middleware · model-context-protocol · omega-framework · company-brain · supermemory · agent-scope-isolation