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.

I just came out of a conversation with the CEO of a startup in Madrid. My goal was to explain ICM and understand both the problems it could solve and the new friction it might introduce. The first obstacle was file collaboration. Their team works in Google Drive and is used to editing Docs, Sheets, and Slides together in real time. An ICM workspace, however, moves much of the operating context into the filesystem through Markdown and other structured files. That works well for agent readability, portability, and version control, but it is a significant change for a non-technical team accustomed to Google Workspace. How are you handling this in practice? - Do you use Git and a shared editor? - Do you sync the ICM workspace through Google Drive? - Do you keep Google Workspace as the collaboration layer and move approved material into ICM? - Have you found another setup that works better for non-technical teams? I am particularly interested in how you define the source of truth and prevent conflicts between a live Google file and its ICM counterpart.

After reading google's version of ICM we get to a product (who would have guessed....) that is Cloud Knowledge Catalog (link here). Which is a payed product with a bunch of stuff in-it. To all you tech folk, more experienced then me: Why should a company pay for this, when google drive's folder hierarchy and permissions, plus ICM gets you the exact same thing? PS.: does microsoft have anything like this?

I pulled together the main options from a recent tool breakdown, plus one extra cursed-but-powerful category: building the whole thing in VS Code as HTML. I'll leave the link to the original tool breakdown in the comments.

Same poll every month, hit a button below and leave a comment arguing for your favorite! Also be like @David Vogel and yell at me if I didn’t mention your fav 😅