The Recall Loop in Practice
agentmemory is easiest to judge by following one remembered decision through its complete loop: a coding action is emitted by a host, captured and filtered, shaped into a searchable record, selected by one or more retrieval signals, and delivered within a bounded context. This checkpoint connects those stages and uses contrasting operating modes and failure cases to answer a practical question: when a later session cannot find what it needs, what actually failed, and what can the evidence support?
One decision across the loop
Imagine a session in which an agent is asked to add rate limiting to an API. It reads the authentication middleware, edits a configuration file, runs tests, encounters a failure, and eventually gets the suite passing. The useful future memory is not one line saying “rate limiting added.” It may include the files touched, the test outcome, the authentication decision that constrained the implementation, and the failed approach that should not be repeated.
At the host boundary, those moments arrive as lifecycle events. A session-start event gives the runtime a session identity and project. A post-tool event carries the tool, its input, and its result. A failure event preserves a different kind of evidence from a successful edit. The host hook sends a normalized request to agentmemory; the REST layer validates the required identity and timing fields before the iii-backed worker accepts it. If the host never emits the event, or if the server is unreachable while the hook's short timeout expires, the coding action can still finish but the memory loop has a gap at its first transition.
When the event does arrive, the observer sanitizes it before writing the raw observation. A private tag or recognizable credential pattern can be replaced, and the event receives an origin such as user, tool, or agent. This is the point at which privacy and provenance become part of the record rather than an afterthought. The result is not an untouched transcript, and the origin is not a truth score. It is a filtered account with a traceable entry route.
The runtime then makes the observation searchable. In the default path it produces a synthetic compressed representation without calling an LLM. That representation can include a title, facts, narrative, concepts, files, type, and importance. If automatic LLM compression is explicitly enabled and a provider is available, a richer structured path can run instead. Either way, the record enters the search machinery only after the capture boundary has been crossed. A provider or vector index can fail without making the original event equivalent to a successful, fully enriched observation.
Later, a query about the API's protection might contain the exact phrase “rate limiting,” the more indirect phrase “throttle abusive requests,” or the name of a middleware file. BM25 can recover literal terms and identifiers. A vector stream, if configured and populated, can bridge some paraphrases. Graph data, if present, can connect the file, concept, library, and decision through relationships. The result is fused and filtered before a compact response is returned. The agent can expand selected evidence rather than receive every observation from the session.
The final transition is easy to overlook: delivery is bounded. A relevant observation can be in the corpus but not in automatically injected context because it ranked below the limit, fell outside a project or agent scope, or did not fit the token budget. That does not mean the record was never captured. It means the system made a second decision about what the next model input could carry. The loop has several observable states, and each state explains a different kind of absence.
The diagram is not claiming that every record must pass through every optional state.