Memories
Saved context your agent can carry into future work.
A memory is a saved piece of context your agent can use later: a preference, fact, correction, constraint, or team detail that should carry across future work.
Context worth keeping
Memories keep stable context from becoming setup work. If leadership updates should lead with risk, movement, and next actions, the agent can remember that.
That context carries into future threads. A RevOps agent can start Monday's pipeline review already knowing the format, fields, and risk language. A Customer Success agent can prepare a renewal brief with the account conventions your team uses.
That is what memories are for: useful context that should travel with the agent instead of living only in old conversations.
Anatomy of a memory
Each memory has a few fields that control what it says, when it appears, and which agents can use it.
| Field | What it controls |
|---|---|
| Memory content | The fact, preference, correction, constraint, or context the agent should remember. |
| Category | The kind of memory: preference, project context, domain knowledge, active work, tools and workflows, and more. |
| Importance | Whether the memory should load upfront. Memories rated 4 or 5 are always included for agents that can access them. |
| When to use | Guidance that helps the memory surface on the right requests. This text is part of memory retrieval. |
| Tags | Search and organization signals. Tags help retrieval, can be expanded with related terms, and make the Memories page easier to filter. |
| Archive | Removes stale context from active use without losing the record. |
What belongs in a memory
Good memories are stable enough to matter beyond the current thread. They are facts, preferences, corrections, and constraints the agent should not need to rediscover.
👤User Fact
✍️Preference
📁Project Context
📚Domain Knowledge
🤝People
🎯Active Work
🔧Tools & Workflows
🏢Organization
Not everything should become a memory. Current deals, one-off numbers, temporary plans, and details that only matter inside one run usually belong in the thread, a table, a document, or the connected system where they came from.
How memories show up
A thread does not start with every memory loaded. Hyperagent brings memory context in based on scope, importance, and what the conversation is about.
⭐Always included
High-importance memories load at the start of the thread.
🔎Surfaced by relevance
Matching memories appear when the request calls for them.
🧠Requested directly
You can point the agent at saved context by name or topic.
Memories rated 4 or 5 load at the start of the thread for agents that can access them. In the UI, this is shown as Always include.
Use this for context the agent should usually have before work begins: your role, operating standards, core team details, or rules that should shape most runs.
Other memories can surface as the thread develops. Before the agent responds, Hyperagent searches memory content, When to Use, and tags for matches to the request.
Specific terms carry more weight than generic ones. A memory about Stripe can also match billing or payments if related tags were added in the background.
You can point the agent at saved context directly. Ask what it knows about your renewal process, reference a memory, or name the context you want used.
The agent can then search its knowledge base and bring the right memory into the thread.
This keeps the thread focused. The agent does not need every memory loaded at once. It starts with the context it should always know, then brings in more as the work calls for it.
Scope and access
Memory scope controls which agents can use a memory.
🌐Global memories
Visible to all your agents. Use them for company positioning, writing standards, your role, operating principles, or facts every agent should know.
🤖Agent-associated memories
Linked to a specific agent. A memory associated with Hyperagent | Documentation helps that documentation agent without crowding unrelated agents.
Always include respects scope. If a global memory is rated 4 or 5, it loads upfront for every agent. If an agent-associated memory is rated 4 or 5, it loads upfront only for that agent's threads.
Creating and managing memories
Memories usually start in a real run. You correct a detail, state a preference, explain a team rule, or tell the agent something it should remember for next time.
- Suggestions in the thread. When the agent notices something worth saving, it proposes a memory as a draft card. You can save it, edit it, adjust its importance, or dismiss it before it becomes long-term context.
- Auto-save. If auto-save is enabled, the agent can save memories without showing a draft card first. Use this for personal agents you trust to learn from the conversation. Keep it off for shared agents, especially in team channels.
- Suggested learnings after a run. At the end of a conversation, the agent can review the work and propose memories worth keeping. Those suggestions appear in Learning, where you can accept, edit, or dismiss them.
- Manual creation. You can create memories directly in Learning when you want to front-load context before the first conversation.
The same flow shows up in two places: suggestions inside the thread, and the Memories view inside Learning.
Keeping memories current
Once a memory is saved, keep it current from Learning:
- Review and edit saved memories when a team restructures, a target shifts, or a process changes.
- Adjust importance when a memory should always load, or when it should only surface around a specific topic.
- Set scope so a memory is global or associated with the right agent.
- Delete memories that are no longer accurate. Stale context is worse than no context.
- View version history so you can see what changed and when.
The goal is accuracy. A smaller set of current, well-maintained memories is more useful than a large set of stale ones.
Over time, this reduces setup. A RevOps agent can start Monday's pipeline review already knowing the format, metrics, and channels. A Customer Success agent can prepare for a renewal call with the right account-health conventions already in view. Global memories help broadly; agent-associated memories deepen the context for one configured teammate.
Memory vs. skill vs. thread context
Memories work alongside skills and the Thread Context Document, but each solves a different problem.
| Concept | What it saves | Scope | Example |
|---|---|---|---|
| Memory | Context the agent should remember later | Global or associated with specific agents | "Leadership updates should start with risk, movement, and next actions." |
| Skill | A reusable method for doing work | Portable across agents | "How to prepare the weekly pipeline summary." |
| Thread Context Document | Facts, corrections, decisions, and plan details for one thread | One thread only | "In this run, use the corrected $5.5B valuation." |
A memory is not a process document. If the agent needs to remember that updates go to #exec-updates, that is a memory. If it needs to learn the full process for writing the weekly update, that is a skill. If it needs to remember that you corrected a number ten minutes ago in this conversation, that belongs in the Thread Context Document.
Memory FAQs
Memories are saved context your agent can use in future work: preferences, facts, corrections, constraints, and team details. They help the agent work with your standards and context without making you repeat the same briefing in every thread.