@Rich C You're spot on. Huge opportunity inbound for corporate AI rescue when they end up getting exactly what they ask for.

@Rich C Sounds expensive... i like it 🤣

@Alex Brown yep exactly that. It reads MD files, but the structure matters. My whole workspace is a vault of markdown: every working project has its own folder with a MOC/status note, plus a projects.MD registry that says what's active. So "review my working projects" = the loop skill wakes up on a schedule, reads the active project notes, and asks "what concepts is Daniel touching right now that he only half-understands?" <- inferred by my odd or half baked questions/requests (e.g. this week it's Graph API auth flows and cron scheduling). Then it hands those topics to /teach, which is its own stateful workspace it keeps a mission.MD (why I'm learning), learning-records of what I've already covered, and generates short HTML lessons (5 min max, one concept each). Because it tracks what I've learned, lesson 12 builds on lesson 4 instead of re-explaining basics. That's the loops-inside-loops part: outer loop watches my real work, inner loop runs spaced-repetition teaching against it. Your daily-log idea is basically the same pattern. I run an evening debrief skill that interviews me and writes a daily MD note, and a weekly rollup reads those. The unlock isn't the logging, it's giving a scheduled loop a folder of structured MD to reason over. Start with one daily file + one skill that reads the last 7 of them, you'll get 80% of it.

@Alex Brown Great minds think alike! Happy to collab

Running ICM in production right now, daily. Real talk up front: ICM by itself won't make the model faster or smarter. What it actually does is control what the model sees at every step, and that's where all the accuracy and hallucination wins come from. That distinction matters for what you're evaluating. Here's what ours actually looks like on disk. Every automation is its own pipeline of numbered stages, and every stage has a CONTEXT.md that says exactly what goes in, what happens, and what comes out: Automations/Weekly-Rollup/ CONTEXT.md pipeline routing references/ stable reference docs stages/ 01_gather-week/ CONTEXT.md the contract: inputs / process / outputs input/ output/<run-date>/ per-run state 02_reflect-synthesize/ 03_draft-digest/ 04_finalize/ The whole thing is basically a state machine on disk. Numbered folders = execution order, files in output/ = state. Nothing magic about it, and that's the point I can open any stage and see exactly what the model saw and what it produced. To your questions: Can ICM handle it alone at enterprise scale? No and honestly that's the wrong framing. ICM is the control layer, not the retrieval layer. With a huge collection of databases you still need some kind of index over your schemas (catalog metadata, embeddings, whatever works). ICM's job is making sure the SQL generation step only ever sees the 5 relevant tables instead of 5,000. Pair it with a schema catalog and it scales fine. Throw one giant prompt at everything and no architecture saves you. Where it kills hallucinations: Three things did the heavy lifting for us. 1. Small scoped context per stage. Hallucinated columns come from the model guessing when the schema isn't in context, or drowning when there's too much of it. Discovery stage narrows to candidate tables, generation stage gets ONLY that shortlist plus the real column definitions. Small correct context beats big noisy context every single time.

You can output it anywhere - make sure your routing table stays up to date and you'll be good

@Scott Smith This base set skill isn't going anywhere. Salesforce might be going another direction but, legacy companies will need help with their particular brand of CRM - great skill to nail down