---
id: memory/understand-and-centralize-agent-memory-into-a
title: 'Understand how Claude and opencode do memory, then centralize both into one vector database'
theme: memory
status: open
created: 2026-08-25
date_source: stated
order: 1
---

**Understand how Claude and opencode do memory, then centralize both into one vector database.** Wanted
2026-08-25. Two steps in order, and the second should not be started before the first is actually
answered rather than assumed:

1. **Understand what "memory" means for each harness, as it exists today.** For Claude that is this
   platform's own memory system (`~/.claude/projects/*/memory/`, `MEMORY.md` plus per-topic files — the
   mechanism this very session uses) and whatever `CLAUDE.md` files and file-based conventions the SDK
   itself reads. For opencode — wired into this platform (`sidecar/opencode/`) but not deeply understood
   by this session — the equivalent needs the same audit: where does it read and write anything durable
   about a session or a user, and does it call that memory at all or something else entirely.

2. **Centralize into one vector database**, so both harnesses (and whatever joins later) read and write
   the same store instead of each keeping its own files. **Needs an affordance per harness**, teaching it
   NOT to use its native memory mechanism and to use the shared store instead — the same delivery
   mechanism already used to teach Claude sessions about image rendering and gitea
   (`capabilities/affordances/`, loaded per turn, no restart).

Open, deliberately not decided here: which vector database; what gets embedded (raw notes, summaries,
both); whether centralization REPLACES each harness's native memory outright or sits ahead of it as a
retrieval layer the harness is told to consult first; and how a memory tied to one user account maps
onto a store meant to serve every harness the same account uses. Step 1 should surface most of these —
this is exploratory before it is a build.