Recently a lot of excellent community discussion around how to ICM, largely because that’s the foundation but also refocused due to @Bas Rosario’s Post on ICM as building a Cake. Having experienced rapid growth in my past, one of the hardest things to do is keep language and definitions aligned. If I say the Agent did this, where does your brain go? Lines get crossed because you have so many levels of understanding and perspective. Some people are coming from non-technical backgrounds and have learned through corporate ai marketing. Others coming from corporate environments where language is defined for them by the management and designers building their infrastructure. Mini cultures with their own language. One of the brilliant aspects of ICM is it's commonality with almost anyone on a computer. It's just a folder, from that foundation we can all get on board. What's difficult is what happens next. I had this conversation with claude during a planning session. Claude asked me did I want agents or roles? I responded back by did he mean an agent like claude or codex, which is really an LLM, a purpose built agentic piece of software that the market tells me is an agent that does stuff? Or a folder acting as an agent with a specific role. I didn't know what the underlying meaning implied, how to answer? So I asked here was the response. 1. Engine — the LLM brand (Claude, Codex, Kimi, Minimax). Raw cognition, rented capacity, the electrons. Interchangeable. 2. Agent — the ICM folder. Persistent shaped context: identity + rules + reference + memory + boundaries. A standing operator that exists on disk and endures across sessions. This is your "folders hold attention" — an agent is where attention lives. 3. Role — a lens/hat: a function performed at one step of a process. It exists only in the doing. Where attention points right now.

BuilderCore Journey Update Over the last few weeks, something interesting happened. We weren’t just building an AI development platform. We were discovering what an AI software factory actually needs before it can be trusted. One of the biggest lessons was this: Governance is more important than autonomy. Everyone is racing to make AI agents that can do more. We’re trying to make AI systems that can be trusted to do more. Those are very different goals. The first goal isn’t autonomy. It’s predictability. Our first milestone wasn’t: - autonomous coding - autonomous deployment - autonomous GitHub actions It was proving that every stage of software delivery could be controlled, audited, replayed and stopped. That meant proving things like: - controlled apply - replay workspaces - validation - queue promotion - queue completion before even thinking about autonomous execution. That order matters. We stopped treating AI like one assistant. Instead, we started treating it like an organisation. Not one intelligence. A collection of specialised roles. For example: - Planner - Hardener - Researcher - Implementer - Reviewer - Judge - Operator That immediately changed how we think about AI. One of the strongest doctrines we’ve adopted: The same AI should never judge its own work. That now applies to: - reviews - validation - judgement If one model creates something… A different one should evaluate it. That’s closer to how healthy engineering teams actually work. Roles are permanent. Models are replaceable. This became one of the biggest architectural shifts. Instead of designing around: - GPT - Claude - Codex - Perplexity we design around roles. Today GPT might be the planner. Tomorrow another model might be better. The workflow shouldn’t have to change because the underlying model changes. We discovered evidence should change roadmaps. Not doctrine. This thread completely changed our roadmap. Originally we planned to test vague briefs next.