What is proactive recall vs reactive recall?

The previous chapter covered which retrieval type to use for a given search. This chapter takes up a different question entirely: who or what actually decides that a search should happen in the first place. That decision can be left to an agent’s own judgment in the moment, or it can be handled automatically by infrastructure that fires regardless of what the agent decides. The difference between these two approaches turns out to matter more than it might first appear.

What Does It Actually Mean for Recall to Be Reactive Rather Than Proactive?

Reactive recall means an agent itself decides, in the moment, whether a specific situation calls for searching memory, typically by choosing to invoke a search tool it’s been given access to. Proactive recall means that decision is made ahead of time by the surrounding infrastructure, triggering a search automatically at a defined point, before a session starts, before each new message, regardless of whether the agent itself would have decided to search on its own. The distinction isn’t about which retrieval type gets used once a search actually happens, it’s about whether the search happens at all, and who’s actually responsible for that decision.

Why Might an Agent Given the Freedom to Decide for Itself Actually Choose Not to Search Memory Very Often?

An agent weighing whether to reach for an external memory tool is implicitly weighing that tool against whatever’s already conveniently available to it, and if a simpler, always-present alternative already satisfies the immediate task, the agent has little practical incentive to make the extra effort of invoking a separate tool call. This isn’t a flaw in the agent’s reasoning, it’s a completely rational response to genuinely having no clear, compelling reason to reach for a tool that costs more effort than simply continuing with what it already has in front of it.

What Does This Look Like When It Actually Plays Out in a Real System?

An agent given access to a memory search tool, but no explicit guidance about exactly when that tool should actually be used, can end up simply not using it at all, defaulting instead to whatever cheaper, already-loaded context happens to be sitting in front of it, even when that memory tool holds genuinely useful information the agent never bothers to retrieve. The problem here isn’t that the memory system failed to work, it’s that leaving the decision to the agent’s own unguided judgment, with no concrete trigger forcing that decision, produced a real and predictable gap between what memory could have offered and what the agent actually recalled.

How Does Proactive Recall Actually Close This Gap Without Relying on the Agent’s Own Judgment at All?

Proactive recall moves the decision out of the agent’s hands entirely, firing a search automatically at defined moments in a session’s lifecycle, before the very first message, or before each subsequent turn, so that relevant memory is already sitting in context by the time the agent even starts reasoning about how to respond. The agent never has to decide to recall, because the recall has already happened, deterministically, regardless of whatever the agent itself might have chosen to do left entirely to its own devices.

Does This Mean Reactive Recall Is Simply the Wrong Approach and Should Always Be Avoided?

Not entirely, reactive recall still has a genuine place for situations that are inherently unpredictable or that only become clear partway through a task, a follow-up question that couldn’t have been anticipated at the start of a session, or a mid-task pivot that only makes sense to search for once the agent is already several steps into reasoning about something. The real lesson isn’t that reactive recall is always wrong, it’s that relying on it exclusively, with no proactive fallback covering the predictable, common cases, leaves exactly the kind of gap that shows up when an agent simply never gets around to deciding to search at all.

How Does Weaviate Engram Support Building Proactive Recall Directly Into a System’s Own Infrastructure?

Weaviate Engram’s search API can be called deterministically at fixed points in an application’s own control flow, independent of whether an agent would have chosen to search on its own. Consider a field-service dispatch platform helping appliance repair technicians prepare for each visit, where a customer’s prior repair history should be available automatically rather than depending on the assistant remembering to look it up:

from engram import EngramClient

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

def prepare_technician_briefing(customer_id, upcoming_appointment_notes):
    history = client.memories.search(
        query="Prior appliance issues and repair history for this customer",
        user_id=customer_id,
        retrieval_config="hybrid",
    )
    context = "\n".join(f"- {m.content}" for m in history)
    return f"Customer history:\n{context}\n\nUpcoming visit notes:\n{upcoming_appointment_notes}"

Because this search runs automatically as a fixed step in the dispatch workflow itself, triggered the moment a technician’s appointment is scheduled rather than depending on an assistant deciding in the moment that a lookup might be worthwhile, the technician’s briefing always includes relevant repair history, even during a routine visit where nothing about the current appointment notes would have obviously prompted an agent to go searching for past context on its own. This is exactly the value proactive recall delivers for a use case like field service dispatch, where a technician arriving informed about a customer’s recurring issue makes a real, practical difference, and where leaving that lookup to an assistant’s own unguided discretion risks it simply never happening.

Proactive recall guarantees relevant memory actually surfaces at the moments a system can predict in advance, rather than depending on an agent’s own, sometimes unreliable, judgment. The most common form this proactive pattern takes is using whatever a person just said as the search query itself, triggered automatically before every response. Our next chapter, What is query-time retrieval using the current message?, takes up exactly that pattern.