Repository navigation
Description
Summary
consolidate_now over the MCP server can never take the FlashAttention consolidation path, so it reports episodesProcessed: 0 on every call and discovers no causal edges — regardless of how much episode data exists.
I understand ENABLE_FLASH_CONSOLIDATION is a deliberate feature flag defaulting to false (NightlyLearner.ts:17, :78). The issue isn't the default — it's that the MCP server provides no way to opt in, and the fallback is silent, so the tool looks like it succeeded.
Root cause
src/mcp/agentdb-mcp-server.ts:282 constructs the learner with no config argument:
const learner = new NightlyLearner(db, embeddingService);It therefore inherits the constructor default (NightlyLearner.ts:78) where ENABLE_FLASH_CONSOLIDATION: false. The AttentionService is only created when that flag is set (:88-89), so attentionService stays undefined and consolidateEpisodes() takes its fallback branch on every call (:213), returning episodesProcessed: 0.
The consequence is that the reward-delta discovery loop — the only code that converts episode outcomes into causal edges — is unreachable through the MCP surface.
Evidence
Environment: [email protected] (resolved via agentic-flow), MCP server started with agentdb mcp start, store with 2993 episodes across 2 sessions.
Before — every consolidate_now call, session-scoped or global:
{ "edgesDiscovered": 0, "episodesProcessed": 0, "experimentsCreated": 10,
"recommendations": ["No new causal edges discovered. Consider collecting more diverse episode data.", ...] }SELECT COUNT(*) FROM causal_edges → 0.
The recommendation points at the data, which sent me looking in the wrong place for a while — the data was never read.
After — same database, same episodes, learner constructed identically except for the flag:
new NightlyLearner(db, embedder, { ...defaults, ENABLE_FLASH_CONSOLIDATION: true })attentionService present: true
episodesProcessed: 1000
causal_edges: 0 -> 94
Verified by direct SQL rather than the tool's own report:
| check | result |
|---|---|
mechanism |
flash_attention_consolidation on all 94 |
uplift |
signed, −0.35 … +0.35 |
|uplift| >= 0.05 |
94 / 94 |
PRAGMA integrity_check |
ok |
Suggested fix
Pass a config at the construction site, ideally with an env opt-in so operators can enable it without a code change:
const learner = new NightlyLearner(db, embeddingService, {
ENABLE_FLASH_CONSOLIDATION: process.env.AGENTDB_FLASH_CONSOLIDATION === '1',
});Two smaller observations, take or leave
The fallback is silent. episodesProcessed: 0 is indistinguishable from "there was nothing to process". Since the fallback is a real capability difference, it may be worth surfacing it in the report — e.g. mode: "fallback" or a note that flash consolidation is disabled. That one line would have saved me most of the investigation.
A downstream call site overrides the threshold. agentic-flow's dist/reasoningbank/AdvancedMemory.js:39 constructs NightlyLearner with upliftThreshold: 0.1, double the library default of 0.05 (NightlyLearner.ts config default). In my corpus, 12 of the 94 edges clear 0.05 but not 0.1. Not an agentdb bug — flagging it in case the divergence is unintentional.
Thanks for agentdb — the causal-edge model is genuinely useful, and once the path actually runs it produces exactly the signed-uplift structure the docs describe. Happy to open a PR for the one-line change if that's helpful.
Activity
Jordi-Izquierdo-DDS commentedon Aug 7, 2026
Verified end-to-end against the running MCP server, not just a side script — the earlier numbers came from constructing the learner in a separate process, which proves the mechanism but not the fix.
Applied the proposed change to the installed
agentdb-mcp-server.js(the exact line above), restarted the server withAGENTDB_FLASH_CONSOLIDATION=1, and deleted every existing causal edge first so the result could not come from stale data.Preconditions:
Same
consolidate_nowMCP call that previously returnedepisodesProcessed: 0on every invocation:{ "edgesDiscovered": 69, "episodesProcessed": 72, "metrics": { "computeTimeMs": 157, "peakMemoryMB": 0.125, "blocksProcessed": 1 } }Confirmed by direct SQL:
Two details worth noting for whoever picks this up:
metricsblock (computeTimeMs/peakMemoryMB/blocksProcessed) only appears on the flash path, so its presence/absence is itself a reliable signal of which branch ran — possibly a cheaper fix for the silent-fallback point than adding amodefield.similaritysaturates at 1.0 on all 69 edges andconfidenceis assigned fromsimilarity, so confidence isn't independent evidence here. My episodes are "same route, different outcome" pairs with near-identical task text, which is a favourable case; a more varied corpus would exercise the similarity threshold properly.I've reverted the patch locally — it was for verification, and
npm iwould overwrite it anyway. Happy to open the PR for the one-line change with the env opt-in if useful.