Do you think Mikhail or Milla or Ben have their own research on the matter? Cus what you are doing is super interesting, and I would hope that every piece of extra research can be turned into a public Obsidian vault for checking (from retrieval method taxonomy to companions to agent scaffolds to higher-order paradigms)
P.S. Would be amped if you can join in anomalyco/opencode#8554 anomalyco/opencode#11829 code-yeongyu/oh-my-openagent#1397

Thanks @TomLucidor 😊. From what's visible from outside: bensig (Ben), milla-jovovich (Milla), and igorls — all three actively produce design writing: Milla's announcements like #868 "Post Launch Insanity" and #1388 are essentially design narrative; Ben's release notes and technical articles, and Igor's careful PR write-ups (he often surfaces architectural reasoning in extraction commentary) are themselves the research thread you're asking about. There's more output than the GitHub surface alone shows — articles, threads on adjacent platforms, etc. arnoldwender does heavy PR triage too.

The active fork-contributor community is much broader than I'd implied in my earlier draft — there's really an ecosystem here. A non-exhaustive list of folks shipping substantive work: @skuznetsov on the pgvector backend #665; @zhapostolski on search hardening + decay + community patches #1335 + #1425; @kostadis on hierarchical AAAK pruning and RPG-content workloads; @fatkobra on HNSW integrity + Windows compat + entity-registry; @mvalentsev on KG cache, bash compat, hooks reliability; @rusel95 on miner + hooks features (5 open PRs); @mjc on repair/recovery hardening; @dergachoff on quarantine refinements; @MohamedAbdallah-14 on the sqlite_vec backend + macOS/ARM64 stability; @brodheadw on wing-level access control; @lukewp on Claude-desktop session integration; @fuzzymoomoo on the cdd-mempalace methodology bridge; @rboarescu on palace-daemon (the HTTP gateway downstream consumers depend on); @midweste on batched mining inserts; @nakata-app on encoder fine-tuning (adaptmem); @kenchambers on Kent + agent-lightning training; @NickCirv on engram. Plus many I'm undoubtedly skipping. PRs and Discussions are where most design conversation happens — this discussion is itself an artifact of that pattern.

The "public Obsidian vault for checking" framing is interesting though, because what you're describing as missing is a single centralized surface — and that surface doesn't exist (yet). The fork's docs/research/ directory is the closest I've come to that pattern personally: 7 files (chunking-strategy-ablation, adaptmem-orthogonal-layers, two compass_artifacts, kostadis-comparison, three-mempalace-consumers, three-patterns-for-agent-memory) plus spec/plan files in docs/superpowers/. The README pivots toward a four-layer model (storage / encoder / retrieval / consumption) that's been useful for keeping different lines of work separable. A community-aggregated vault that pulls all the maintainer + contributor research into one navigable place is a real gap worth filling — open to ideas on shape.

On the opencode + oh-my-openagent issues — those are squarely on the jphein/mempalace roadmap. The fork's "What's next" section calls out first-class support across the AI coding agent ecosystem (Claude Code, OpenCode, Cursor, Aider, Gemini CLI, Codex CLI, Warp, and adjacent) — the integration path goes through upstream's RFC 002 source-adapter spec (#990, tracking #989). Today's integration is Claude-Code-specific (Stop / PreCompact hooks reading ~/.claude/projects/*.jsonl and mining via palace-daemon); the model going forward is each new agent ships a pip install mempalace-source-<agent> package mapping its session format onto the canonical drawer shape — read stays universal, mine is per-agent, hook/event wiring lands wherever the host exposes a hook surface. Will take a look at those opencode + oh-my-openagent issues — thanks for the pointer.

The mempalace-as-substrate-for-other-tools pattern is real and growing: familiar.realm.watch is mine; engram, cdd-mempalace, Kent, CampaignGenerator, Tiro, GraphPalace, mempalace-viz all consume the same canonical drawers via BaseBackend or palace-daemon HTTP — broader agent-host integration is the natural next step.

I have this weird idea on viewing different systems of memory (might need some better breakdown), and how different methods might be useful in different contexts as a context triangle (similar to the compute-latency-accuracy triangle) anomalyco/opencode#23628 (comment)