I keep seeing the same technologies in AI engineering roles: LangChain, LangGraph, RAG, vector databases and agent orchestration. They solve real problems. After building extensively with ICM, I've started wondering how often we introduce that infrastructure before deciding whether the problem actually requires it. ICM approaches the problem from the context side. A workflow is divided into stages. Each stage has one job, known inputs, expected outputs and defined context. The agent reads what that stage requires and produces an artifact that the next stage can work from. Context selection becomes part of the design. That distinction has changed how I think about RAG. RAG is extremely useful when the system cannot know in advance which information will be relevant. If someone can ask arbitrary questions across thousands of changing documents, retrieval has to determine what information should reach the model. That creates a second problem alongside the original AI task: retrieval itself has to work well. Documents need to be chunked. Search and ranking need to return the right material. Retrieval quality has to be evaluated. If an answer is wrong, you may need to determine whether the model reasoned poorly or whether it never received the right information in the first place. There are many applications where that complexity is justified. But consider a structured workflow where the current stage already tells you which references are relevant. If I'm performing a security review and the workflow already defines the security requirements, architecture references and files that should be inspected, I'm not convinced semantic retrieval should automatically sit between the agent and that information. The architecture already knows what context is required. In that situation, retrieving the "most relevant" context at runtime may be less useful than explicitly providing the correct context by design. The failure modes change too. With retrieval, a poor result can come from chunking, indexing, query formulation, ranking or reasoning.

We just crossed 50,000 members 🎉. Today. Not a projection. Not a “coming soon” slide. That number broke because Jake showed up with ICM and actually shipped it into a room that doesn’t treat people like leads. The welcome here isn’t a drip sequence. It’s people answering questions, sharing the folder, and sticking around after the first win. Most communities rent attention. This one compounds it. Jake’s ICM didn’t land in a vacuum - it landed in a stack that already preferred transparent workflows over vendor theater. Members didn’t just buy. They stayed, tested, and pulled the next person in. From empty chairs to a milestone that pays people back. Stop chasing the next shiny cohort. Start owning the room that keeps grinding after the launch email dies. If you’re in, say what you got out of it. If you’re watching, the door’s still open.

I read through all the Copilot post and asked the Jake agent, and not many success cases. I recently started a new position where Copilot is the approved AI tool. (No Claude or Chat allowed). I’d like to give it a reliable foundation of context my role, team, stakeholders, processes, and ongoing priorities so I don’t have to explain everything each time. Has anyone successfully implemented something like this within Microsoft 365? I’m especially curious about: - Where you keep the context and how Copilot accesses it - What carries over between conversations - How you keep the information current - Whether you use an agent or another setup Would appreciate practical examples, lessons learned, or resources. I’m looking to build something useful for daily work. Thanks community!

Did some digging as I was curious about the security implications with respect to utilizing MCP. Made some interesting findings! What are your personal takes? Is it `MCP to the moon!` or do you guys think users should be pumping the brakes?

#TOKEN-MAXXED