I built a folder-based memory that can't mix data across clients (open source, MIT)

You've probably seen Anthropic's "dreaming" feature - the scheduled process that reviews an agent's past sessions, pulls recurring patterns out of them, and curates a memory layer that future sessions read instead of the raw logs. As Anthropic describes it, it's a framework more than a single endpoint: you design the consolidation around your own setup.

So I did, for my agency running on Claude Code. The kit is a concrete, folder-based implementation of that same loop: a weekly pass reviews your past sessions, extracts the durable learnings, and curates them into a memory layer each new session loads. By my own cost math - standing this up the way the dreaming write-ups describe versus what the kit actually costs to run - it comes out roughly 97% cheaper.

The dreaming input, as described, is the session record: inputs, outputs, tool calls, reasoning, outcomes - the whole log. The kit throws almost all of that away before it spends a token. It strips every tool call and tool result (the scraped pages, the file dumps, the command output, the bulk of any Claude Code session) and sends only the user/assistant text turns to consolidate. If I were to run this as Anthropic designed it, it would cost me roughly $150-250 per month, but with this filtering it only costs me $5 (in API costs).

What it does that the managed feature doesn't:

- No managed memory service in the middle. To be precise: inference still goes to the Anthropic API on your own key, same as any Claude Code call. It's fully local, but the memory itself is plain markdown in folders you own and git-version, not a black box you query through someone else's service. The only thing that leaves your machine is that filtered slice you'd already be sending to the model anyway.

- Shared learning without the leak. During your actual work the load is per-client and deterministic, so client A's data can't surface while you're on client B. The one place the kit reads across clients is a deliberate weekly pass that abstracts recurring findings into a cross-client patterns file - and it's built to write agency-level rules, not specifics. You get the pattern, not the bleed. Anything ambiguous is quarantined for you to file, never guessed.

Now the problem it solves, and how.

If you run more than one client or project through Claude Code, you've probably hit the same wall I did: the memory layer.

Most "AI memory" tools use one global vault. A single shared pile the model reads and writes across everything. For a single workspace that's fine, but the second you have client A and client B in the same setup, it's a liability. A's context can surface while you're working on B. Once you've seen it happen, you stop trusting it.

So I built the opposite, and it leans hard into the folder-architecture idea this community teaches:

> The client folder is the single source of truth. There is no global vault.

Nothing leaks across clients because there's no shared pile to leak through. The mechanics, for the people who care about how it actually works:

- LOAD is deterministic. A UserPromptSubmit hook injects a fixed load order (a context-load-order.md you control) for the task at hand. No fuzzy similarity search that might pull the wrong client's files.

- CAPTURE is agent-driven into the one folder the session is actually about. The protocol lives in CLAUDE.md, so the agent writes learnings where they belong.

- AMBIGUITY goes to a quarantine inbox. When it's genuinely unclear which client a learning belongs to, it's parked for you to file by hand. Never guessed.

- ENGINE and DATA are separate. The plugin is the engine (hooks + scripts + config schema). Your agency is a "world": a folder with clients/ and system/memory/. One engine, many worlds. Section names and language live in a world.json you own, so the engine ships English defaults but a Hungarian (or any) world overrides them without touching the plugin.

- WEEKLY consolidation is lossless and approval-gated. It dedups/merges each client's learnings, regenerates cross-client patterns, and surfaces candidates - durable rules worth promoting, stale entries proposed for archiving. Nothing is archived or promoted without your say-so. It also mines your transcripts for recurring tool mistakes and proposes them as guard rules (warn-only until you explicitly harden one).

Where it's going next (this is the current roadmap, not a promise):

- Stronger no-mixing guard. Today no-mixing is enforced hard on the automated mining path, but the primary path - the agent writing a learning at session end - leans on the protocol, not a gate. Adding a pre-write guard that warns when a learning filed under client A mentions client B, so a compacted session can't quietly write to the wrong folder.

- Typed learnings. Right now captured candidates are flat (scope + text). Giving each a lightweight type (decision / learning / gotcha / result / rule) plus a concept tag, so review is faster and the type can drive where an accepted learning actually lands.

- Leaner context injection. The load-order hook currently injects the full table on every prompt. Moving to a compact per-prompt reminder plus the full table once at session start and again right after a compaction. Same behavior, fewer tokens.

- Closing the tool-craft loop. The weekly run already mines recurring tool mistakes and proposes guard rules. Next: the approved advisory rules actually surface back in context, and a rule that keeps getting violated escalates from warn to block visibly, instead of the counter sitting unread.

- More robust capture. Overlapping the weekly mining window so a single missed run doesn't silently drop that week's learnings, plus a real test harness around the pipeline that rewrites your learnings files.

This is a first attempt at agency memory, developed by me (a marketing guy, not a software developer) for my own company, so expect rough edges. Nothing overwrites your hand-curated files or archives anything without approval, you're still the last line of defense.

It's a Claude Code plugin, MIT, free, bring your own API key. Two weeks of private beta with my business partner, zero data mixing.

Repo: agency-memory-kit

If you're running a multi-client or multi-project setup, I'd genuinely like to know where this breaks for you.

Fork it, tear it apart, and tell me what's missing!

Enjoy :)

0 comments

I built a folder-based memory that can't mix data across clients (open source, MIT)