# Memories Source: https://www.hyperagent.com/docs/concepts/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 [#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 [#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 [#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. Who you are: your name, role, company, location, and other stable personal details. How you like work delivered: tone, format, source style, level of detail, naming conventions, or units. What you are building or working on: tech stack, constraints, timelines, goals, and project-specific decisions. Subject expertise the agent should understand: industry terms, technical concepts, market definitions, or regulatory context. Colleagues, contacts, teams, customers, and relationships the agent should recognize when they come up. Current projects, ongoing initiatives, deals in flight, and other work that is in progress and shapes how the agent should prioritize. Systems you use, how they connect, process patterns, and operational conventions the agent should follow. Company structure, team channels, operating rhythm, approval chains, and other institutional context. 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 [#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. High-importance memories load at the start of the thread. Matching memories appear when the request calls for them. 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 [#scope-and-access] Memory scope controls which agents can use a memory. Visible to all your agents. Use them for company positioning, writing standards, your role, operating principles, or facts every agent should know. 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 [#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 [#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 [#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. ## FAQs [#faqs] Save a memory when the context should help future work: a preference, stable fact, team rule, recurring destination, correction, or constraint. If you expect to say the same thing again in another thread, it probably belongs in memory. Do not save details that only matter to the current run, like today's working plan, temporary numbers, or one-off notes. Those usually belong in the thread, Thread Context Document, a document, a table, or the source system. A memory preserves context. A skill teaches a method. "Use AP style for blog drafts" is a memory. "How to draft and edit a launch blog post" is a skill. No. Memories rated 4 or 5 are visible from the start only for agents that can access them. Other memories surface when the topic becomes relevant or when you ask the agent to search for specific context. This keeps threads cleaner and leaves more room for the task itself. Yes. Memories should stay accurate. Update stale details, remove anything no longer true, and keep important context clear enough for the agent to use later. Rate 4 or 5 for context the agent should always carry: your role, team structure, operating conventions, and key constraints. Rate 1 to 3 for details that matter when relevant but do not need to be present in every conversation: specific account details, one-off preferences, or project-specific facts. A global memory is visible to all your agents. If it is rated 4 or 5, it loads upfront for every agent. A non-global memory is associated with specific agents, and only those agents can use it. Yes. Hyperagent searches memory content, tags, and the When to Use field when deciding which memories are relevant to a request. Specific tags and precise When to Use guidance help the right memory surface at the right time. Only if you turn on auto-save for that agent. By default, memories are proposed as drafts you review before saving. Auto-save is useful for personal agents you trust to learn from the conversation. For shared agents, keep it off. 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.