Summary

The Active Memory plugin's embedded runner appears to fail to register/expose plugin-provided tools (specifically memory_recall) when the AM hidden runner is configured to use a DeepSeek-provider model, even when:

• The plugin (memory-lancedb bundled) is loaded and the tool IS registered for normal-chat invocation
• active-memory.config.toolsAllow = ["memory_recall"] is explicit
• AM correctly resolves to the DeepSeek provider (activeProvider=deepseek activeModel=deepseek-v4-flash confirmed in journal)
• DeepSeek is independently verified tool-capable via direct provider canary

The failure surfaces as the well-known but ambiguous "No callable tools remain after resolving explicit tool allowlist (runtime toolsAllow: memory_recall); no registered tools matched" error — same wording as #82977's third-party-plugin scenarios, but different mechanism.

Environment

• OpenClaw 2026.5.18 (commit 50a2481)
• Plugin: bundled @openclaw/memory-lancedb (in plugins.slots.memory)
• Active Memory: enabled, config.toolsAllow=["memory_recall"], timeoutMs=30000
• DeepSeek provider: api.deepseek.com via API key, profile deepseek:default, model registered + reachable

Repro

1. Working baseline: set active-memory.config.model = openai-codex/gpt-5.5 (or openai/gpt-5.5). AM completes status=ok or status=no_relevant_memory consistently.
2. Verify DeepSeek tool capability via direct provider call (NOT via AM): deepseek/deepseek-v4-flash completes a tool-call canary status=ok in ~15.5s. (We tested with a session_status tool call.)
3. Patch active-memory.config.model = deepseek/deepseek-v4-flash. Restart gateway.
4. Trigger a real-inbound AM canary.

Expected: AM completes with activeProvider=deepseek activeModel=deepseek-v4-flash status=ok|no_relevant_memory.

Actual: AM routes correctly (activeProvider=deepseek activeModel=deepseek-v4-flash confirmed) but completes with:

[agent/embedded] [tools] No callable tools remain after resolving explicit tool allowlist (runtime toolsAllow: memory_recall); no registered tools matched.
...
[plugins] active-memory: ... done status=unavailable elapsedMs=10643

Why this is distinct from #82977 / #78907

#82977 frames this as a third-party-memory-plugin issue (i.e. memory-lancedb-pro). Here we hit it with the BUNDLED memory-lancedb plugin — only the AM-internal hidden-runner provider was changed. Same plugin, same explicit allowlist, same slot. The failure is provider-bridge-specific, not plugin-specific.

Also distinct from "model too small to emit tool call" (the failure mode for ollama/llama3.2:1b) — DeepSeek-v4-flash is frontier-class and proven tool-capable in the same install via direct canary.

Suggested investigation

Compare the embedded-runner tool-registration code path between:

• openai-codex provider (works — AM finds memory_recall in registry)
• openai provider (works — AM finds memory_recall in registry)
• deepseek provider (fails — AM does NOT find memory_recall in registry, despite correct provider resolution)
• ollama provider (untested as AM runner — would be useful data point)

Likely the embedded-runner tool-discovery path is provider-conditional in a way that misses the DeepSeek provider's runtime context.

Related

• Active-memory plugin incompatible with third-party memory plugins — tied to stock memory-core only #82977 (Active-memory plugin incompatible with third-party memory plugins — parent class)
• [Bug]: Embedded direct lane fails to materialize allowlisted plugin tool #78907 (Embedded direct lane fails to materialize allowlisted plugin tool)
• [Bug]: Breaking change: api.registerTool() silently fails without contracts.tools since 2026.5.2 #77800 (registerTool rejected without contracts.tools since 2026.5.2)

Evidence available

Full canary report + journal extracts at governance/reports/memory-tests/am-deepseek-hidden-runner-20260519T0754Z.md on our deployment if maintainers want raw data.