Building a Memory Layer Into an AI Agent Product: What Actually Persists Between Sessions
Nothing persists between agent sessions by default. What belongs in a file, a database row or a vector store, and why your agent never learns from corrections.
Contents
What actually persists between agent sessions by default?
Why doesn't the agent learn from my corrections?
What are the three different things people call memory?
Should a memory live in a file, a database row or a vector store?
When should the agent decide what to remember?
How do you stop remembered facts contradicting each other?
Why does memory get worse as the store gets bigger?
How should memory be scoped per user, session and account?
Can an attacker write to your agent's memory?
What does Australian privacy law require of stored user memories?
Frequently asked questions
Get the memory architecture right before you ship it
buildAgency puts one senior Melbourne engineer on your agent product to design the memory store, the write path and the delete path, for a fixed scope. You own the code.
See buildAgencyRelated Guides
AI Agents in Production: What Works, What Doesn't, and Who's Actually Shipping
An honest, hedged look at where AI agents genuinely work in production today, where they don't yet, and how to scope a narrow use case.
A Real Prompt Injection Attempt Against a Live Australian System, and Why It Failed
In July 2026 an attendee tried to prompt inject a live Australian system. The exact payload, why it failed, and the design that would have fallen for it.
Context Windows and Token Limits: Why a Bigger Window Does Not Fix It
A 1M-token window does not fix context problems. What the research says about context rot, what it costs, and the techniques that actually work.