Say when a saved memory becomes searchable

[gloryfromca]

Summary

add_memory(wait=true) replied "Stored and extracted; the memory is now searchable." Extraction finishing and the memory becoming searchable are two steps, and on a self-hosted EverOS the index catches up about half a second after the write. Verified on 2026-10-10 against a local everos server start (everos 1.4.1): a search_memory call issued right after that reply returned nothing; the same query a second later found the memory, and the server log shows the cascade indexing the new episode ~0.5 s after /memory/flush returned.

This changes only wording:

• the wait=true reply now says the memory is searchable once the index catches up, usually within a second;
• the add_memory docstring says the same for the wait=true branch;
• README: the tool table no longer says wait=true blocks "until it is searchable", and Good to know gains a bullet about the two steps and list_memories showing new entries sooner.

Tests assert on the stable prefix Stored and extracted instead of now searchable.

Verification

uv sync --dev --locked
uv run ruff check .      # OK
uv run pytest -q         # all tests pass

🤖 Generated with Claude Code

[dani1005]

Thanks for tracking this down. The measurement is convincing: wait=true currently claims more than it delivers, and making the wording honest is the right first step.

The catch is that rewording alone leaves the tool contract self-contradictory (see inline). The docstring still tells the model to use wait=true when it must search right away, which is exactly the case this PR shows still fails.

Suggested direction. Make wait=true actually wait for searchability. In Conversation.store, after the flush, poll briefly until the new entry is visible, or use a server-side option that waits for indexing if the API has one. Then "now searchable" is true again and the docs need no hedging. If you'd rather land the wording first, please at least:

1. Drop "only when you must search for it right away" from the add_memory docstring.
2. Use one latency statement everywhere. search_memory's docstring and its empty-result note say "saved in the last minute may not be indexed yet"; this PR says "usually within a second"; the background path says "a few seconds later" / "shortly".
3. Update Conversation.store's docstring (conversation.py:111), which still says "extracted" means searchable.

Then follow up with the real fix in a separate PR.

Note: EverMind-AI/EverOS#484 repeats the "about a second" claim in docs/mcp.md, so it's worth landing the two consistently.

[dani1005]

This sentence still tells the model to use wait=true when it must search right away, but the PR's own finding is that wait=true doesn't make the memory searchable right away. A model that follows the docstring calls search_memory immediately, lands inside the index lag, gets "No relevant memories found", and may tell the user the save failed. Either make wait=true wait for indexing (preferred), or drop "only when you must search for it right away".

[dani1005]

Two things on this line:

• Latency figure. "usually within a second" comes from one self-hosted measurement. Meanwhile search_memory (docstring and empty-result note) says memories from "the last minute" may not be indexed yet. On Cloud or a loaded server the model may trust "a second", retry once, and give up. Please pick one conservative statement and use it everywhere.
• Line length. This line is 102 characters, over line-length = 100 in pyproject.toml. CI doesn't catch it because E501 isn't enabled. Splitting it into two adjacent literals, like the reply just below, fixes it.

[dani1005]

With only the stable prefix asserted, nothing guards the wording this PR fixes. If "now searchable" comes back later, all three updated assertions still pass. Maybe add assert "now searchable" not in reply here (and at 750 / 841).

[gloryfromca]

Thanks for the careful read. Pushed a follow-up commit:

• Docstring: dropped "only when you must search for it right away". wait=true is now described as "block until extraction has finished", and the docstring carries the same statement as search_memory: memories saved in the last minute may not be indexed yet; list_memories shows them sooner.
• Reply: the wait=true reply uses that same sentence instead of "usually within a second"; the README bullet too, so the three places agree. Also fixed the 102-char line.
• Tests: the three assertions now also check "now searchable" not in reply.

On making wait=true wait for indexing: we decided against it. How long the index takes to catch up depends on server load (and on Cloud vs self-hosted), so any bound we picked would be a guess, and a bounded wait that times out would need yet another message. One honest statement everywhere seemed better than a sometimes-true guarantee.

[dani1005]

Thanks, this all looks good, and the reasoning on not waiting for the index makes sense to me. I pushed one small follow-up (9677d0d): the Conversation.store docstring still said "extracted" means searchable, which is the claim this PR retires.

[dani1005]

LGTM.