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.

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. 📋 THE CHALLENGE Build a folder-based AI diagnostician that reads something broken and tells you WHY it's broken. Not how to fix it. Why it failed. This week's deliverable is one diagnostician folder that someone could drop into a Claude project and use to figure out why something in their world isn't working. 🎯PICK YOUR DOMAIN The domain is yours. Pick something specific. Pick a failure you've actually seen happen. A few sparks to get you thinking: - 📉 Why a landing page isn't converting - 📧 Why cold emails to a specific buyer aren't getting replies - 📋 Why a product spec keeps getting pushed back by engineering - 📄 Why a resume isn't getting callbacks in a specific industry - 🚪 Why users drop off at one step of an onboarding flow - 💸 Why a pricing page isn't converting trials - 🎥 Why a YouTube video underperformed the channel average - 🤝 Why a sales deal stalled after the demo - 📱 Why an app's retention craters in week two The more specific, the better. "Diagnoses marketing problems" is too broad. "Diagnoses why cold emails to enterprise IT buyers get opened but never answered" is right. 🗂️THE METHODOLOGY If this is your first comp, welcome. Here's what you need to know: This week (and every week) you're learning interpretable context methodology. Folders as architecture. Each file does one job well. Your diagnostician is a folder with five things: - 📄 identity.md (who the diagnostician is, what they diagnose) - 📐 rules.md (how they diagnose: what they look at, how they separate cause from symptom) - 💬 examples.md (2-3 example diagnoses showing the reasoning) - 📚 reference/ (common failure modes, diagnostic frameworks, benchmarks) - 📖 README.md (how to use it, what to feed it) Drop the folder into a Claude project. Claude becomes the diagnostician. Reusable. Shareable. Portable. 🔥 THE ANGLE THIS WEEK A diagnostician is NOT an editor. Last comp was The Editor. That one critiques craft. It looks at a draft and says "this part is weak, go fix it."

I’ve been thinking about what happens when an AI agent causes real financial damage. Not a harmless glitch or sloppy wording in an email. I mean an agent sends the wrong quote, invents information that ends up in a client deliverable, exposes customer data, or anything that costs someone actual money. Who is responsible? or I guess the better question is: Who is liable? That matters, of course. But I’m not sure it is the best first question. I think the first question is, What are we doing right now, before something goes wrong, to make sure we are not completely unprepared when it does? Or, since I'm not building for clients yet, the real question is what are YOU doing? Do you plan for this? Do you actually take ownership of the risk? (Legal, IT, operations, the person who built the workflow). I can see AI insurance companies popping up all over the place. 😄 I do not have any of this figured out. I suspect many of us are building faster than we are defining accountability. What are people actually doing in practice? Do you have checkpoints or review processes you trust, or are you still trying to work this out too?

I'm running a startup incubator in Suriname and for a young "AI for geology & mining" startup I'm trying to get ICM in the mix: Workflows - for the business aspects design - design, coding and maintenance of the software (front end/back-end) - The actual AI engine running the service, setup, training, optimization, uptime etc. - Monitoring users, errors, UX - Monitoring business progress/KPI's/CAP tables for Stock Splits Anybody knows how best to structure all of this? Best practices? Oh and I manage currently 4 active startups

Context: I've built a Python pipeline that processes client documents through the Anthropic API on a schedule. It handles PII, so I have compliance obligations. Right now it runs manually on my PC; the next phase adds a scheduler and a webhook receiver. My problem: the plan assumes it runs on my local PC, and that's a bad fit — my internet isn't reliably stable and the machine can't be counted on to stay awake and connected through a busy season. The obvious alternative is a small VPS running everything, with my PC as the dev machine. Questions: (1) Local vs. VPS for this — what would you do? (2) If VPS, what's the minimum competent setup for handling PII? (3) Anything about running a scheduled, webhook-driven Python pipeline in production that bites people who haven't done it before? If it matters for #2 — I was leaning toward DigitalOcean, but open to other suggestions. Thank you in advance. #Rookie