Skip to main content

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

For persistent memory — write and read explicitly in your bot’s on-event handlers:

Memory in Swarms

In a multi-agent swarm, memory is namespaced at the swarm level:
Both Scout and Analyst can access swarm-level memory. Individual agent memory is private to that agent’s execution.

Memory best practices

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.
Payment card numbers, passwords, access tokens — these should never go into persistent memory. Use your integration’s secure credential store instead.
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.
If your agent handles 50+ message conversations, switch to summarized memory. It auto-compresses older messages and keeps the token cost flat.
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 explicit remember 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 values
  • memory.write — what was stored and when
  • memory.miss — keys that were queried but had no value
This makes it easy to debug memory-related issues without guesswork.

Next reads

Architecture

Observability

Build Your First Agent