I am running an ICM knowledge base for my engineering company using GitHub, VS Code, and Claude Code. The efficiency gains in our workflows have been massive, and I see a clear opportunity to offer this to other regional companies as a new business unit. ​However, this dev-centric stack creates too much friction to be presented directly as a product to non-technical clients. ​The model I envision starts with heavy consulting to align the client's processes and culture. Once maturity is reached, it transitions into a managed service: issue tracking, periodic context pruning, and ad-hoc consulting for new agentic features. ​Has anyone here successfully commercialized this philosophy? I am particularly interested in how you package the delivery and abstract the technical friction (like the IDE and repo management) for the end user. Are there platforms already solving this?

Hi everyone. Is there any rule of thumb on how many words in every layer of an ICM workflow? Im trying to narrow it down in a large repo with many canonical things that apply for every workflow and I have 1263 words in layer 0 and a context routing of 871 words.

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.

To optimize version control, we avoid tracking binary files like Docx or Excel. Instead, the repository stores a Python generator script and Markdown files containing the specific parameters for each document. The script compiles the Markdown into the final binary artifact, ensuring minimal repository size and semantic diffs. We apply this pattern to engineering quotation spreadsheets. The LLM creates a MD file after analysing the specific sale. The Python script generates an Excel file from the MD parameters. However, users must modify the generated Excel directly to adjust the Bill of Materials (e.g., adding rows or changing products) for real-time sensitivity analysis. This human intervention alters the sheet structure, breaking the unidirectional flow and causing standard deterministic reverse-parsing to fail. The proposed mechanism to handle this is: 1. The user edits the Bill of Materials directly within the generated Excel artifact. 2. A deterministic Python script attempts to parse this modified sheet to update the original Markdown parameters. 3. If structural modifications cause the deterministic script to fail, an LLM agent is triggered as a fallback to probabilistically parse the unstructured sheet and reconstruct the Markdown data. I am looking for objective feedback on the architectural robustness of this pipeline, specifically regarding latency, reliability, and the viability of using an LLM as a fault-tolerant layer for reverse-parsing human-altered structured data.

Stack: Claude Code, Opus 4.8 at extra-high reasoning effort while building the workflows, so model tier is not the variable. Symptom: on the machine where I built it, the agent nails conventions and picks the right procedure unprompted. Same repo on another PC (or after splitting the monorepo into per-tier repos) and it gets visibly dumber. Same model, same files, same prompts. I ran several passes of flow debugging, routing tuning, and file cleanup, with no change. So I went hunting for what differs between machines but isn't in the repo. I found two things, both unversioned and both silent. First, the agent's per-project memory store, which is keyed by project path and lives outside git; on the dev box it had been quietly complementing the KB for weeks, and on a new path the bucket is empty, so a whole layer is gone with no error thrown. Second, local harness config (session hooks and settings) that primed routing at startup, which also doesn't travel. The part I almost missed: re-homing those facts into canonical docs is necessary but not sufficient. A rule already written in its canonical home still got skipped, because written is not the same as loaded at task time. Where I landed: performance = model x context actually loaded at runtime. Migration never touches the model, it fragments the loaded context. Fix direction: split durability (one canonical home per fact) from availability (always-on Layer 0 for cross-cutting rules, verb-routed pointers for the rest), then verify in a clean, memory-less session that the rule surfaces by its trigger rather than because I already knew it. Questions: 1. Is leaning on out-of-repo agent memory the classic first mistake, or am I misreading something structural in ICM? 2. Is there an ICM-native pattern for making a fact load-bearing (guaranteed in context at task time) vs just present in the tree? 3. Any heuristic for the always-on vs routed split before Layer 0 bloats? 4. Other unversioned dependencies that silently don't travel, beyond memory and local hooks?