What is multi-hop retrieval across related memories?

Every retrieval pattern covered so far in this Part, whether triggered automatically or invoked as a tool, has assumed a single search can actually answer the question at hand. Some questions genuinely can’t be answered that way, the answer only comes into view after following a chain of connections, one memory pointing to the next, sometimes several hops deep. This chapter looks at multi-hop retrieval, the pattern for handling exactly that kind of question.

Why Can’t a Single Search Answer a Question That Genuinely Requires Following a Chain of Connections?

A single search compares a query against stored content and returns whatever’s most similar, but it has no built-in way to then take one of those results and search again based on what that result actually said. A question like “what happened to the component this supplier originally sourced from their own upstream vendor” isn’t answerable by one search alone, since the answer depends on first finding which vendor supplied that component, and only then searching again for what actually happened to it from that specific vendor’s side. Each hop depends on the result of the one before it, something no single, one-shot search can express.

What Does It Actually Mean to Decompose a Complex Question into a Sequence of Simpler Searches?

Multi-hop retrieval breaks a complex question down into a chain of smaller, individually answerable sub-questions, each one searched separately, with the answer from one hop feeding directly into how the next hop’s search actually gets formulated. The first search identifies an intermediate fact or entity, and the second search then uses that intermediate result as its own starting point, continuing however many additional hops the original question actually requires before arriving at something that finally answers it directly.

How Does an Agent Actually Know When a Single Search Wasn’t Enough and Another Hop Is Genuinely Needed?

The agent examines what the first search actually returned and reasons about whether that result directly answers the original question or merely identifies something else that still needs to be looked up in turn. A result that names an entity, a person, a related fact, without yet supplying the actual detail the original question was asking about, is a clear signal that another hop is needed, searching specifically for that named entity rather than treating the first search’s output as though it were already the final answer.

Does This Chaining Process Ever Reach a Point Where It Should Genuinely Stop, Rather Than Continuing to Hop Indefinitely?

Yes, and recognizing that stopping point matters just as much as recognizing when another hop is needed in the first place. The chain should stop once a search actually returns content that directly answers the original question, rather than merely pointing toward yet another entity or fact still left to look up. Continuing to hop past this point wastes effort chasing connections the original question never actually asked about, while stopping too early leaves the question only partially answered, still resting on an intermediate result rather than the actual detail being sought.

What Makes This Kind of Chained Retrieval Genuinely More Reliable Than Trying to Force a Single, Overly Broad Search to Cover Everything at Once?

A single search covering an entire multi-part question at once has to somehow represent every part of that question in one query, diluting the precision that a genuinely well-scoped, single-hop search would otherwise achieve for each individual part. Breaking the question into a deliberate sequence keeps each individual search sharply focused on exactly one specific thing to find, letting each hop actually benefit from precise, well-targeted retrieval rather than asking one broad search to somehow cover ground that really calls for several separate, focused ones.

How Does Weaviate Engram Support This Kind of Chained, Multi-Hop Retrieval Across Related Memories?

Weaviate Engram’s search API can be called repeatedly within an agent’s own reasoning loop, with each subsequent search shaped by whatever the previous one actually returned. Consider a supply-chain compliance auditor tracing a specific component through multiple tiers of suppliers, where a compliance question can’t be answered without following the chain back through more than one link:

from engram import EngramClient

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

first_hop = client.memories.search(
    query="Which upstream vendor supplied the specialty polymer used in this component?",
    properties={"program_id": "program-avionics-housing"},
    retrieval_config="hybrid",
)

The first search returns a memory identifying a specific upstream vendor by name, an intermediate fact rather than the actual compliance answer the auditor originally needed, prompting a second, more targeted search:

second_hop = client.memories.search(
    query="Has this specific upstream vendor had any recent material sourcing compliance flags?",
    properties={"program_id": "program-avionics-housing"},
    retrieval_config="hybrid",
)

Only this second hop, searching specifically for compliance history tied to the vendor the first hop actually identified, surfaces the detail the auditor genuinely needed, whether that specific upstream vendor’s own sourcing practices have raised any recent concerns. Neither search alone could have answered the original question, the first hop needed to happen before the second one could even be properly formulated. This is exactly the value multi-hop retrieval delivers for a use case like supply-chain compliance auditing, where the answer to a real question genuinely depends on following a chain through more than one connected memory rather than sitting in any single one of them alone.

Multi-hop retrieval lets a system answer questions no single search could resolve, by chaining searches deliberately rather than forcing everything into one broad attempt. A related distinction sits just underneath this one, worth examining directly: whether memory retrieved along the way should stay purely internal to an agent’s own reasoning, or whether it should actually appear in a final answer. Our next chapter, Should retrieval for reasoning differ from retrieval for final answers?, takes up exactly that distinction.