What amazes me about ICM is how different it is from traditional software. Normal software is built by a team around a fixed set of features. You get what they built, and if you need something else, you buy another tool or wait for an update. With ICM, I can build as many personal tools as I want. A workflow I repeat becomes a small system of folders and files that my AI can run. If it isn't right, I change it. If a better idea comes along, I scrap it and build a better version, all without waiting on a vendor or paying a developer. It's living software. It changes when I change, it grows as my work grows, and it's mine. An idea in my head can become a working system the same day. In ICM, your workflow is your software.

Hermes can run a cron job without ICM. It can wake up on schedule, read a source, write a report, send a message, and save the run output. It also has its own durable storage: - session history, - persistent memory, - cron definitions and run logs, - skills, - and whatever files it creates in the workspace. That is useful. But it can still leave you with a familiar mess: > a chat somewhere > a cron log somewhere else > a report with no obvious home > and an agent that needs you to explain the project again next week That is where ICM comes in. I use ICM around my Build Market Close signal cron so the **job is not the whole system**. The cron is just the heartbeat. The structure holds the memory: ```text pinned-post-curriculum-signal/ ├── CONTEXT.md ├── signal-register.md ├── reply-drafts.md ├── curriculum-outline.md └── runs/ └── YYYY-MM-DD/ └── signal-review.md ``` Here is what each part does: - **`CONTEXT.md`** tells a fresh agent what source it may read, what counts as meaningful signal, what it may write, and where it must stop for me. - **`runs/YYYY-MM-DD/`** keeps a dated receipt of every review: what the job saw, what changed, and what it deliberately did not do. - **`signal-register.md`** is the one place for real questions, objections, implementation friction, and learner needs. - **`reply-drafts.md`** holds proposed answers for review. Nothing gets posted automatically. - **`curriculum-outline.md`** turns repeated questions into a better lesson sequence instead of letting them disappear into comments. So the cron does the recurring check. But ICM makes the check **usable**. A fresh agent can open the folder and answer: 1. What is this job for? 2. What source is it allowed to use?

I just watched the Jake Van Cleef breakdown, and the biggest thing that stood out to me was not getting overwhelmed and starting small. It clicked because I tend to complicate things and get overwhelmed. My main takeaway was start small. The experiment at the end helped me understand how to think about the system. Going forward, I'm going to start small and utilize the system better.

Subject: Am I misunderstanding "build inside your workspace"? I'm working through "Building Your Stack" and stuck on something Jake says in lesson 1.1: "Build inside your workspace. Don't create a separate folder. Build where your context already lives." Right now, every time I start a new project, I create a new folder and ask Claude to use the ICM architecture to design it. But based on this lesson, it sounds like I might be doing something wrong. My current approach: - New project = new folder - Each folder gets its own CLAUDE.md and structure - I reference ICM architecture in the setup What I think Jake is saying (but not sure): - Build tools and projects inside an existing workspace that already has context - Don't spin up a new isolated folder every time Questions: 1. Is there a "main workspace" I should be building everything inside of? 2. Should custom tools live alongside my regular AI work files, not in separate repos? 3. Am I overthinking this, or am I actually setting things up wrong? Would appreciate any clarity from people who've gotten this working.

just discovered (sorry if this is old news) you can browse the file tree in claude code, do we need VS code anymore?