Serious post so no emojis today. I keep thinking about people like this: https://youtube.com/shorts/31buPKjzhGo?si=-nzpH1vj87oUhFgK There’s something I’ve said often over the years and it’s that people don’t spend enough time considering human behavior when trying to adopt tools and workflows. Imagine you built an ICM structure that helps your coworker Nancy generate weekly reports. It saves her 2 hours a week, it’s reliable, the output is better than anything she’s seen in years. Every time Nancy opens Claude to start the workflow, she forgets she needs to go to Cowork and tries to use Chat. She constantly has to bring you over for help after struggling for 10 minutes on her own. After doing this for a couple weeks, she just starts writing them on her own again because there’s no friction. The tool wasn’t the issue, it was that it was creating friction, even if the end result was improved.The best tool in the world is useless if no one wants to use it. Which brings me back to the video. The narrative with AI has become emotional. People are not only comparing how effective it is or whether it’s worth investing in, they are taking a moral stance against it and becoming offended at your use of it. The comments in the video struck me and gave me a new frame for thinking about how I want to design tools. How do I design for outputs where it is not replacing human connection? And for instances where I am communicating with others using it, do I pass it off as my voice or do I own that it’s AI and that I am using it as a tool. It’s going to get harder to tell the difference and others will not think this hard about it. Will that make me at a disadvantage to those who are willing to 1000x every aspect of their work at the expense of quality and connection? Or will my thoughtfulness find a way to shine through and create more quality work even if my output is less. This is the question I am asking myself today. Do you think this is worth thinking about? Let me know your thoughts below.

For if you've been lurking here and feel like you're missing half the conversation... --- 1️⃣ ICM (Interpreted Context Methodology) 💬 "I set up the ICM workspace once with numbered stages. Claude Code reads the folder, knows exactly what to do at each step, and I only review the output at each handoff." Jake Van Clief's framework for structuring AI agent workflows using folder-based architecture. ICM treats the filesystem itself as the orchestration layer — workflows are broken into numbered stage folders (e.g. 01_research, 02_drafting), each with a CONTEXT.md file that defines what inputs the agent receives, what it should do, and what output it should produce. Designed primarily for use with Claude Code rather than the Claude.ai chat interface. The methodology is model-agnostic and eliminates the need for complex coordination code by using plain text files and folder structure as the state machine. --- 2️⃣ Agent The most overloaded word in AI right now. Technically: a Claude session or piece of software that can take actions, not just respond. In this community it gets used loosely — anything from a folder-based specialist you consult manually to a fully autonomous system reading emails and triggering workflows without human input. When someone says "I'm building an agent," it's worth asking which kind they mean. 💬 "My agent reads the leads inbox hourly and drafts responses autonomously" is a very different build from "my specialist is a folder I open when I need it." --- 3️⃣ Agentic The adjective form of agent — but more specific. An agentic workflow is one where Claude takes a sequence of actions, observes the results, and acts again without waiting for human approval at each step. A single Q&A is not agentic. A system that reads an inbox, decides what to do, drafts a reply, and sends it is. The more agentic your build, the more important your rules.md becomes — autonomous action with bad constraints causes autonomous problems.

I’m curious about how much traditional development lifecycle people are using in their ICM builds and *why* they found that was the right level. Do you bother with some kind of development > staging > production equivalent? If so, what does this look like in your setup? For me, development is essentially a system playground folder where things are before they are ready and wired. I’m using my “governance” settings as a cheap way to have staging without actually having staging - I dial back the permissions when something is released and see how it performs on several runs before loosening those off and letting it go more on its own without permissions - essentially prod. Because what I’m currently building myself is for a user market of exactly one (me), this works exceptionally well. But it’s on my mind - what are you all going for? And what’s the thinking behind it?

36,000 members in here. I reckon we're all at very different stages. Drop your letter below. If you picked B or C, tell me what you're working on.

Two weeks ago I stood in this room and begged you all to stop using big words like "orchestration." This week I "accidentally" built one. La ironía. Quick reminder of who's talking: I'm not a coder. Built my company on Excel, faith, and the kind of stubbornness my pregnant wife tolerates because I bring snacks to bed at 1 AM. In a room full of software engineers, I'm the guy who snuck into Harvard on a clerical error. So grade this on a curve. Here's the thing I built. I'm calling it the 8 SIGNAL Operating System (my fancy words for 8 SIGNAL's implementation of ICM). If you've been around in the community long enough, you know the drill. It's one place where my whole team and I work alongside AI. Not a chatbot in the corner. Not eleven different tools nobody remembers to open. One environment, and every department lives inside it. Marketing. Client work. Accounting. This week, legal. The part that still makes me a little dizzy: it routes itself. --- Hand it a legal document and it walks itself to the legal corner of the OS, does the work there, and still carries the context of the whole company with it. --- This morning, mid leadership meeting, I fed it notes on a job candidate. Never told it where to look. It went and found the job descriptions on its own and started scoring the fit while I was still talking. --- It's tool-agnostic. Whatever model is best in that moment, Claude, Gemini, Codex, it's supposed to reach for that one. I'm not married to a vendor. I'm married to the result. (I should probably test this out for myself, but I'm taking Jake's word on this one.) And the boring win I love most: every week somebody on my team used to pull our accounts receivable and payable out of QuickBooks by hand and type them into a task before our leadership meeting. Tedious. Easy to forget. As of last week, the system reads it, organizes the numbers the way my team likes to see them, drops them in the right place (Asana task description) on its own, and moves last week's data to a new place (Asana comments on that same task). Nobody touches it. Three months ago I could not have built that. I learned how by building it.