Memory System
Memory is what makes an agent feel intelligent over time instead of starting from zero every turn.
The four memory types
Conversation Memory
Stores the current conversation history. Automatically included in every turn. Has a configurable TTL and message window size.Best for: Support bots, assistants, any interactive chat
Persistent Memory
Long-term storage that survives across sessions. Explicitly written and read. Think: user preferences, company name, recurring context.Best for: Personal assistants, CRM agents, user profiling
Ephemeral Memory
Single-session only. Gone when the conversation ends. Ideal for sensitive temporary state.Best for: Checkout flows, one-time auth challenges, wizard-style UX
Summarized Memory
Long conversations get auto-compressed into a summary. The agent sees the summary instead of the full history, keeping context window costs low.Best for: Long-running assistants, research agents, complex projects
When to use each type
HiveLang v5 memory configuration
Memory in Swarms
In a multi-agent swarm, memory is namespaced at the swarm level:Scout and Analyst can access swarm-level memory. Individual agent memory is private to that agent’s execution.
Memory best practices
Store context, not raw messages
Store context, not raw messages
Don’t remember entire message transcripts. Extract and store structured facts: customer name, issue type, preferred language, plan tier. This keeps memory compact and useful.
Never store sensitive data in persistent memory
Never store sensitive data in persistent memory
Payment card numbers, passwords, access tokens — these should never go into persistent memory. Use your integration’s secure credential store instead.
Set appropriate TTLs
Set appropriate TTLs
Conversation memory with no TTL will keep growing. Set a TTL that matches your use case: 24h for support bots, 7d for assistants, 90d for long-term CRM agents.
Use summarized memory for long contexts
Use summarized memory for long contexts
If your agent handles 50+ message conversations, switch to
summarized memory. It auto-compresses older messages and keeps the token cost flat.Scope memory correctly in SaaS
Scope memory correctly in SaaS
Always scope memory to
(bot_id, user_id). Never store cross-user state in a single key — every user should see only their own memory.Memory and observability
Every memory read and write is visible in the run trace. Under Runs → Trace, you’ll see:memory.read— what keys were fetched and their valuesmemory.write— what was stored and whenmemory.miss— keys that were queried but had no value