Where bare ICM stops being enough, and what you have built on top 🎂

ICM is the best thing I have come across for making AI work legible, and it is genuinely the reason I can build what I build. What I keep running into is that a folder structure is a map, not an engine - past a certain size, something has to drive it.

Three things I ended up adding on top:

- A logbook - every job writes a record when it finishes, so the system has a history and not just a current state.

- A bundler - one command assembles the right files into a single prime, rather than me picking them by hand every session.

- A design layer - brainstorming and prompt writing happen in a chat first, and only the finished work order goes to Claude Code.

For context, ICM was one of my first real experiences of what you can actually do with AI, and I am still not over it. This is not a criticism of the methodology, it is a question about where it stops being sufficient on its own.

Where I hit that was memory and scale. A folder tells a fresh session what exists, but not what happened last week, what already went wrong, or which of five projects it is sat in. The structure holds state and I kept needing history. Without the layer on top, I am the one remembering, assembling and routing, every single session, and that is where all the manual work quietly goes.

So the genuine question. If you are running something big, or anything near enterprise, are you telling me it is a folder structure and Claude Code prompts and you see what happens? Or is there an orchestration layer you have quietly built that you do not talk about much?

Interested in the limitations people have actually hit with a bare ICM setup, and what you put on top to get past them?

35 comments

Where bare ICM stops being enough, and what you have built on top 🎂