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.What Bothive saves automatically
Bothive treats conversation history and durable memory differently. Recent messages are retained for continuity within a bot-user session. They are not automatically promoted into the long-term memory store. Automatic durable memory is deliberately strict. A fact must be explicit, structured, non-sensitive, likely to matter later, and scored with high confidence. Each saved fact carries a reason and confidence in its metadata so an owner can understand why it was kept. Greetings, one-off questions, temporary task details, assistant output, credentials, payment data, health information, and inferred traits should not become durable memory. For anything important, prefer an explicitremember instruction in HiveLang. That makes the intent clear to the user and to anyone reviewing the run trace.
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