This is a brain dump turned into a post, summarizing the work I've done with Jake's ICM method. I want to share what I've learned to see how these use cases resonate and what I could do better. It took me probably two months of reading through the community and using the resources available before this actually clicked. What did it for me was a post @Curtis Hays wrote a few months back (https://www.skool.com/cliefnotes/the-folder-system-became-my-agency?p=1e30aba0). Reading that post is what helped me understand how this actually works, and I'm hoping this post can do the same for someone else. There are a lot of different ways to come at this. >>>How I wrapped my head around this I lead development teams, and I also do what I'd call typical project or product management work. So a lot of how I thought about this started with a simple question: what are the most common things I produce or share, at a daily, weekly, or even monthly level? I wrote those things down. From there I asked how they actually get created, where they start, what the process of drafting or iteration looks like, and where they end up. About 50% of my day is spent on the phone, and most new ideas, action items, and questions come out of those calls. Sometimes it's email, but most of the time it's calls. Before, I'd use AI to help draft or compile something, but I was feeding it context manually every time, sometimes a brain dump on the call itself, sometimes a brain dump afterward. I'd work on the thing, it would spit something out, and I'd save it or send it. What I realized was that I needed a way to take the information from those calls and actually store it, so I could recall it and use it again for whatever needed to happen next. Here are 4 different use cases of how I use this ICM framework. The first 2 are functional, I use them everyday. The last 2 are more ideas, but only because the opportunity to implement has not presented itself just yet.

You built an agentic OS. So did the person three seats over. And when you put your architecture next to theirs, the shapes rhyme. Folders for clients. A governing layer up top. Named agents doing scoped work. An orchestrator routing it all. That's not a coincidence and it's not theft. It's convergence. Builders with no access to my internal architecture keep arriving at doctrine I already wrote down. One builder reasons their way to belief over prompting. Another builder names an agent and discovers that's the hook for giving it a soul. And another builds a routing gate to protect the signal. Different vantages, same destination. None of them copied me. They solved the same problem in their own org and ended up in the same place. I used to find that mildly surprising. Not anymore. Because if a stranger reinvents the doctrine without ever seeing it, the doctrine isn't clever positioning I invented. It's just how this actually works. Convergence is the proof that it's true. Which tells me the map was never the moat. If people can rebuild a system from a screenshot of a folder tree, then handing over the clean version costs me nothing and proves the point. So here it is. An outline of the AgencyOS map is attached to this post. Layers, agent roster, sample folder structure, and tool integrations. Take the shape. Start at Layer 1, not Layer 3. The agents are the fun part, so that's where everyone wants to start. The leverage is upstream. The belief layer governs everything the agents produce. Mine didn't come from a build sprint. It started forming in late 2023, with these ideas spoken aloud on a podcast, before any AI was in the picture. Then I spent over a year encoding that conviction into a system. Then I found ICM and ported it over. I'm still refining it. An agent I can spin up in 15 minutes. The belief layer took years because it had to exist before the machine did. Build the workforce on top of nothing and you get a fast machine with no conviction. And the belief layer is the one thing on that map you can't take from me. I can't take yours from you. You can copy the folders. You can copy the agent names. But you cannot copy what I believe into your system. I can go into my AI and ask it "what do I believe?" and it returns my truth. If you load my doctrine and ask the same question, you get what I believe. Not what YOU believe.

Eight months ago, I started building what I thought orchestration required — N8N, Postgres, LibreChat, consulting and hosting fees. Tens of thousands of dollars. That was the right bet at the time. Nobody I saw was doing this with Claude yet. Three or four months ago, the game changed. And I didn't know it until I stumbled onto Jake's content on YouTube. Two weeks after watching "Stop Building AI Agents. Use This Folder System Instead", I have a working MCP. Client demo-ready. The whole system I was killing myself over? Markdown files and orchestration prompts. That's it. I want to give credit where it's due. Jake put something out that reoriented how I thought about AI. The investment wasn't wasted — it built the foundation. But Jake and this community pointed me toward what was actually possible now. If you're still building the complex version because you think you have to — it's worth a second look.

Hey everyone, I've been running an ICM folder system for my own reporting workflow and it's genuinely changed how I stay on top of everything. Now I want to roll it out to my immediate team first, then the wider company, but I want to do it in small increments rather than dropping it on everyone at once. Has anyone gone through this? Taking this system and actually getting a team or business to adopt it without it dying in week two? I'm thinking start with just my team, let them get used to the structure, then bring in other departments once there's some proof of life. But I'd love to hear from someone who's already been through the rollout side of things. What worked, what didn't, what you'd skip if you were starting again. Also, is there a video on here I should have watched already? If there's something that covers this and I've missed it, please just point me at it. Happy to do the homework first. Thanks

Before ICM I called it a "Prompt Modifier". At it's core, a markdown file, instructions to tell AI how to operate with the task at hand. This isn't building agents, it's the how, with a handful of instructions. At a high level, the Orchestrator manages handing off work to subagents. Built to be LLM agnostic, drop in to any chat, point to the file, or wire it into ICM with a trigger when needed. The main chat stops doing all the work and instead organizes, delegates, and manages communication. I've seen this catch a lot of errors, assumptions and hallucinations. Plans are better. Execution is improved. This also allows higher level model usage, without all the token costs. I'm usually using Opus, on high effort. --- An analogy I used when sharing with my brother-in-law, military vet. Think of Claude like a Team Leader. - Claude manages the agents instead of doing the work himself - A "research agent" is sent out to get the information and bring it back - Claude writes up the assignment, then sends a "worker agent" to do it and report when it's done - Then a "verification agent" checks that the worker actually did the job right - If it didn't, Claude keeps working the agents until it passes So if you're not getting what you want, talk to the Team Leader and tell him to fix his sh*t. --- I've used a version of this over the last 3+ months, it has helped cut down on token usage, while getting what I need done quicker. Building this into my ICM system has been a force multiplier. If you use this I would love some feedback to add to my backlog, still iterating on it. *Attached slide with some additional detail.