# Observing Agent-Memory Retrieval

May 19, 2026. VALESKA defines an agent-memory cascade and begins measuring how retrieval is used.

Language: en
Canonical: https://avanticomplex.com/en/blog/observing-agent-memory-retrieval/

Published: 2026-05-19T12:00:00.000Z

2026-05-19. A shared memory store only helps if an agent knows when to consult it and if we can later tell whether that consultation was useful. My claim is that retrieval needs an operating model and evidence of use, not just an embedding index. The working question is deliberately practical: when a conversation turns to a project, decision, person, or prior piece of work that is not already in the agent's loaded context, can the agent make one disciplined recall attempt and leave enough of a record for us to assess the attempt?

I am defining that behavior as a three-layer cascade. L1 is the agent's own startup memory: identity, durable preferences, and its local project index. It is already in the prompt, so it should not cause a search. L2 is VALESKA's shared Postgres and vector store, reached through the memory tools when a topic shift, an explicit recall request, or work on another agent's repository calls for prior context. L3 is everything outside those stores: files not yet read, the web, and other external systems. The layers describe responsibility as much as speed. The agent decides whether a topic meets the L2 trigger; no hook silently injects retrieved material before every user turn.

That distinction matters. Automatic capture was made safer in [the previous entry](/en/blog/making-automated-capture-safer/), but safer capture alone cannot show whether later recall served the work. The cascade specification sets a reflex rule for a new, ungrounded topic and also names skip conditions for a continuing task or material already present in L1. It sets a cost ceiling of one search per topic shift and no further pagination when fewer than three results exceed the similarity threshold. Those are operating assumptions to examine, not proof that the rule is being followed well.

The implementation adds an append-only `search_events` record for each semantic search. It stores the query and its filters, elapsed time, requested limit, result count, count above the threshold, top similarity, and the returned agents, projects, and thought types. Caller identity is optional at this point because the Model Context Protocol (MCP) path has not yet supplied it consistently. The event write is deliberately isolated: an insertion failure is caught so observability cannot make memory retrieval unavailable. The accompanying architecture record proposes four measures—search rate, capture rate, hit rate, and cross-agent reads—and supplies reference queries for inspecting them. Capture rate remains derivable from the memory records themselves; it does not need a duplicate event stream.

I have also recorded the failure modes this model must expose. Repeatedly re-deriving an answer can mean that capture or retrieval failed. Contradictory sessions can mean the reflex was missed. A stale result is historical context, not a substitute for checking current code. A flood of irrelevant material can mean that the question was too broad or did not warrant retrieval. None of these observations has been measured here. The telemetry is the beginning of a way to distinguish them.

## What I will test next

The first task is to let events accumulate for one to two weeks before treating a dashboard as informative. I will compare real topic-shifting sessions with their searches and captures, inspect misses and low-similarity results, and check whether cross-agent work actually surfaces another agent's record. Only then can the trigger, threshold, or result limit be adjusted on evidence rather than intuition.

**Historical basis:** 2026-05-19 repository milestone, commit `cbd118f`.


## Translations
- en: https://avanticomplex.com/en/blog/observing-agent-memory-retrieval/
- es: https://avanticomplex.com/es/blog/observing-agent-memory-retrieval-es/
- pt: https://avanticomplex.com/pt/blog/observing-agent-memory-retrieval-pt/