Memory
Hive builds a persistent memory from every session. When you resolve an issue, Hive stores what worked. The next time a similar problem occurs on any agent in your organization, Hive finds the relevant resolution and applies it — without you having to explain the fix again.
Memory Types
| Type | What it stores |
|---|---|
| resolution | A solution that fixed a specific problem (highest value, searched first) |
| command | A command or sequence of commands that achieved a specific outcome |
| context | Background facts about a server — stack, environment, known quirks |
| learning | General operational lessons observed across sessions |
| error | Known errors and their patterns, useful for pattern matching on new failures |
How Memory Works
After each session, Hive reviews the conversation and extracts:
- What the problem was
- What commands were run
- What resolution succeeded (if any)
- Any new facts about the server's environment
These are embedded (converted to vector representations) and stored alongside metadata — agent, timestamp, importance level, and optional expiry.
At the start of the next session, Hive performs a semantic search across memories relevant to the current task and injects them as context before responding. This means Hive "remembers" that your PostgreSQL replica has a known replication lag issue, or that your nginx config is in a non-standard path.
Importance Levels
Memories have an importance level from 1–10. Higher importance memories are retained longer and surfaced more prominently in searches.
| Level | Meaning |
|---|---|
| 1–3 | Low importance — pruned first, routine observations |
| 4–6 | Medium importance — standard operational context |
| 7–9 | High importance — key resolutions, critical server facts |
| 10 | Critical — never pruned, always surfaced |
Memory Scope
Memories are organization-scoped. Resolutions from one team member's session are available to all other members when Hive investigates similar issues — no manual knowledge sharing required.
Within a session, you can scope searches:
- Agent-specific — only memories from a particular server
- Organization-wide — all memories across the org
- Knowledge base — resolution memories only (issue + fix pairs)
Viewing Memories
Go to Hive → Memory to browse and manage stored memories.
| Column | Description |
|---|---|
| Type | Memory type (resolution, command, context, etc.) |
| Content | Summary of what is stored |
| Agent | Which agent the memory is associated with |
| Importance | Importance level |
| Expires | Expiry date (if set) — blank means no expiry |
| Created | When the memory was stored |
Adding Memories Manually
You can add memories by hand for facts Hive might not discover automatically.
- Go to Hive → Memory → Add Memory
- Select the type
- Write the memory content
- Set importance and optional expiry
- Associate with an agent (or leave org-level)
Example: Add a context memory that says "This server runs Ubuntu 20.04 with a custom kernel patch for net.core.somaxconn." Hive will reference this whenever diagnosing network issues on that server.
Memory Pruning
ops0 automatically prunes memories that are:
- Below a minimum importance threshold
- Past their expiry date
- Too old relative to their importance level
You can also manually delete any memory from the Memory page.
Embedding Cache
Memory search relies on semantic embeddings. ops0 caches embeddings to speed up search. If memory search seems slow or stale, the embedding cache can be cleared from Hive → Memory → Settings.
Privacy
All memories are scoped to your organization and never used to train external models. Memory content is not shared across organizations.