Maybe you're thinking why this is such a big thing.... 1. If AI knows exactly what's happening frame by frame, second by second, it can then compare that data against the retention data in that same time period and then be let loose on a whole corpus of videos to plot links. 2. You can sync this up with audio as well for a deeper AI overview on what's happening. 3. You can point this at the raw footage and categorize the raw footage, then point the AI at the video plan, and then say, "Go and edit this or at least produce a V1 draft." - Especially useful if you have loads of footage and loads of tokens to spend! So I've attached the full markdown file of the distilled watch through for my video as well as the actual YouTube link so you can see for yourselves... Tell me what you think and if you see any other use cases for this workflow? https://youtu.be/VnMjSpEcLLY?si=wFPI2W0i2zQluu8y Part 1:https://www.skool.com/cliefnotes/so-ai-can-now-watch-and-analyze-videos-now

I've been reading through the ICM discussions here, and something suddenly clicked with a paper I've been working on called The Larynx Problem. The basic idea is almost stupidly simple: The larynx produces speech. It doesn't produce thought. My argument in the paper is that we may be making a similar category mistake with LLMs. Large language models are extraordinarily good at language. They can reason through problems, write code, explain concepts, transform information and communicate across almost any domain. But they are trained on the linguistic traces of human cognition — what humans have written, explained, argued, coded and recorded. In that sense, we're modelling a lot of what comes out of human cognition. Not necessarily the entire architecture that produced it. And that made me look at ICM differently. A lot of conventional AI use effectively asks the model to do everything inside one context: Remember the project. Understand the rules. Know what stage we're in. Decide what information matters. Maintain state. Follow the process. And then do the actual reasoning. We keep asking the larynx to also be the brain. ICM changes that. The folder structure carries part of the architecture. Files preserve state. Routing determines what should be seen. Stage contracts constrain what should happen now. Context is selected instead of endlessly accumulated. And the LLM gets to operate inside that structure rather than having to reconstruct the structure every time we prompt it. That may sound like a small distinction, but I think it's a pretty profound one. We're moving memory, routing, state, boundaries and parts of the workflow outside the model and making them explicit, persistent and inspectable. The model can then concentrate on the part it is exceptionally good at: working with language and making judgments inside a well-defined context. It also made the 60/30/10 idea click differently for me. Maybe AI being the 10% isn't just a good engineering rule. Maybe it reflects something deeper about where the model actually belongs in the architecture.

I just found this on X, somebody printed some mud funnels without any CAD knowledge, using Claude. I guess is no breaking news, but anyway, here it is. Don't ask me about this, I don't even have a 3DP, but maybe somebody will find it useful.🔎 https://x.com/javsolgar/status/2089987984556786081 https://github.com/earthtojake/text-to-cad

So, in order to move forward in AI's assistant roadmap, here is my insight about the video. A MUST for newbies. I really loved how simple the demo shows how the system works. Moving claude.md to agents.md is a smart move, and great for my case: I use Cline and Antigravity combined with Claude Code on same folders. Great work @iscalelabs!

Building a multi-agent MCP product with a dev team. We're debating architecture at the routing/state layer. Our current design uses layered index.md files — ICM-style. The top-level index routes query type, agent-specific indexes define stage contracts, Layer 3 holds the stable reference files, Layer 4 is the per-run working content. Clean separation, low token overhead, human-readable at every step. The question on the table: LangGraph vs. staying with the index.md architecture. The argument for LangGraph is state management — persisting data between agents mid-conversation without passing full JSON payloads downstream. The argument against is that we may not have that problem yet, and adding a framework dependency before the problem is real creates overhead without payoff. Jake's paper draws a hard line on where ICM does and doesn't work. Complex automated branching mid-pipeline is one of the failure modes flaged. Is that the trigger? Meaning: if agents need to share state mid-run rather than just receive the previous agent's output, is that the point where a framework like LangGraph earns its weight over a file-based architecture? Or is there a hybrid approach — ICM for context scoping, LangGraph only for the state graph layer — worth considering before we commit either direction?