Summary
Two adjacent behaviors of search_long_term_memory that we live-verified on 0.14.0 and found undocumented:
- Empty-text search is a reliable listing primitive.
search_long_term_memory(text="", namespace={"eq": ns}, limit=N) returns the namespace's records without semantic filtering — the only dependable way we found to enumerate/count a namespace.
- Semantic (non-empty) search applies a relevance cutoff, so it cannot be used to count or enumerate — records that exist simply don't appear for weak queries. We initially misread this as data loss while diagnosing an eventual-consistency question; an explicit doc note would have prevented that.
Ask
Document both: "to list/count a namespace, use empty text; semantic search is top-k with a relevance floor, not an enumeration." If empty-text-as-listing is unintentional and might change, that's even more important to state — consumers (us included: Smart-AI-Memory/attune-ai#666) now depend on it.
Happy to PR the docs note. Context: AMS backs attune-ai's cross-session memory in production.
Summary
Two adjacent behaviors of
search_long_term_memorythat we live-verified on 0.14.0 and found undocumented:search_long_term_memory(text="", namespace={"eq": ns}, limit=N)returns the namespace's records without semantic filtering — the only dependable way we found to enumerate/count a namespace.Ask
Document both: "to list/count a namespace, use empty text; semantic search is top-k with a relevance floor, not an enumeration." If empty-text-as-listing is unintentional and might change, that's even more important to state — consumers (us included: Smart-AI-Memory/attune-ai#666) now depend on it.
Happy to PR the docs note. Context: AMS backs attune-ai's cross-session memory in production.