Agent memory sounds harmless.
Remember my preferred report format. Remember which metrics I care about. Remember that we exclude test accounts from revenue.
Useful.
But once the same agent can query a database, memory stops being just convenience. It becomes part of the decision surface.
A recalled preference can influence which tool the agent chooses, what SQL it writes, what rows it returns, and what it treats as relevant.
That means memory needs governance.
Not all context is the same
For database workflows, I separate two kinds of context:
-
Curated schema context
- table meaning
- approved joins
- metric definitions
- source-of-truth notes
- safe default filters
-
User/session memory
- preferred formats
- recurring questions
- past feedback
- task-specific working notes
The first should be reviewable and durable.
The second should be scoped, redacted, and easy to forget.
Mixing them casually is where the risk starts.
What should not become memory
For database-connected agents, I would avoid storing:
- raw query result rows
- credentials or secrets
- copied customer data
- tenant-specific details in global memory
- unverified business assumptions
- temporary exceptions that should expire
Long-term memory should not become a cache of everything the agent has ever seen.
It should be a controlled source of useful context.
We wrote the full piece here: Agent memory for database workflows: useful context or hidden risk?
And yes, this is exactly where MCP architecture matters. Conexor helps expose databases and APIs as MCP tools for AI clients without turning memory into permission.
Memory makes agents more useful.
Boundaries make that usefulness repeatable.
Top comments (0)