Anthropic Agent Memory: Tools, Storage, and Project Context
Claude's context window is not persistent memory. Anthropic's API provides tools for supplying state to a model, but persistence across sessions is something a developer builds. This guide explains the distinction and the options.
Updated 4 min read
Claude does not remember previous conversations by default. Each API call receives the messages you send and returns a response; when the call ends, no state is retained by the API. Persistence across sessions is something a developer supplies, using tools available in the API or through an external store.
Anthropic distinguishes between in-context state (what is in the current messages array), tool-retrieved state (what a model reads by calling a tool), and product-level memory (available in Claude.ai's Projects feature but not the API). For production agent work, the developer is responsible for all three. Tools like fenbs keep shared project facts and decisions outside runtime storage, so the record is available to any session without being rebuilt each time.
In-context state: what the model can see now
The messages array is the model's working memory for one session. Everything you include — the system prompt, earlier turns, tool results — is visible to the model for that call. Nothing persists automatically when the session ends.
In-context state is limited by the context window (the maximum number of tokens in one call). Long sessions accumulate many tokens. Developers manage this by summarizing older turns, truncating history, or selectively including only the relevant parts of previous exchanges.
Tool-retrieved state: reading from storage
Tool use in the API lets a model call a function you define. That function can read from a database, a file, a vector store, or any accessible service. The result comes back as a tool result message and the model uses it in its next response. This is how an agent reads from persistent storage without that storage being part of the context window from the start.
- Define a tool that reads from your storage (a database query, a file read, a search endpoint).
- The model calls the tool when it needs information it does not have in context.
- The tool result is added to the messages array and the model continues.
- The storage itself is not inside the API — you own and manage it.
See what is agent memory for the full taxonomy of memory types, and how to build agent memory for implementation patterns.
Product-level memory: Claude.ai Projects
Claude.ai Projects (shared memory added September 17, 2026) keep instructions and uploaded files across sessions within that product. This is a Claude.ai interface feature, not an API feature. You cannot access it through the Anthropic API. If you are building a product that uses the API, you supply persistence yourself.
Memory architecture patterns for agents
Most agent memory architectures combine at least two layers: short-term state in the context window for the current task, and long-term storage outside the model for facts that persist across sessions. The agent reads from long-term storage at the start of a session and writes back before it ends.
| Layer | Where it lives | What it holds |
|---|---|---|
| In-context | Messages array, current session | Current task, tool results, conversation so far |
| External storage | Your database, file, or vector store | Facts, documents, previous session summaries |
| Project context | Shared record outside the model | Rules, decisions, where things were left, glossary |
The third layer — shared project context — is what fenbs provides. It is not a runtime storage system for agent tool calls; it is a record of the work that a person and an assistant maintain together and that any connected assistant reads before starting.
Keep shared project facts outside runtime storage
Add the project to fenbs. Write the rules, the decisions, and the project state as Decisions and rules and Where we left off entries. Every connected assistant reads those before starting a session — not as tool-retrieved data, but as the agreed context for the project.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
What to put in each layer
Short-term, session-specific data belongs in the context window: the current task, the tool results from this session, the conversation so far. Facts that need to persist across sessions — user preferences, a summary of what was done last time, domain knowledge the agent refers to often — belong in external storage.
Durable project context — the rules that govern the agent's behavior, the decisions that shaped its design, where the work stands — belongs in a shared record that people and assistants maintain together. That is not runtime data; it is the governing context that a developer or a new assistant needs before they change anything.
Agent memory and security
Agent memory that persists across sessions creates security considerations. What can the agent write to storage? What can it read? Can a user manipulate stored facts to change the agent's behavior in a future session? These are design questions to answer before the system handles real data.
For the security angle, see agent memory security. For the choice between memory and RAG, see agent memory vs RAG. For MCP-based memory tools, see agent memory MCP.
How to do this with fenbs
- Create a free account and add a project for the agent system you are building.
- Write the agent's design decisions in Decisions and rules: the storage approach chosen and why, the access boundaries, and what the agent must not write.
- Connect Claude or Claude Code to fenbs from Integrations. The assistant reads the project context before each development session.
- When the agent design changes because testing revealed a problem, update the decisions and record the lesson.
- Before each session ends, save progress: where the implementation stands and what the next step is.