)
Last updated: October 27, 2026
What is the institutional memory problem in the age of AI agents? It is what happens when the work moves to agents but the know-how stays scattered across vendor memory features, chat logs and agent traces that your company does not control. Every decision an agent helps make teaches something, and unless you decide where that lives, it leaves with the tool, the account or the person.
TL;DR: Key Takeaways
- Agents are spreading fast. Microsoft's 2026 Work Trend Index (May 5, 2026) found active agents in Microsoft 365 grew 15x in a year, and calls institutional know-how that compounds over time "Owned Intelligence".
- Documentation helps. In the same report, documented, repeatable workflows were more common on Frontier teams, 26% against 19%.
- Vendor memory has limits. In Claude Managed Agents, a memory holds up to 100 kB, a store holds 10,000, and versions are kept for 30 days unless you export them.
- Moving memory is manual. Anthropic's help center calls memory import experimental and says Claude's memory focuses on work topics.
- Memory is an attack surface. OWASP (May 13, 2026) says persistent memory should be treated as security-relevant state.
Key Facts at a Glance
| Question | Short answer |
|---|---|
| What is it? | Know-how created while agents work, kept in places you do not own or cannot read |
| Why now? | Agents write memory, notes and traces as a side effect of every task |
| What is at risk? | Context, decisions and rules of thumb that took years to build |
| What is the fix? | Pick a home for that knowledge, keep it readable and exportable, and assign owners |
What Is the Institutional Memory Problem?
The institutional memory problem is the gap between what your organization knows and what it can retrieve, move or prove. With agents doing more of the work, the gap widens, because the reasoning behind each task lands in tools instead of in shared documents or people's heads.
The idea is old. Michael Polanyi argued in 1966 that people know more than they can put into words, and that tacit knowledge is the hardest to keep when someone leaves. Agents capture some of it as memories, notes and logs, but in formats built for the tool, not for the company.
According to Microsoft (2026), firms getting the most from AI turn what agents learn into shared routines, a result it calls "Owned Intelligence". That only works if you can reach the knowledge in the first place.
)
Where Does Know-How Live When Agents Do the Work?
Today it lives in five places: the memory features inside assistants, chat and session history, the notes agents write for themselves, the prompts and skill files that tell agents how to work, and the traces and logs of what they did. Most were built for the vendor's product, not for yours.
| Where it lands | What it holds | Who usually controls it |
|---|---|---|
| Assistant memory features | Preferences, project facts, working style | The vendor's settings and one person's account |
| Chat and session history | Drafts, reasoning, decisions | The individual user's account |
| Agent memory stores | Notes an agent writes for later sessions | Whoever runs the agent, if the store can be exported |
| Prompts, skills and config files | The rules of how work gets done | Whoever wrote them, often without version history |
| Traces and logs | What the agent did and why | Platform retention settings |
None of these is a bad place. The problem is treating them as a knowledge base, which has owners, structure and a way to leave. A chat history has none of those by default.
What Gets Lost When People, Tools or Vendors Change
Know-how goes missing at every handover: a person leaving, a switch of assistant, a vendor plan or feature change, a store reaching a limit, or an agent being retired. Each has a concrete failure and a concrete fix, and most fixes cost little if you make them before the change.
Vendor documentation shows the kind of limits to know about. In Claude Managed Agents, a store holds up to 10,000 memories and new writes fail when it is full. Versions are kept for 30 days, and Anthropic says to export through the API for longer history. These are reasonable limits, and a team should know them before relying on the store.
| Change | What goes missing | How to protect it |
|---|---|---|
| A person leaves | Their chats, personal memory and private prompts | Move work knowledge into shared, owned stores |
| You switch assistants | Memory does not travel by itself | Keep a plain-text export and test the import |
| A vendor changes limits or retention | Old versions, older notes | Export on a schedule, not on demand |
| A store reaches its limit | New writes fail | Review and curate entries |
| An agent is retired | Its notes, traces and the reasons behind its choices | Archive them and name an owner |
Moving between assistants shows how fragile this is. Anthropic's help center documents an import from another service and an export that asks Claude to write memories out verbatim, saved as a local file. It also says imports are experimental and that Claude's memory focuses on work topics, so some personal details may not be kept. There is no shared format yet.
Security and Governance: Memory Is Part of the Attack Surface
Memory that persists across sessions is trusted by later sessions, so a single poisoned entry can shape an agent's behavior for weeks. Treat it as data you govern, not a feature you switch on: map each store to a risk, limit who can write to it, and keep a way to review and delete what agents learned.
A May 13, 2026 post from the OWASP GenAI Security Project, written by the ASI06 entry lead, argues that memory and configuration files are part of an agent's trusted environment. It describes Cisco's MemoryTrap case, where a routine Claude Code workflow led to an injection that persisted into later sessions. Anthropic's docs give the practical advice: read-write stores can be poisoned, so use read-only stores for reference material.
| Risk | OWASP mapping | How it shows up in institutional memory | Control to ask for |
|---|---|---|---|
| Memory poisoning | LLM05:2026 Data and Model Poisoning, ASI06 Memory & Context Poisoning | A planted instruction in memory steers later work | Read-only stores for reference data, review of writes |
| Sensitive information disclosure | LLM02:2026 | Memory holds client, personnel and strategy facts | Know where it is stored and how it is deleted |
| Hidden context exposure | LLM08:2026 | Memory and config files carry internal rules or secrets | Keep credentials out of memory |
| Excessive agency | LLM03:2026, ASI02 Tool Misuse and Exploitation | An agent with write access to shared memory can change what the whole team relies on | Scoped write permissions and approval for high-impact changes |
| Goal hijack | LLM01:2026, ASI01 Agent Goal Hijack | Untrusted content ends up summarized into memory | Treat tool output and documents as untrusted input |
NeuralTrust is a Barcelona-based AI agent security company. Its Agent Posture Management (TrustLens) builds an inventory of agents, including ones nobody registered, and Agent Runtime Security (TrustGuard) inspects what agents read and do at runtime. Both are part of the Runtime Security Mesh and are separate from the memory product mentioned below. For the poisoning path in depth, read What is Memory & Context Poisoning?.
How to Fix the Institutional Memory Problem
You can fix it in six steps: inventory where agent knowledge lands, choose one readable home for what matters, export on a schedule, scope who and what can write, assign owners, and add memory to your offboarding and vendor reviews. None needs a new platform to start.
| Step | What to do | What you end up with |
|---|---|---|
| 1. Inventory | List every assistant, agent and tool that stores memory, notes or traces | A map of where know-how lands |
| 2. Choose a home | Pick plain-text or Markdown storage you control for what matters | Knowledge you can read without the vendor |
| 3. Export | Schedule exports beyond vendor retention, such as the 30-day version window | A copy that outlives any tool |
| 4. Scope writes | Read-only for reference material, reviewed writes for the rest | Less room for poisoning and drift |
| 5. Assign owners | One named owner per store, with a review rhythm | Memory that is maintained, not just accumulated |
| 6. Cover handovers | Add memory export to offboarding and to vendor and model changes | No knowledge lost at the door |
Start small: one team, one agent, one store and one monthly review is enough to learn what your agents actually remember.
The AI memory product NeuralTrust is launching is built around this idea of owning your AI memory. It connects places your knowledge already lives, such as Granola, Fathom, Google Calendar, ChatGPT and Claude history exports, Notion and Google Drive, with Slack, Gmail and Outlook coming soon. For the wider picture, read What is a Company Brain? and Who Owns Your AI Memory?.
Which Approach Fits Your Team?
Match the effort to the risk. Individuals can start with an export and a folder. Teams running agents need owned stores and review. Regulated companies also need retention, deletion and audit evidence from their vendors before agents carry the work.
| If you are | Start with | Add next |
|---|---|---|
| One person using several assistants | A plain-text export of your memory, saved in a folder you control | A monthly check of what each assistant remembers |
| A team running agents | A shared, owned store with read-only reference material | Reviewed writes and a named owner per store |
| A regulated company | An inventory of agents, stores and retention terms | Deletion, audit evidence and a vendor review for every memory feature |
Conclusion
The institutional memory problem is not that agents forget. It is that what they learn lands in places you cannot read, move or clean. Decide where know-how lives before agents do more of the work, keep it exportable, scope who can write to it, and give every store an owner. Start with one team and one store, review what your agents actually remember, and widen from there. Knowledge you can reach is knowledge you can build on.
Want to Keep Your Know-How? Let's Talk
NeuralTrust is launching an AI memory product for people and companies who want to own their AI memory. Book a demo and tell us where your agents' knowledge lives today.
Related Reads
FAQs about Institutional Memory Problem
1. What is the institutional memory problem?
It is the gap between what an organization knows and what it can find, move or prove. With AI agents doing more work, know-how ends up in vendor memory features, chat history and agent traces that the company does not control, so it can be lost when a person, tool or vendor changes.
2. What is institutional memory?
Institutional memory is the collective knowledge, decisions and ways of working that an organization builds over time. It includes written records and also tacit know-how, such as why a choice was made. Microsoft's 2026 Work Trend Index calls the part unique to a firm and compounding over time "Owned Intelligence".
3. How do AI agents affect institutional memory?
Agents write memories, notes and traces as they work, which can capture useful context. But those records usually sit in formats and places built for the tool, tied to individual accounts or short retention windows. Without owners and exports, the knowledge is hard to reuse or move.
4. Where is agent memory stored?
It depends on the platform. Assistants keep memory inside the vendor's service, and agent platforms such as Claude Managed Agents store memories as text documents in stores with versions. Chat history sits with the user's account. Ask each vendor where memory lives, how long it is kept and how to export it.
5. Can I move AI memory between assistants?
Sometimes. Anthropic's help center documents importing memory from another service and exporting it as text, but calls imports experimental. There is no shared format yet, so test an import before depending on it, check what the new assistant actually kept, and keep a plain-text copy of your memory.
6. Is agent memory a security risk?
Yes. Memory persists across sessions, so a poisoned entry can shape later behavior. OWASP lists memory and context poisoning as ASI06 in its Agentic Top 10 and said in May 2026 that memory should be treated as security-relevant state. Use read-only stores for reference data and review writes.
7. How do I protect institutional memory when employees leave?
Move work knowledge out of personal accounts into shared stores with named owners, export on a schedule, and add memory to your offboarding checklist. Keep reference material read-only, and review what each assistant and agent has stored about work before access ends.
About the Author
Roger Howroyd is Head of Global SEO and AI at NeuralTrust, where he leads the company's search strategy across SEO, AEO, GEO, and LLM optimization. He specializes in AI-powered search, content strategy, and SEM. Connect on LinkedIn.
NeuralTrust is the leading platform for securing and scaling AI agents. Named a Pioneer in the Gartner Emerging Market Quadrant for AI Application Security 2026, recognized across four Gartner Hype Cycle reports in 2026, and featured in the Gartner Market Guide for Guardian Agents 2026, the Gartner Market Guide for AI Gateways 2025 and the KuppingerCole Leadership Compass for Generative AI Defense 2025. Headquartered in Barcelona with offices in London and New York. ISO 27001 certified.
Sources
- Microsoft WorkLab, 2026 Work Trend Index Annual Report, May 5, 2026.
- Michael Polanyi, The Tacit Dimension, 1966.
- Anthropic, Memory for Claude Managed Agents, April 23, 2026.
- Claude Platform Docs, Using agent memory, accessed October 27, 2026.
- Claude Help Center, Importing and exporting your memory, accessed October 27, 2026.
- OWASP GenAI Security Project, Memory Is a Feature. It Is Also an Attack Surface, May 13, 2026.
- OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2026, August 3, 2026.
- OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications, December 2025.
)
)
)
)