Anybody built an ICM representing the idea of super large initiatives going on in an organization and smaller less impactful initiatives going on in the organization (that move a little bit faster than the large ones) and making sure that the dependencies across all of them are not overlapping significantly? When they do, they get called out so we can find them. Something that highlights and manages, to some degree, the interconnections between different initiatives

This is a follow-up to my previous post about using ICM for AI-driven machine learning research. In one week of ICM-assisted research, I've moved further than I managed in roughly six months of my master's thesis. This is what that looks like in practice: ICM/ ├── README.md ├── skills/ ├── agents/ │ ├── literature-intake.md │ ├── research-development.md │ ├── code-development.md │ ├── results-evidence.md │ ├── research-argument.md │ ├── thesis argument.md │ ├── self-review.md │ └── ... ├── research/ │ ├── context/ │ ├── literature/ │ ├── development/ │ ├── results/ │ └── reports/ ├── code/ │ ├── src/ │ ├── tests/ │ └── runs/ ├── thesis/ └── _system/ ├── rules/ ├── templates/ └── schema/ I can queue several research goals across different chats and let each one keep moving. The agents are not all doing the same job with different names. Each one has a bounded responsibility, its own context and a clear handoff to the next part of the work. - The literature-intake agent turns papers into usable research context. It extracts the claims, methods, datasets, assumptions and limitations that matter for my problem. It helps answer: what has already been tried, what can actually be reused and what still needs to be tested? - The research-development agent turns vague ideas into explicit questions, hypotheses and experiments. It forces the research to become testable before implementation begins. Instead of “try an LSTM”, the goal becomes something like: under these conditions, does recursive probabilistic prediction outperform a defined baseline? - The code-development agent owns the implementation. It builds the data pipeline, model interfaces and experiment code while respecting the assumptions defined by the research question. Its job is not to decide whether the research is meaningful. Its job is to make the proposed experiment executable and reproducible. - The testing agent checks whether the implementation behaves as intended. It verifies data shapes, transformations, edge cases, saved artifacts and the parts of the pipeline that can be checked mechanically. A passing test gives me confidence in the software. It does not give me scientific confidence in the conclusion.

I am pulling records about the same people out of a few different systems into one folder, so an agent can actually work with them. The merging is not the hard part. The hard part is that the same person shows up three times, slightly differently, and every system is convinced it is the right one. Phone written four ways. Name spelled two ways. One system has the newest email, another has the newest address, and the one with the better data is not the same one twice in a row. Right now I pick a winner per field instead of per record, and I keep the losing values in the same file so nothing disappears quietly. It works. But the file keeps getting fatter, and I am not sure fat but traceable is the right trade for something an agent reads on every request. For anyone whose folder is fed by more than one system: do you settle the conflict once on the way in, or keep both versions and let whatever reads the file choose at the time? And what happens on the day one of those systems changes its mind about a person you had already settled?

When I first joined this community I could not quite get my head around what ICM actually was. I understood the rough concept, but it kept sounding like skills wearing a different name, and nobody explained the difference in a way that stuck. Something clicked today that made it simple, so here it is in case anyone else is stuck at the same place. A skill is a recipe with the ingredients already out on the counter. It is a meal you make often, so you have written down how it goes and you have everything to hand. Run it and you get that meal, made well, every time. ICM is a chef who knows your kitchen. The chef knows where things are kept, because you told it once. It knows the fridge is over there, and roughly what you keep in it. It knows what you like, because that is the context you have given it over time. It knows what you cooked last week, because your workspace has your past outputs and examples in it. And it can already cook, because that part came with the model. So when you say "make dinner", it does not need a recipe for that specific dinner. It knows where to look, what you have, and what you would want. That is the whole difference. A skill produces one known thing reliably. ICM is the standing knowledge that lets something work out what to do when there is no recipe for it. The bit that took me longest to see is that they are not competing. A chef with no idea where anything is kept still needs a recipe handed to them for every single meal. A kitchen full of well-labelled ingredients with nobody in it is just storage. The recipes live in the kitchen, and the chef reaches for one when the job calls for it. If you are early in this and it still feels like two words for the same idea, that was exactly where I was - And there's loads of content in here and merely being around it and being receptive to some insanely capable people in this community, you will learn loads just via osmosis. What was the thing that finally made it land for you - and what does the kitchen look like in literal terms in your workspace?

From my live stream last night, the tight nine on explaining the platform as best I can on the fly. The full live stream is also posted if you want to see the other bits of Q&A and chatting we did. This was fun and I have a lot more to learn for the next one! Let me know what you guys wanna see next.