How the community manages memory in Claude agents

The problem of memory in AI agents is not new, but it still lacks a canonical solution. This week, a thread on Hacker News asked the community directly: what memory system are you building? The question, simple on the surface, touches one of the most tangible friction points in daily work with Claude and other models: the persistence of context between sessions.

Beyond academic use cases, what's interesting about the thread is that it shows how real teams, not research labs, are solving this with limited resources and within the current ecosystem constraints.

The problem everyone has but few discuss openly

Claude Opus 4.8 offers an optional context window of up to 1 million tokens, which technically allows loading large volumes of information in each call. However, this approach carries non-trivial inference costs and doesn't scale well when projects grow or when the agent needs to remember past interactions selectively. Loading the entire history in each prompt isn't memory: it's brute force.

The patterns that emerge in conversations like this typically group into three categories:

Structured text files (markdown or YAML). The simplest and surprisingly common approach. The agent writes and reads files with session summaries, decisions made, or user preferences. Claude Code facilitates this natively through lifecycle hooks: a `Stop` hook can trigger a script that summarizes the session and updates a `memory.md` file. No external dependencies, no network latency.

MCP servers with vector storage. The next level of sophistication. A specialized MCP server is configured, typically backed by an embedded database like LanceDB or ChromaDB running locally, which exposes semantic search tools. The agent queries relevant memories based on current context, without needing to load everything. This architecture is configured in `claude_desktop_config.json` or directly in Claude Code, and several open source projects already offer ready-to-use implementations.

Skills with preloaded context. Less oriented toward persistence between sessions and more toward coherence within a task: packages of instructions that include project context, code conventions, or team preferences. They don't replace durable memory, but they reduce the need to repeat context in each prompt.

Why this conversation matters now

The discussion comes at a moment when Claude Code has matured enough for small teams to build production agents without needing heavy external frameworks. Subagents, hooks, and MCP servers provide sufficient primitives to implement memory in a modular way. The problem is no longer purely technical: it's a design question.

What should an agent remember and what should it forget? When does accumulated memory start degrading performance instead of improving it? How do you manage privacy when the agent saves information between sessions? These questions have no answer in official documentation, and they're precisely where community patterns emerge.

For teams working with Claude on long-duration tasks, such as code review, iterative technical support, or continuous documentation generation, having a well-designed memory layer makes an appreciable practical difference. Not in terms of the model's capabilities, but in the agent's coherence and usefulness over time.

Who finds this useful

These kinds of open conversations are especially valuable for three profiles: developers just starting to build their first agents with Claude Code and looking for practical references; teams that already have something working but suspect their solution won't scale; and those evaluating whether it's worth investing in a custom MCP server or if a file-based approach covers their needs for the coming months.

There's no universal answer. The complexity of a memory system should be proportional to the complexity of the agent's tasks. An agent that helps draft emails doesn't need the same thing as one managing the full lifecycle of support tickets.

---

For months at ClaudeWave we've seen how the lack of established patterns in this area forces each team to reinvent the wheel. A community repository of memory architecture references for Claude Code would, at this point, be more useful than another quickstart tutorial.