Giving Your Agent Persistent Memory
Part 7 covered long-term memory conceptually. This part builds it — a real, working implementation letting Bright Leaf Coffee's inventory agent genuinely remember patterns across separate, real sessions.
The real, persistent storage model
# models.py (Django, per the Django series' own conventions)
from django.db import models
class AgentMemory(models.Model):
fact = models.TextField()
category = models.CharField(max_length=50)
embedding = models.JSONField() # real, stored vector, part 1 of
# the LLM & Advanced AI series
created_at = models.DateTimeField(auto_now_add=True)This directly reuses the Django series' own real models pattern — genuine, persistent storage that survives across separate real process runs, unlike part 6's in-memory Python dictionaries.
Real, embedding-based storage and recall
from shared.embeddings import embed_text # the LLM & Advanced AI
# series' own embedding call
def remember(fact: str, category: str) -> None:
vector = embed_text(fact)
AgentMemory.objects.create(fact=fact, category=category, embedding=vector)
def recall_relevant(current_situation: str, top_n: int = 3) -> list[str]:
query_vector = embed_text(current_situation)
all_memories = AgentMemory.objects.all()
scored = [
(cosine_similarity(query_vector, m.embedding), m.fact)
for m in all_memories
]
scored.sort(reverse=True)
return [fact for score, fact in scored[:top_n]]This directly applies the LLM & Advanced AI series' own embedding and similarity techniques to agent memory specifically — recall_relevant() finds real, semantically related past facts, not just an exact keyword match, exactly the same real reasoning behind that series' RAG work.
Wiring real memory into the agent's own reasoning
def run_inventory_agent_with_memory(request: str) -> str:
relevant_memories = recall_relevant(request)
memory_context = "\n".join(relevant_memories) if relevant_memories else "No relevant past learnings."
messages = [{"role": "user", "content": request}]
system = f"{SYSTEM_PROMPT}\n\nRelevant past learnings:\n{memory_context}"
# ...same real loop as part 6, using this augmented system promptA real, concrete example of this actually working
Session 1 (October): agent processes several real reorder decisions,
and a real, separate process later logs an observed pattern:
remember("Ethiopian Light Roast demand spikes 40% in November-
December", category="seasonal")
Session 2 (mid-November, a genuinely SEPARATE process run): agent
checks Ethiopian Light Roast, stock at 22 (normally above the
reorder threshold) → recall_relevant() surfaces the real, stored
November pattern → the agent reasons this stock level is
genuinely risky THIS specific month, and reorders proactively
despite being nominally above the usual thresholdThis is the real, concrete, practical value long-term memory adds over part 6's version — the agent's actual behavior genuinely improves across separate sessions, incorporating real, learned context a purely stateless version could never access, since it has no way to know what happened in a prior, separate run.
Who actually writes to long-term memory — a real, honest design question
Automatic: the agent itself decides what's worth remembering after
each real task — genuinely convenient, but risks storing noisy,
low-value real facts
Curated: a real, human periodically reviews and adds genuinely
significant patterns — more real, deliberate effort, but higher
real signal qualityA real, practical middle ground many production systems use: the agent proposes a candidate memory, and a real, lightweight human approval step (similar in spirit to the LLM & Advanced AI series' own confirmation pattern for consequential actions) confirms it before it's genuinely, permanently stored.
A real, honest limit: memory can go stale too
The same real staleness risk the LLM & Advanced AI series flagged
for RAG document indexes applies here — a remembered "fact" from
six months ago may no longer genuinely hold true, and a real
memory system needs the same honest consideration of expiry or
periodic reviewFAQ
Why store the embedding in a JSONField instead of a real vector database?
For a small number of memories, JSONField plus computing cosine similarity in Python (as recall_relevant does) is simple and sufficient. Once the memory table grows into the thousands, a real vector database with an indexed similarity search (covered in the LLM & Advanced AI series) becomes the faster option, since comparing against every stored embedding one by one in Python stops scaling.
Does every fact the agent encounters get embedded and stored?
No — only what an explicit remember() call saves, which is the point of the "automatic vs. curated" design question this part raises. Embedding and storing everything indiscriminately is exactly the noisy-memory risk that section warns about.
What happens if two stored memories contradict each other?
Nothing in this basic implementation resolves that automatically — recall_relevant returns both if they're both relevant, and the agent has to reason about the conflict using whatever's in its system prompt. A more complete system would need an explicit conflict-resolution step, such as preferring the more recently stored memory, which this part doesn't build.
Next: how AI agents use APIs and external tools — connecting an agent to real, genuine external systems beyond this series' own in-memory examples.