I’ve done a master’s thesis before: genetic algorithms, XGBoost, Monte Carlo simulations, graph optimization. Lots of ML, long before modern AI could meaningfully help me. Back then, the hard part wasn’t having ideas. It was turning those ideas into structured experiments, reliable evidence, useful visualizations and clear conclusions, without losing weeks to setup, documentation and context switching. ICM changed the game. In one week, I’ve done more research than I managed in six months of my master’s thesis. The difference is not just speed. It’s the number of ideas I can now explore, test and refine: - Turn a vague idea into a concrete research question. - Convert that question into an experiment or proof obligation. - Generate the code, tests and evaluation structure. - Produce visualizations and evidence automatically. - Inspect the results and use them to guide the next idea. - Keep the reasoning, context and decisions connected throughout. - Do all of the above concurrently. The ICM becomes a research operating system. It helps separate what the code proves, what the experiment observes, what the data supports and what still requires human interpretation. That distinction matters. A test can show that the implementation works. It cannot prove that the model is useful. A result can show that one approach performed better. It cannot automatically explain why. A paper can inspire an architecture. It cannot validate that architecture on your dataset. ICM gives each of these things a place—and connects them into a traceable research loop: question → hypothesis → experiment → evidence → interpretation → next question The most powerful part is that ICM does not replace the researcher. It amplifies the researcher’s ability to think. The human provides judgment, curiosity and scientific direction. The ICM provides structure, memory, continuity and execution. That is why it feels so transformative for ML research. It turns research from a sequence of disconnected tasks into a living system that can continuously generate, test and refine knowledge.

Yesterday I had the the amazing opportunity of attending the talk of @Pedro Costa (Pedro Ribeiro da Costa | LinkedIn) in Santander Cafe Madrid about ICM. It was refreshing seeing a presentation of AI that is truly focusing on the right problem. and interestingly enough of all the hours I have already studied of ICM, Pedro was able to teach me so much in that hour presentation.

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 looked at 11 recent methods for giving AI the right knowledge and context. ICM, Agent Skills, OKF, LLM Wiki, Second Brain and more. They differ a lot. But they share three things: - Plain files and folders hold the knowledge. - Context comes in layers: a short summary first, detail only when needed. - The structure itself tells the model what to do and what to read. The differences are in the slides. The main similarity is clear: Hierarchy. Out of all of them: ICM constraints you the most. It limits you by forcing you to split your work hierarchically. And I would bet that is exactly the reason why it sits far above all the other methodologies. It has clear standards and design patterns that one could follow and improve upon.

I've been quiet lately between personal projects/lyceum/day job and life with family and friends. Rest assured, I am still working. Had this idea this morning to make a tool for folks to visually audit your ICM workflows in the order that the agent reads files for a given task. Turned it into a skill for everyone here. https://github.com/donroy26/workflow-tracer Invoke the skill for a given folder and write the task you want and the agent will give you a dashboard like shown in the attached photo. You can then audit all the files it walks for that task and see if any wires are crossed. Let me know what you think!