Summary

QMD-backed memory search currently fans out one qmd search/qmd query subprocess per managed collection when more than one collection is configured. For agents with many QMD memory collections, a single memory_search tool call can spend most of its latency serially starting QMD processes.

This is especially visible in realtime lanes such as Google Meet/Gemini Live owner-consult flows: the live model waits while the owner agent executes memory tools, so one user question can appear to stall for a long time.

Observed behavior

On an OpenClaw 2026.4.24 runtime with Jay configured for QMD memory:

• memory backend: qmd
• memory source: memory
• QMD collections exposed in status: 11
• query: openclaw memory search --agent jay "most recent OpenClaw PR" --max-results 1 --json
• before patch: 14.578s total

Trajectory evidence from a Google Meet consult showed four memory_search tool calls in one answer, each taking roughly 16-18 seconds end to end. That made the voice lane appear unresponsive even though the consult eventually succeeded.

Expected behavior

When all selected collections belong to the same OpenClaw memory source, OpenClaw can pass all collection filters to one QMD invocation:

qmd search "..." --json -n <limit> -c collection-a -c collection-b ...

For mixed memory/session searches, OpenClaw should still avoid session results crowding out memory hits before its existing source-diversification step. A good compromise is one QMD invocation per source group, not one per collection.

Runtime validation

A local runtime patch applying source-grouped collection filters reduced the same Jay search from:

• before: 14.578s total
• after run 1: 7.261s total
• after run 2: 5.637s total

This does not make QMD instant, but it removes the serial per-collection subprocess fanout for common single-source searches.