Opt-in MCP conversation store as a second memory backend beside builtin BM25 #237

New issue

Closed

opened 2026-08-23 12:39:07 +00:00 by john · 1 comment

john commented

2026-08-23 12:39:07 +00:00

Owner

The idea

Allow an MCP-backed conversation store (Verbatim, or any equivalent) as an
opt-in memory backend beside the builtin BM25 recall.

Always opt-in. Never a default, never a replacement for the builtin corpus.

Why it is interesting

The two corpora are additive, not competitors.

planning.mjs recall is BM25 over .planning/ artifacts, so it can only ever
return what a gate already wrote down: CONTEXT decisions, SUMMARY deviations,
CAPTURE rows. A conversation store indexes turns, which is where the reasoning
that never reached a numbered decision actually lives. That material is
currently lost at the end of every session.

The blocker, and it is architectural

memory.backend gates cmdRecall inside cadence-core/bin/planning.mjs
(see planning.mjs:2206-2235), which is a zero-dep Node subprocess. MCP tools
are reachable only from the model's tool-call loop. A seam script cannot call
one.

So memory.backend: verbatim cannot be implemented where none and builtin
live. It would require:

lifting the backend switch out of the seam and into workflow prose, and
a second, model-side recall path beside the seam call at all three consumers
(cad-context, cad-plan, cad-debug).

That is an architectural change, not a new config value. This is the main thing
to decide before any code.

The tension to settle first

PROJECT.md's Core Value states that what Cadence writes down comes back
"without any external memory system."

An opt-in backend is defensible, but it contradicts that sentence as written.
Whichever way this goes, it should be a stated decision, not a drift. If the
answer is yes, the Core Value line needs rewording in the same change.

What is already in our favor

v3.6.0 phase 2's D-03 makes the citation count backend-agnostic by
accident. The surfaced set reaches the counting seam as a payload file holding
whatever envelope the plan-time call returned, and the count never re-runs
recall itself. So a Verbatim-sourced set would be measured identically, and the
determinism criterion still holds because the count reads a fixed file.

Whatever backend work happens later, the read-back gate does not have to change
for it.

Open questions

Is an external memory backend compatible with the Core Value, or does the
Core Value change?
Is lifting the backend switch out of the seam worth it for one optional
backend, given every seam in this tree is deliberately zero-dep?
What happens to recall determinism when the corpus is a service rather than
files on disk? The count is insulated, but cad-context and cad-debug
are not.

Raised while v3.6.0 phase 2 was planning. Candidate for v3.6.1 at the
earliest, and only after this discussion resolves.

## The idea Allow an MCP-backed conversation store (Verbatim, or any equivalent) as an **opt-in** memory backend beside the builtin BM25 recall. **Always opt-in. Never a default, never a replacement for the builtin corpus.** ## Why it is interesting The two corpora are additive, not competitors. `planning.mjs recall` is BM25 over `.planning/` artifacts, so it can only ever return what a gate already wrote down: CONTEXT decisions, SUMMARY deviations, CAPTURE rows. A conversation store indexes turns, which is where the reasoning that never reached a numbered decision actually lives. That material is currently lost at the end of every session. ## The blocker, and it is architectural `memory.backend` gates `cmdRecall` **inside** `cadence-core/bin/planning.mjs` (see `planning.mjs:2206-2235`), which is a zero-dep Node subprocess. MCP tools are reachable only from the model's tool-call loop. A seam script cannot call one. So `memory.backend: verbatim` cannot be implemented where `none` and `builtin` live. It would require: - lifting the backend switch out of the seam and into workflow prose, and - a second, model-side recall path beside the seam call at all three consumers (`cad-context`, `cad-plan`, `cad-debug`). That is an architectural change, not a new config value. This is the main thing to decide before any code. ## The tension to settle first `PROJECT.md`'s Core Value states that what Cadence writes down comes back "without any external memory system." An opt-in backend is defensible, but it contradicts that sentence as written. Whichever way this goes, it should be a stated decision, not a drift. If the answer is yes, the Core Value line needs rewording in the same change. ## What is already in our favor `v3.6.0` phase 2's `D-03` makes the citation count backend-agnostic by accident. The surfaced set reaches the counting seam as a payload file holding whatever envelope the plan-time call returned, and the count never re-runs recall itself. So a Verbatim-sourced set would be measured identically, and the determinism criterion still holds because the count reads a fixed file. Whatever backend work happens later, the read-back gate does not have to change for it. ## Open questions 1. Is an external memory backend compatible with the Core Value, or does the Core Value change? 2. Is lifting the backend switch out of the seam worth it for one optional backend, given every seam in this tree is deliberately zero-dep? 3. What happens to recall determinism when the corpus is a service rather than files on disk? The count is insulated, but `cad-context` and `cad-debug` are not. Raised while `v3.6.0` phase 2 was planning. Candidate for `v3.6.1` at the earliest, and only after this discussion resolves.

john added the

needs-decision

proposal

labels

2026-08-23 12:39:07 +00:00

john commented

2026-08-23 18:34:51 +00:00

Author

Owner

Closing as not doing. The idea is interesting and the cost is the answer: it adds weight.

The blocker this issue names is the whole objection. memory.backend gates cmdRecall inside planning.mjs, a zero-dep Node subprocess, and MCP tools do not reach there. Getting them there means either a dependency in the seam layer or a second recall path that lives outside it, and both buy the same thing: a backend that can be absent, misconfigured, or slow, sitting under a Core Value that currently has no runtime dependency at all.

v3.6.0 just spent a cycle proving the builtin corpus is read rather than only written. That is the direction with the evidence behind it. Reopen this if the builtin corpus turns out to be missing material that matters, measured rather than suspected.

Closing as not doing. The idea is interesting and the cost is the answer: it adds weight. The blocker this issue names is the whole objection. memory.backend gates cmdRecall inside planning.mjs, a zero-dep Node subprocess, and MCP tools do not reach there. Getting them there means either a dependency in the seam layer or a second recall path that lives outside it, and both buy the same thing: a backend that can be absent, misconfigured, or slow, sitting under a Core Value that currently has no runtime dependency at all. v3.6.0 just spent a cycle proving the builtin corpus is read rather than only written. That is the direction with the evidence behind it. Reopen this if the builtin corpus turns out to be missing material that matters, measured rather than suspected.

john closed this issue

2026-08-23 18:34:52 +00:00

john added this to the v3.6.0 milestone

2026-08-23 20:50:27 +00:00