Most ICM setups I see here are single-operator: one person, one agent, one context tree that's basically externalized working memory. We're running it differently — as the shared know-how of a small engineering firm (~15 people: industrial automation, control-panel building, light EPC). That one shift, from personal to organizational, changes the whole problem. In a company, the context isn't just my memory — it's the procedures everyone has to follow, and procedures have to be governed, auditable, and improvable by people who will never open a terminal. Here's the core of what we've landed on. One markdown source, three readers. The ICM KB — plain markdown in GitHub — is at the same time: - the agent's operating context (what it reads to act: load costs into the ERP, build quotes, enforce the process); - the company's procedure manual, rendered into a navigable wiki — search, cross-links, the graph of how procedures interconnect — which is what employees actually read; - the ISO 9001 controlled-document system, because Git already is change control: versioned, attributed, diffed, immutable — stronger than the Word-on-a-shared-drive most small firms limp along with. No parallel copies, so nothing drifts. Git is the evidence vault; the wiki is the auditor's reading room. (Worth stating for this crowd: ISO 9001 mandates control — identification, approval, versioning, availability of the current version — it mandates no specific format. A git-backed static site clears that bar cleanly.) The agent is the abstraction layer — this is what makes it survive in a company of non-technical people. Nobody learns markdown, Git, or pull requests. They talk. The agent enforces the current procedure while they work; and when someone says "step 3 is wrong, we do Z now," it turns that into a proposed change to the controlled document. The quality lead gets a plain-language summary and approves or rejects. Proposing is frictionless and open to everyone; approving is a controlled human gate. The Git/PR machinery stays invisible underneath.

Been building an AI system for our agency for the last several months — custom tools, automations, outreach, all structured so the AI knows what context to pull and when. We run most of it through our own website. Found Jake's content and immediately recognized what we'd been building toward. The ICM framework — structured context over complicated multi-agent setups — we'd been doing a version of this without knowing it had a name. Here's the thing though. Everything I've seen assumes one person running the system. We're two founders. And the team layer — who owns what, how handoffs work, how you avoid overlap when the AI is already handling coordination — nobody seems to be talking about that. Just getting into the classroom so maybe it's in there. Curious if anyone's figured out ICM for a small team or if that conversation is even happening yet.

The last couple of contests have been pushing people to post repos on GitHub and I must say it has removed a lot of friction in my workflow. It is as simple as using a remote drive and the best part is Claude code on mobile works natively in GitHub. This means for any app, website, or ICM structure you have up there, you can open the Claude app and work right in your folder structure. Have an itching thought about that bug you want to fix while you’re grocery shopping? Just a message away. The dispatch feature is nice but this is so much more natural to use and stay organized with and I’m loving it!

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?