@geco — this is a great pattern, and the read-side bit "Model searches MemPalace via MCP before answering (guided by AGENTS.md)" is the place we have empirical data worth sharing.

We've been measuring exactly this — how often agent harnesses actually invoke mempalace_search when instructed via system-prompt/AGENTS.md-style guidance — on the SME framework's Cat 9a thread (M0nkeyFl0wer/multipass-structural-memory-eval#3). One finding bears directly on your plugin's effectiveness:

Same retrieval substrate, same instructions, same task: orchestrator-LLM choice determines invocation rate. On a 30-question Cat-9a-shaped diagnostic at fixed 4B parameter count:

Same wrapper, same backend palace, same questions. The gap (30pp recall) is almost entirely an invocation-rate gap — gemma4 answers from prior knowledge on 60% of questions even when instructed to use the memory tool; qwen3.5 invokes 87% of the time. This matches the published Tau2 tool-use benchmark gap (37.7 pts in qwen's favor) almost exactly on an independent corpus.

Practical implications for OpenCode + MemPalace integration:

1. Document a "minimum recommended orchestrator" in the plugin's README. Users running the plugin with low-tool-use-discipline local models will see most questions answered from priors regardless of how AGENTS.md is structured. Qwen 3.5 4B or above is the floor for reliable read-side invocation in our measurements; smaller / older models hit ~60% zero-call.

2. System-prompt augmentation can recover some of the gap. We tested prepending a mandatory mempalace_search directive at the system-prompt layer (one constructor kwarg in our RlmAdapter: invocation_mode="forced"). On gemma4:e4b the directive lifted n=5 recall from 0.417 → 0.567 (+15pp). Worth considering: a plugin-level config flag that injects an invocation-forcing prefix into the model's system prompt, on top of AGENTS.md guidance. Belt-and-suspenders.

3. The KG-extraction write side is more model-tolerant than the search read side. Our gemma4 numbers above are read-side only; on write-side classification tasks (wings, hall keywords) most 4B models converge to similar accuracy. So the plugin's write loop is sturdier across model choices than the read loop.

We're running Step 2 (forced + grounded invocation experiments ×ばつ n=200 expanded corpus) on katana right now; full numbers will land on the SME #3 thread today/tomorrow. Happy to cross-link once they settle.

Three weeks of operator experience on an adjacent pattern (palace-daemon HTTP gateway + RLM-orchestrated reads against the same techempower-org/mempalace backend you're targeting — not your plugin, but the same read-side question) says the model-choice axis is the single biggest variable for read-side memory effectiveness — bigger than embedding model, bigger than rerank, bigger than wing/room structure. AGENTS.md gets you most of the way; the rest is base-model tool-use training.

🫏

Quick follow-up worth surfacing for anyone landing on this thread: there's a complementary write-side path to geco's plugin already in flight upstream — MemPalace/mempalace#1484 — feat(sources): OpenCode adapter on RFC 002 contract (reviewed by @igorls on 2026年05月13日, awaiting final merge). The two solve the same OpenCode→MemPalace problem space from opposite directions:

Complementary rather than competing — the plugin captures new sessions in real-time; the adapter ingests historical sessions. Anyone running OpenCode + MemPalace who wants both retroactive and forward-going coverage can install the plugin AND run mempalace mine --source opencode once #1484 lands.

If geco's plugin and the RFC 002 adapter end up in the same release window, worth a section in the user-facing docs that walks through "install plugin for live capture, run source-mine once for backfill, never think about it again." Closes the OpenCode integration loop end-to-end.

🫏