Last week, I tried out Jake's icm-architect skill, which he also posted here. There were a few legitimate issues the skill found that needed fixing, and I quickly patched those in my infrastructure. What surprised me, though, was that the structural part itself (which I built before I joined here and started learning about Jake's ICM methodology) was not only completely fine, but when applied to my use case, it was even better than what the skill suggested. Jake's skill is set up for fairly general use cases, as well as for people who don't know how to organize a specific idea or project in a way that works well for agents. After I patched the holes the icm-architect skill found, I gave it some thought and created my own version. I named it Agency ICM Builder. https://github.com/krsnczky/agency-icm-builder The difference is in what it assumes. One folder per client, and keeping them apart is rule two, not an afterthought: any learning whose client is ambiguous goes to a quarantine inbox instead of getting guessed into the wrong folder. In an agency, cross-client bleed isn't untidy, it's a liability. Expertise and state are split the same way, by construction. Departments hold what's true for a service across every client, client folders hold per-client state, and the two never mix. A few weeks ago, I posted here about my memory system, for which I created a public plugin, and this new skill complements it perfectly. You could say the memory kit is the soul/brain of my infrastructure, and this skill helps you build the body around it. Once you plug the memory kit in, you'll have a very strong foundation for your infrastructure. https://github.com/krsnczky/agency-memory-kit It won't fit everyone. If you're not doing client work at all, the client separation is dead weight and Jake's icm-architect is the better starting point. And if you want a framework with a database and orchestration code, this isn't that either. It's markdown files in folders, and that's the whole design.

I’ve been building our agency operating system inside Claude Code, and memory quickly became one of the harder architectural problems. Most AI memory systems use a global store with similarity-based retrieval. That can work for a single project, but it becomes risky when the same system handles multiple clients. Relevant context for one client should never be retrieved while working on another. So I built Agency Memory Kit around a different model: Each client folder is its own source of truth. The core mechanics are intentionally simple: - Context loads in a fixed, task-specific order instead of relying on fuzzy retrieval. - New learnings are written back to the relevant client folder. - Ambiguous learnings go into quarantine instead of being assigned automatically. - A weekly process deduplicates memory, recovers useful learnings from missed sessions, and extracts cross-client patterns without carrying over client-specific details. - Recurring tool mistakes can become proposed guardrails, but promotion, archiving, and hard blocks always require human approval. The plugin is the engine. Your data stays in plain Markdown files inside your own folder structure, where it can be reviewed, edited, and versioned with Git. The daily hooks run locally and send no telemetry. The optional weekly consolidation uses your own Anthropic API key. Agency Memory Kit is currently on v0.2.10. It’s open beta, MIT licensed, and tested end to end on macOS and Windows. If you’re building a multi-client or multi-project Claude Code setup, try it! I'm interested in what you would change. Repo here: https://github.com/krsnczky/agency-memory-kit

Intros for The Connection Hub - The Vault 👤 Who I am: (name + where you're based) 🛠️ What I actually do: (the specific work — not "I'm in real estate" but "I run a 3-agent team doing residential resale in Austin") 🤖 What I'm building with AI right now: (your current project, workflow, or the thing you're stuck on) 🎯 What I'm looking for connection-wise: (pick one or two) 💡 Someone who's solved [X] 🤝 A collaborator / accountability partner 👀 Just here to learn from people in my field 🧰 Trading workflows & systems 📬 Best way to reach me: (DM here / comment / link)

We talk about folders all day, but the folders are FOR something. I want to know what... 🎖️Bonus points: comment with the single most painful manual process in your industry. The best comp entries come from exactly those answers.

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.