# Memory Search Tuning for Multi-Agent S - .rendrag

[arctic cedar]

Config (goes in agents.defaults.memorySearch):

{
  "enabled": true,
  "sources": ["memory", "sessions"],
  "extraPaths": [],
  "experimental": { "sessionMemory": true },
  "provider": "openai",
  "fallback": "local",
  "model": "text-embedding-3-small",
  "chunking": { "tokens": 300, "overlap": 100 },
  "sync": {
    "onSessionStart": true,
    "onSearch": true,
    "watch": true,
    "watchDebounceMs": 2000,
    "intervalMinutes": 3,
    "sessions": { "deltaBytes": 25000, "deltaMessages": 15 }
  },
  "query": {
    "maxResults": 8,
    "minScore": 0.15,
    "hybrid": {
      "enabled": true,
      "vectorWeight": 0.65,
      "textWeight": 0.35,
      "candidateMultiplier": 4,
      "mmr": { "enabled": true, "lambda": 0.65 },
      "temporalDecay": { "enabled": true, "halfLifeDays": 21 }
    }
  },
  "cache": { "enabled": true, "maxEntries": 500000 }
}

What I changed from defaults and why:

Chunks: 300 tokens, 100 overlap — Default 400/80 was returning chunks that mixed topics. 300 keeps each chunk focused on one idea, higher overlap so you don't lose context at boundaries. More chunks to embed but retrieval is noticeably more precise.

Session memory on — This is the big one. Without it agents only search curated memory/ files. With it, raw session transcripts are searchable — agents can recall conversations from days ago even if nobody explicitly saved anything. Session sync is incremental (25KB or 15 messages).

Hybrid 65/35 vector/text — Pure vector misses exact terms. Ticket IDs, agent names, specific commands — BM25 catches those where semantic search would rank them low. 4× candidate multiplier so the initial pool is wide before MMR narrows it down.

MMR lambda 0.65 — At 0.5 we were getting diverse-but-irrelevant results. 0.65 keeps the top results tightly on-topic while still avoiding near-duplicate chunks.

21-day temporal decay — Yesterday's decision should outrank the same topic from a month ago. 21 days felt right as a half-life — old stuff still surfaces, just doesn't dominate.

Watch debounce 2s — Slightly above default 1.5s. Reduces re-index churn when multiple agents write memory files at the same time (happens during bulletin responses).

Local fallback — If OpenAI embedding API goes down, search degrades to local rather than breaking.

Two gotchas we hit:

1. extraPaths duplicates at scale — If you use extraPaths to give agents shared docs access, each agent embeds those files into its own store. Same content embedded N times, every doc update triggers N re-indexes. We ended up removing it. Would love a shared vector store feature (posting separately).

2. Idle agents don't index — Sync only runs during active sessions. If an agent hasn't been woken up, its index is empty. Run openclaw memory index --force after adding agents or you'll wonder why memory_search returns nothing.

[manic sedge]

Appreciate the explanations and helpful information.

[brittle wharf]

Awesome work!

I also just merged a PR that uses gemini embeddings 2, I wonder if you could leverage it

[brittle wharf]

You should look int this @manic sedge

memorySearch: {
      provider: "gemini",
      model: "gemini-embedding-2-preview",
      extraPaths: ["assets/reference", "voice-notes"],
      multimodal: {
        enabled: true,
        modalities: ["image", "audio"], // or ["all"]
        maxFileBytes: 10000000
      },
      remote: {
        apiKey: "YOUR_GEMINI_API_KEY"
      }
    }

[wild drum]

Soo cool

This is memory core?

Not using qmd?

@brittle wharf difference with the new Gemini embedding and prior?

[brittle wharf]

It’s memory search with the newest embed model

[brittle wharf]

Main ones is different types of inputs

But it’s faster, bigger

It’s the colder goose lol

[brittle wharf]

I think I have an idea how to fix #1

[wild drum]

Damn I just moved default to qmd 2 days ago

Better do I move back ?

[wild drum]

On session memory

How I solved this a while ago is to auto prune session files of tool calls and index them in memory/sessions

So memory core picks them up automatically without the tool call noise which is mostly junky

[wild drum]

I guess if you are using same memory for 6 agents
They all live in same gateway?

Mine don’t I have 6 too

My current process is they all sync memory with each other using GitHub to a share memory folder that gets indexed

So they are know what I talked about with others

Then they also have access to an over 50k files qmd outside their own

This contains all my old notes and calls etc

So 3 memory levels of search fallback

1. Qmd
2. Memory search
3. Huge qmd

[arctic cedar]

@wild drum The fix I'm thinking about is a native sharedPaths config ... indexes once into a shared store, unions results at query time with each agent's own memory. The wiring's already mostly there in the memory subsystem, just needs the store to be shared instead of per-agent. Your GitHub sync approach is interesting though...how do you handle conflicts when two agents update the same file? Also...I have slow mode on my own subthread...so this is my last response for 6 hours lol . I'll do a pr if wanted

[brittle wharf]

I use local with a cloud memory system and it’s a ton better

[brittle wharf]

I would recommend a cloud memory solution that’s built for this type of stuff versus GitHub

[brittle wharf]

You can solve #1 by just keeping your data up to date with no conflicts

[wild drum]

Which one ?

[brittle wharf]

Mem0, I find it to be amazing but there’s free options

[past basin]

Wow, thank u guys. I got to learn much from this thread. ❤️