I made a small personal operational summary of Jake’s ICM paper while studying it. It helped me clarify the core structure in a more practical way: layers, stages, workspace structure, how outputs move from one stage to the next, and how the “factory vs product” idea works in practice. I also included a simple hypothetical “video to study PDF” workspace, which is the kind of workflow I’m using to understand how ICM can help turn technical videos into structured study notes. The summary explains how one stage produces an output, how the next stage reads that output as working material, and how the stage’s CONTEXT.md defines which files and references should be used. It’s not official material, just my own study notes, but I’m sharing it here in case it can help someone else who is trying to understand ICM more operationally. Happy to improve it if anything is unclear or inaccurate. stay curious 🫡

ICM's premise is that structure replaces orchestration: folders and markdown carry each stage's context, and one agent reads the right files at the right moment. The paper assumes that agent is capable. I wanted to see if ICM holds when the agent is a small local model you run yourself. It does, by leaning on two things ICM already gives you. Stage-scoped context becomes injection. In ICM the agent roams the workspace and opens what it needs. A model served through Ollama is not that agent. It is an inference endpoint that takes a prompt and returns text, with no file access and no navigation loop, so it cannot roam the folders at all. The engine reads the files and injects each stage's context into the prompt instead. Same principle, each stage sees only what it needs, delivered by code rather than fetched by the model. "Scripts handle what doesn't need AI" becomes an oracle per stage. ICM keeps the mechanical work out of the model. I extend that one step: every generative stage is checked by a deterministic oracle (for code, the compiler and its tests), because a small model proposes well but can't verify itself. Reliability stays in the structure, not the model. That is the whole port. One stage one job, plain-text artifacts, factory vs product, human-reviewable files: all carry over unchanged. ICM and MCP stay complementary, as the paper notes, with the folder structure deciding context and the stage's tools exposed over MCP. The result is a frontier-free assistant: the same methodology, running on hardware you own, for tasks that are narrow and checkable. Two repos, MIT, pure stdlib (you bring Ollama): - Rust coding assistant: https://github.com/CurtisSlone/ICM-Local-Model-Rust-Coding-Assistant - Reusable base to make your own: https://github.com/CurtisSlone/ICM-Local-Model-Base I also have a coffee test example that is way more simple than the coding assistant.

1. Watch the intro video and introduce yourself in the intro post here 2. Start with The Foundation (free course). Concepts, folder architecture, prompting framework. Everything else builds on this. 3. Check in at the bottom of each lesson. Polls, discussion posts, other members working through the same stuff. Use them. 4. When you're ready to build real things, move to Implementation Playbooks (Level 2). When you're ready to build your own tools, Building Your Stack (Level 3). 5. Post your work. Ask questions. Help others when you can. What are you here to build?

Someone shared that a person a reaction video was made about my method and at first I was nervous but immediately it was amazing praise. I have never met with this person one-on-one and I haven't paid them or done anything other than post my own videos ! I think they do a great job at breaking some of the concepts down. It does an amazing job of breaking down some of the logic especially some parts where I go ranting in my video he slows it down a bunch ! Much needed