# How to Implement Memory Mount for Shared Knowledge in Analyst Sessions

> Learn to implement memory mount for shared knowledge in analyst sessions by supplying a memory_store resource with read_write access when creating your session.

- Repository: [Anthropic/cwc-workshops](https://github.com/anthropics/cwc-workshops)
- Tags: how-to-guide
- Published: 2026-07-21

---

**To implement a memory mount for shared knowledge, supply a `memory_store` resource with `read_write` access when creating the analyst session via `client.beta.sessions.create()`.**

The research-desk workshop in the `anthropics/cwc-workshops` repository demonstrates how to build persistent, collaborative AI analyst sessions. By implementing a **memory mount for shared knowledge**, you enable analyst agents to read historical research notes and write new findings to a centralized, versioned memory store that survives beyond individual session lifetimes.

## Understanding the Memory Store Architecture

The shared research memory is stored in an Anthropic **memory store**—a persistent, versioned object that functions as a virtual filesystem. According to the source code in [`src/lib/provision.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/provision.ts), this store organizes knowledge under hierarchical paths such as `/companies/<TICKER>/` for company-specific filings and `/memos/` for desk-level communications.

When mounted, the memory store appears to the agent as a local filesystem, eliminating the need for explicit API calls to persist data. This architecture provides **zero-API-overhead** persistence where any note written by one session becomes immediately available to subsequent sessions.

## Step-by-Step Implementation

### Create the Memory Store

Before mounting, you must provision the memory store. In [`src/lib/provision.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/provision.ts) (lines 20-27), the workshop initializes the store using the Anthropic client and persists the returned ID in the configuration:

```typescript
// research-desk/src/lib/provision.ts
const memoryStore = await client.beta.memoryStores.create({
  name: "desk-memory",
  description:
    "The research desk's accumulated knowledge: one note per company per filing under /companies/<TICKER>/, " +
    "plus desk-level memos under /memos/. Read before re-analyzing a company; notes persist across sessions.",
} as never);
cfg.memory_store_id = memoryStore.id;

```

The `memory_store_id` is then stored in `cfg.memory_store_id` for later use when mounting.

### Define Mount Instructions

Mount instructions tell the agent how to interact with the filesystem. In [`src/lib/analysis.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/analysis.ts) (lines 19-22), the constant `MEMORY_MOUNT_INSTRUCTIONS` provides contextual guidance:

```typescript
// research-desk/src/lib/analysis.ts
export const MEMORY_MOUNT_INSTRUCTIONS =
  "The desk's shared research memory. Before analyzing a company, read your prior notes for it under " +
  "/companies/<TICKER>/ if any exist. After analyzing, write or update one note per filing at " +
  "/companies/<TICKER>/<fiscal-period>-<form>.md using the note template from your instructions.";

```

These instructions ensure the agent knows where to look for existing research and where to save new analyses.

### Mount the Memory Store in Session Creation

The critical step occurs when creating the analyst session. In [`src/lib/analysis.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/analysis.ts) (lines 77-93), you must include the memory store in the `resources` array with `type: "memory_store"`:

```typescript
// research-desk/src/lib/analysis.ts
export async function analyzeTicker(
  client: Anthropic,
  cfg: DeskConfig,
  ticker: string,
  focus = "",
  record: AnalysisRecord = newRecord(ticker),
): Promise<AnalysisRecord> {
  // Create the analyst session with the memory mount
  const session = await client.beta.sessions.create({
    agent: cfg.analyst_agent_id,
    environment_id: cfg.environment_id,
    title: `Filing analysis: ${record.ticker}`,
    metadata: { ticker: record.ticker, kind: "analysis" },
    resources: [
      {
        type: "memory_store",
        memory_store_id: cfg.memory_store_id,
        access: "read_write",
        instructions: MEMORY_MOUNT_INSTRUCTIONS,
      },
    ],
  } as never);
  record.sessionId = session.id;
  // ... remaining implementation
}

```

The `access: "read_write"` parameter grants the agent permission to both consume existing knowledge and contribute new findings.

## Reading and Writing Shared Knowledge

Once mounted, the memory store operates as a virtual filesystem accessible via standard path conventions.

### Accessing Existing Research Notes

Client applications can retrieve stored notes through the API endpoint defined in [`src/app/api/desk/memory/route.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/app/api/desk/memory/route.ts). For example, to read a previous 10-K analysis:

```typescript
// Example client-side fetch to read mounted memory
const { memory } = await fetch(
  `/api/desk/memory?path=${encodeURIComponent("/companies/AAPL/2023-Q2-10K.md")}`
).then((r) => r.json());

console.log(memory?.content); // Outputs the stored markdown analysis

```

The agent accesses these same paths internally through the mounted filesystem without requiring explicit HTTP calls.

### Persisting New Analysis Results

When the agent writes content to a path within the mounted memory store, the platform automatically persists it. The agent simply outputs file content to a specific path:

```markdown
path: /companies/TSLA/2024-Q1-10K.md
content: |
  # TSLA 2024-Q1 10-K Summary

  Key findings from the quarterly filing analysis...

```

This write operation creates a new version in the immutable memory store, making the research immediately available to future analyst sessions without additional database configuration.

## Key Files and Implementation Details

The memory mount implementation spans several key files in the `research-desk` directory:

- **[`src/lib/config.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/config.ts)**: Defines the `DeskConfig` interface including `memory_store_id`
- **[`src/lib/provision.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/provision.ts)**: Handles `client.beta.memoryStores.create()` and initial setup (lines 20-27)
- **[`src/lib/analysis.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/analysis.ts)**: Contains `MEMORY_MOUNT_INSTRUCTIONS` and the session creation logic where mounting occurs (lines 19-22 and 77-93)
- **[`src/lib/memory.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/memory.ts)**: Provides helper functions for listing, reading, and versioning memories
- **[`src/app/api/desk/memory/route.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/app/api/desk/memory/route.ts)**: API endpoint serving memory contents to the frontend

## Summary

- **Provision first**: Create the memory store using `client.beta.memoryStores.create()` in [`src/lib/provision.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/provision.ts) and store the returned ID in your configuration
- **Mount with resources**: When calling `client.beta.sessions.create()`, include a resource object with `type: "memory_store"`, the stored `memory_store_id`, and `access: "read_write"`
- **Provide instructions**: Include `MEMORY_MOUNT_INSTRUCTIONS` to guide the agent on where to read historical data and write new analyses under `/companies/<TICKER>/` paths
- **Zero-overhead persistence**: The mounted store behaves like a local filesystem, enabling agents to read and write research notes without explicit storage API calls
- **Shared across sessions**: All analyst sessions access the same memory store, enabling cumulative knowledge accumulation that survives individual session lifetimes

## Frequently Asked Questions

### What is a memory mount in Anthropic analyst sessions?

A memory mount is a resource attachment that exposes an Anthropic memory store as a virtual filesystem within an analyst session. When you mount a memory store using the `resources` array in `client.beta.sessions.create()`, the agent can read and write files under paths like `/companies/<TICKER>/` as if they were local files, enabling persistent shared knowledge across multiple sessions.

### How does the memory store handle concurrent writes from multiple sessions?

The memory store is immutable per file; updates create new versions rather than overwriting existing content. This versioning system allows multiple analyst sessions to write to the same memory store simultaneously without data loss, as each write generates a distinct version that can be tracked through the helper functions in [`src/lib/memory.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/memory.ts).

### Can I restrict an analyst session to read-only access?

Yes. When mounting the memory store in the `resources` array within [`src/lib/analysis.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/analysis.ts), change the `access` parameter from `"read_write"` to `"read"`. This restricts the agent to consuming existing research notes without allowing modifications to the shared knowledge base.

### Where are memory store files actually stored?

The memory store is managed by Anthropic's platform infrastructure, not local storage. When you call `client.beta.memoryStores.create()` in [`src/lib/provision.ts`](https://github.com/anthropics/cwc-workshops/blob/main/src/lib/provision.ts), the platform provisions a persistent, server-side object. The virtual filesystem paths like `/companies/<TICKER>/` are abstractions provided by the mount mechanism, with actual storage handled by the Anthropic memory service.