What is query-time retrieval using the current message?

The previous chapter established that proactive recall works by firing automatically at predictable points, rather than waiting for an agent to decide a search is worthwhile. This chapter looks at the single most common way that proactive trigger actually gets implemented: using whatever a person just said as the search query itself, run automatically before every single response.

What Does It Actually Mean to Use the Current Message as the Search Query?

Instead of an agent composing its own deliberate search query, or deciding whether to search at all, the system simply takes whatever the person just typed and passes it directly into a memory search, every single time, before generating a response. This is about as simple a proactive trigger as exists, no judgment call, no separate query-writing step, just the person’s own words doing double duty as both the input to the conversation and the input to memory retrieval.

Why Does Something This Simple Actually Work Reasonably Well in Practice?

A person’s current message is usually a strong, honest signal of what’s actually relevant to them right now, since it’s literally what they’re asking about or referring to in this exact moment. Searching memory using that same message as the query tends to surface exactly the kind of context that message would naturally call for, a past preference relevant to a current question, a prior detail relevant to a current request, without requiring any separate reasoning step to figure out what to search for in the first place. The message a person already typed is, more often than not, already a perfectly serviceable query.

What Happens When the Current Message Doesn’t Actually Have Any Relevant Memory to Surface?

Since this pattern runs on every single message regardless of whether relevant memory genuinely exists, it will sometimes return results that technically matched something but aren’t actually useful, the closest thing available in an otherwise irrelevant collection, rather than anything a person would genuinely recognize as pertinent. Injecting this kind of weak, technically-matched-but-not-actually-relevant content into context risks diluting or even misleading a response rather than helping it, exactly the context pollution concern raised elsewhere in this knowledge base’s discussion of context engineering.

How Does a System Actually Avoid Injecting Irrelevant Results Just Because a Search Happened to Return Something?

A similarity threshold filters out results that fall below a minimum relevance score, ensuring that only memories genuinely close to the query’s meaning actually make it into context, rather than whatever happened to be closest among an entirely unrelated set of candidates. Since every stored memory has some numeric distance from any given query, a search will always technically return its closest matches even when none of them are actually relevant, and a threshold is exactly what distinguishes a genuinely strong match worth including from a weak one that only won by default because nothing better existed.

Does This Threshold Need to Be Set Once and Left Alone, or Does It Need Genuine Tuning for a Specific System?

The right threshold genuinely depends on a system’s own embedding model and its own typical content, there’s no single universal number that works correctly everywhere. A threshold set too loosely lets weak, marginally related matches through, reintroducing exactly the pollution problem the threshold was meant to prevent. A threshold set too strictly risks filtering out genuinely useful memories that simply scored slightly lower than an arbitrary cutoff. Getting this right calls for actually testing against a specific system’s real content and real queries, rather than assuming a number that worked somewhere else will transfer cleanly.

How Does Weaviate Engram Let a System Implement This Query-Time Retrieval Pattern with a Meaningful Relevance Threshold?

Weaviate Engram’s search API lets a caller pass the current message directly as the query and configure retrieval so that only sufficiently relevant results actually get returned. Consider a home fitness coaching app, where a coaching assistant should recall relevant training history without cluttering its responses with unrelated notes:

from engram import EngramClient
from engram import HybridRetrieval

client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

def generate_coaching_response(user_id, current_message):
    results = client.memories.search(
        query=current_message,
        user_id=user_id,
        retrieval_config=HybridRetrieval(limit=5),
    )
    relevant_context = [m.content for m in results if m.score >= 0.6]
    return relevant_context

When a client asks “how’s my shoulder feeling these days,” this pattern surfaces genuinely relevant prior notes about shoulder mobility or past injury flare-ups, since that message closely matches memories actually about that topic. When a client instead asks something entirely unrelated to any prior conversation, a scheduling question with no real training history behind it, the same threshold filters out whatever technically-closest but genuinely unrelated memory the search would otherwise have returned by default, keeping the response focused rather than padded with irrelevant, barely-related context. This is exactly the value query-time retrieval with a proper threshold delivers: simple, automatic recall that stays actually useful rather than injecting noise just because a search ran.

Query-time retrieval covers the common case where an agent’s context is built automatically before it ever starts reasoning. Some situations genuinely call for the opposite, letting an agent decide for itself, in the middle of its own reasoning, exactly when and what to search. Our next chapter, What is tool-based memory retrieval?, takes up exactly that alternative.