# Knowledge access Source: https://www.hyperagent.com/docs/concepts/agents/knowledge-access Control what an agent can see, what it keeps to itself, and what it learns from each run. **Knowledge access** controls the context an agent can bring into a run and what happens when the agent learns something new. It is the boundary between your wider library, the knowledge deliberately attached to this role, and the material other people may add through conversation. That boundary matters as soon as an agent leaves a private thread. A Slack agent should not pull a personal preference into a public channel. A shared specialist should not turn every piece of channel chatter into lasting memory. ## What the agent can learn [#what-the-agent-can-learn] Self-learning decides whether a run may turn conversation into reusable knowledge. The master control opens a row for each kind of change: * **Memory suggestions** capture facts and preferences worth carrying forward * **Skill suggestions** capture reusable methods * **Prompt suggestions** improve the role instructions * **Agent configuration changes** propose updates to the agent itself Each row can be **Off**, **Suggested**, or **Auto-saved** when that option is available. Suggested changes wait for review. Auto-saved changes apply without a click-through. For an agent only you use, suggestions or auto-save can reduce repeated briefing. For an agent other people can invoke, start with learning off or suggestions only. Open the boundary after you have seen the real traffic, not before. ## Where memories come from [#where-memories-come-from] Two choices shape memory behavior. ### Which memories can the agent see? [#which-memories-can-the-agent-see] * **Everything in the library** gives the agent the wider personal or Team Library pool * **Only curated memories** limits the agent to memories explicitly linked to it Use the wider pool for a private coworker that should understand your standing context. Use curated access for channel-facing agents and roles with a narrow knowledge boundary. ### Where should learned memories go? [#where-should-learned-memories-go] * **The personal or Team Library** makes the new memory available to other agents that can use that library * **This agent's memories** keeps the learning with this role A shared specialist usually saves to itself. A private generalist may save to your wider library so other personal agents benefit. Team agents use team and agent-owned knowledge rather than the running teammate's private memory library. Depending on the team setup and your workspace role, you may see Team Library controls or a simplified agent-owned view. Owners and editors manage what gets linked. More on [team knowledge management](/docs/concepts/teams). ## Linking and pinning [#linking-and-pinning] Linking makes a memory or skill available to this agent. Pinning tells Hyperagent to place that item into **every run**, regardless of discovery. Link memories and skills the role may need. Hyperagent can retrieve linked knowledge when the current work calls for it. Pin the small set of memories and skills the role must carry on every run: a quality standard, operating policy, or core method. Do not pin the whole library. Always-loaded context competes for space with the live conversation, tool results, and the work itself. ### Skills [#skills] The Skills section shows the methods explicitly attached to the agent. If skill discovery is on, the agent can also find other global skills or skills shared with its team. A pin icon marks skills that load on every run. ### Context files [#context-files] Attach documents and generated files when the role needs a stable source to reference. Context files do not use the same pin control as memories and skills on this surface; attaching them places them directly on the agent. ## Past conversations [#past-conversations] **Thread search** lets the agent search its own past conversations. It is separate from memory access: memories are curated knowledge objects, while thread search reaches prior discussion and tool history. Turn it on when continuity across conversations is part of the job. Leave it off for roles where each run should stay isolated, especially when many people can invoke the same agent. ## Defaults that work [#defaults-that-work] Let the agent see your broader library. Start with suggestions, then auto-save only the categories you trust. Link the playbook, policies, and skills the role needs. Keep channel chatter out of lasting knowledge until you have reviewed the traffic. Keep the role narrow. Save new learning to the agent so the team benefits without writing into a teammate's private library. ## FAQs [#faqs] No. Knowledge access covers memories, skills, context files, learning, and past-thread search. Tools and integrations control the actions and connected systems the agent may use. Start with only curated memories and learning off. Link the exact memories, skills, and files the channel role needs. Broaden access only after you have inspected real runs. Pin only knowledge that must appear in every run: the core operating policy, a required format, or the role's primary method. Link everything else so it can be retrieved when relevant. No. Thread search finds prior conversations. Memories are structured facts and preferences designed to travel across runs. You can attach documents and generated files as context files. They are carried on the agent rather than pinned through the memory or skill controls. Run access does not automatically grant configuration access. Workspace owners and editors manage the Team Library and what is linked to team-owned agents.