EDIT: the use of copilot-instructions.md is very unreliable. Despite clear instructions to load the ICM workspace and read the setup.md at launch, 9 times out of 10 it fails with no meaningful error. Copilot itself tells me that these instructions are more like suggestions.🤣🤣 Instead I have built a skill in Copilot co-work and I have built an agent for the standard Copilot chat. Both of these will reliably launch into my ICM workspace. -------------------------------------------------------------------------------------------------------------------------------------------------------------- We've gone back and forth, here, on whether ICM can work inside Microsoft Copilot. I can now say it definitely does, and that Copilot Cowork is where it works best. I spent today rebuilding my own ICM workspace, currently in Claude, for Copilot — routing file, room context files, a voice file, branding, shared references — and it maps over almost one-to-one. The folders-and-markdown approach we use is almost exactly how Cowork is built to work. Your files live in OneDrive, Cowork reads them on demand, and you get the same context-on-demand behaviour we're used to. Two things make Cowork good for ICM, particularly in a business environment: - It reads your ICM folder tree straight from OneDrive, so you stop re-explaining yourself each session. - It has native access to Outlook, Teams, calendar and SharePoint, so rooms that interface with those apps or their data get easier - The adjustments were small: Copilot itself rewrote my Claude.md to a Setup.md, native M365 instead of connectors, and tightening the original markdown, which had grown, to keep token use down. NB: Copilot, to me, seems a smidgen slower than Claude (Yes, I have Opus 4.8 enabled in Copilot) Guide and blank template at RockfieldIT/icm-copilot-cowork: Implementing ICM in Microsoft Copilot Cowork

Before digging into the topic let's briefly set the scene by providing some background context. Background In 2026-Q1 I decided to invest into a custom pc to run local AI Models. Being an IT Professional I grew increasingly concerned seeing the pc component shift heavily towards AI Business cases. PC component prices was increasing rapidly and high-end components becoming scarce or non-available. Given the overall AI development in general I realized I wanted to ensure I owned AI capability at home, and that if I want to stay current in my career I need to dive in head first into AI and AI Development. A powerful driver and motivator is that I want to see just how far I can take AI capabilities based on localhosted opensource methodology over paying a subscription/pay as you go solutions. I eventually came across Clief's YouTube videos which got me curious about ICM and I decided to join this community. Getting educated Working through the Classroom Foundational course I noticed that ICM is primarily used together with Claude. Reading Clief's thesis ( Interpretable Context Methodology: Folder Structure as Agentic Architecture - https://arxiv.org/abs/2603.16021 ) strengthened my own observation that ICM conceptually is model and tooling agnostic. As long as the AI Model can access and interpret the ICM specification files it shouldn't matter if the model itself is run on cloud services like Claude, Gemini etc. or local hosted alternatives. I decided to put this to the test and do it practically. Working through The Foundation: Module 1.2 ( https://www.skool.com/cliefnotes/classroom/036893d9?md=fdee3f73c53b46049078494c0cfb2e54 ) where we create our first ICM folder and get a quick win. I decided that since the Module 1.2 usecase is easy to start with, it makes sense to get it set up running in my own localhosted ai environment. I also wanted to proceed with a real usecase where ICM can be helpful.

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.

I have two questions I’ve been sitting with and I want to hear from people who’ve figured this out. Question 1: Claude Code vs Claude API cost If I build an app in Claude Code, complete with a frontend and a real workflow, and I want other people to use that product (not Claude Code itself), how do I handle the cost side? The goal is to let users interact with the product without me eating API costs on every request. Is there a clean way to do this while still leveraging a Claude subscription, or is the API bill just unavoidable once you’re serving users? Question 2: Automating Claude Code I come from n8n. I know how to chain workflows, handle webhooks, trigger automations. But Claude Code with ICM is a different kind of powerful, especially for handling larger data volumes, which is one of n8n’s real limitations. What I want to understand is: how do people actually automate Claude Code? Not just run it manually, but set it up so it’s doing work on a schedule or in response to triggers, the same way you’d build a workflow in n8n. If you’ve done either of these, drop it in the comments. I’d rather learn from someone who’s already made the mistake.

This will tell you a lot about the future and the way I think, give it a read if you have time. https://jakevanclief.substack.com/p/the-machine-is-smart