Skip to main content

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

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.

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