Channel: dev.to article #2
Filed at: 2026-05-17T08:05:37Z
Draft
Title: Pull vs push: why agent memory architecture matters
Tags: ai, agents, memory, llm
Most agent memory systems inject everything on every call. That is push-model memory. The agent gets a context stuffed with memories it may not need. Then it has to figure out which ones are relevant. The model does the filtering, not the retrieval system.
Pull-model memory flips this. The agent asks for what it needs, when it needs it. The retrieval system does the filtering. The model gets back a small, targeted result.
This sounds like a minor implementation detail. It is not.
The push-model problem in practice
Imagine an agent that has stored 50 facts over the course of a conversation. In push-model memory, those 50 facts go into the context on every call. Some are months old. Some contradict newer facts. Some are flat-out wrong because the user corrected them later.
The model now has two jobs: answer the current question and filter the memory bank. These tasks compete for attention. The more memories you have, the worse this gets. Context fills. Cost goes up. Accuracy goes down.
Most memory systems try to solve this by ranking memories before injection, sending only the top-k. That helps. But top-k push is still push. The agent does not ask for anything. The retrieval system guesses what the agent will want.
What pull-model changes
In pull-model memory, the agent decides what to retrieve. It forms a query, sends it to the memory store, and gets back the matching records. The rest of the memory bank is not in context. It does not affect the model's attention.
This means the agent can be precise. If it needs to recall what the user said about shipping addresses, it can ask for exactly that. Not the last 20 memories, not the top-5 ranked by cosine similarity against the current message, but the specific thing it is looking for.
The retrieval result is small. The model's context stays clean.
The delete problem
Pull-model retrieval only works correctly if the records in the store are actually correct. That depends on deletes.
Most memory systems do not support real deletes. When you call delete, the system adds a tombstone: a marker that says this record is invalid. The tombstone stays in the store. A well-designed retriever will skip it. A poorly-designed one might still return it.
Even with a good retriever, tombstones accumulate. The store grows. Garbage from months ago sits next to current facts.
hermes-agentmemory and the underlying agentmemory library take a different approach. Delete removes the record. The vector entry is gone. The retriever cannot return it because there is nothing to return. The store stays clean.
Why this matters for correctness
An agent that can retract memories can behave correctly when the world changes. The user changes their shipping address. The agent deletes the old one and stores the new one. Future queries return the new address. The old one is not even a candidate.
With tombstone-based deletes, the old address is still there. Whether it comes back depends on your retriever implementation and how you set confidence thresholds. With real deletes, the question never arises.
The audit log
Knowing what an agent remembers is useful. Knowing what it forgot is more useful.
hermes-agentmemory writes every operation (store, recall, delete) to a JSONL trace file at $HERMES_HOME/agentmemory/trace.jsonl. You can tail it in real time, replay it for debugging, or scan it to verify that a delete actually happened.
This is not logging for logging's sake. It is the cheapest way to verify that memory behavior matches expectations before you discover the problem in production.
Links
The library is under 600 lines of code. MIT license. CI is green on Python 3.10-3.13 across Linux and macOS. It is a drop-in plugin for Hermes Agent (NousResearch, 153k stars).
Where to post
https://dev.to/new (log in as mukundakatta, click "Write a post", paste the title and body above, add the tags listed at the top, publish)
Action
Review, edit if needed, then post. Close this issue when shipped.
Channel: dev.to article #2
Filed at: 2026-05-17T08:05:37Z
Draft
Title: Pull vs push: why agent memory architecture matters
Tags:
ai,agents,memory,llmMost agent memory systems inject everything on every call. That is push-model memory. The agent gets a context stuffed with memories it may not need. Then it has to figure out which ones are relevant. The model does the filtering, not the retrieval system.
Pull-model memory flips this. The agent asks for what it needs, when it needs it. The retrieval system does the filtering. The model gets back a small, targeted result.
This sounds like a minor implementation detail. It is not.
The push-model problem in practice
Imagine an agent that has stored 50 facts over the course of a conversation. In push-model memory, those 50 facts go into the context on every call. Some are months old. Some contradict newer facts. Some are flat-out wrong because the user corrected them later.
The model now has two jobs: answer the current question and filter the memory bank. These tasks compete for attention. The more memories you have, the worse this gets. Context fills. Cost goes up. Accuracy goes down.
Most memory systems try to solve this by ranking memories before injection, sending only the top-k. That helps. But top-k push is still push. The agent does not ask for anything. The retrieval system guesses what the agent will want.
What pull-model changes
In pull-model memory, the agent decides what to retrieve. It forms a query, sends it to the memory store, and gets back the matching records. The rest of the memory bank is not in context. It does not affect the model's attention.
This means the agent can be precise. If it needs to recall what the user said about shipping addresses, it can ask for exactly that. Not the last 20 memories, not the top-5 ranked by cosine similarity against the current message, but the specific thing it is looking for.
The retrieval result is small. The model's context stays clean.
The delete problem
Pull-model retrieval only works correctly if the records in the store are actually correct. That depends on deletes.
Most memory systems do not support real deletes. When you call delete, the system adds a tombstone: a marker that says this record is invalid. The tombstone stays in the store. A well-designed retriever will skip it. A poorly-designed one might still return it.
Even with a good retriever, tombstones accumulate. The store grows. Garbage from months ago sits next to current facts.
hermes-agentmemory and the underlying agentmemory library take a different approach. Delete removes the record. The vector entry is gone. The retriever cannot return it because there is nothing to return. The store stays clean.
Why this matters for correctness
An agent that can retract memories can behave correctly when the world changes. The user changes their shipping address. The agent deletes the old one and stores the new one. Future queries return the new address. The old one is not even a candidate.
With tombstone-based deletes, the old address is still there. Whether it comes back depends on your retriever implementation and how you set confidence thresholds. With real deletes, the question never arises.
The audit log
Knowing what an agent remembers is useful. Knowing what it forgot is more useful.
hermes-agentmemory writes every operation (store, recall, delete) to a JSONL trace file at
$HERMES_HOME/agentmemory/trace.jsonl. You can tail it in real time, replay it for debugging, or scan it to verify that a delete actually happened.This is not logging for logging's sake. It is the cheapest way to verify that memory behavior matches expectations before you discover the problem in production.
Links
The library is under 600 lines of code. MIT license. CI is green on Python 3.10-3.13 across Linux and macOS. It is a drop-in plugin for Hermes Agent (NousResearch, 153k stars).
Where to post
https://dev.to/new (log in as mukundakatta, click "Write a post", paste the title and body above, add the tags listed at the top, publish)
Action
Review, edit if needed, then post. Close this issue when shipped.