A priming bundle grows without anyone ever deciding to grow it. Mine reached a 106 KB markdown file going into every fresh chat before I noticed I was spending most of an opening context window on orientation the job did not need. - The files grow, the bundle never gets re-scoped - each markdown earns a few lines a week and nobody re-reads the total. - Orientation is paid per spawn - every new chat pays the full size again, whether that job touches any of it or not. - Size is checkable, relevance is not - a byte count is trivial to gate on, whether a file earns its place in this specific job is not. What I run now is a size gate rather than a curation step. The priming script assembles the bundle, checks the total, and if it is under threshold it goes. If it is over, the loop running in the background trims on its next pass rather than blocking the spawn. Crude, but it fails in the right direction, because I never get stopped from starting work and the trim happens on the loop's clock instead of mine. It is still a blunt instrument. Size is a proxy for the thing I actually care about, which is whether a given file is load-bearing for this particular job, and a byte count cannot tell me that. So this one is a question rather than a share. How are you handling it - retrieval instead of pasting, per-job bundles assembled by task type, a summarisation pass, or third-party tooling I have not looked at properly? I am more interested in what has actually held up in practice than in what should work on paper.

Hi, I was wondering if anyone who works with AI using ICM has encountered restrictions regarding security. I was discussing this with a friend of mine and at some point I did not have anything else to say, because I genuinely don’t know. I don’t know how to deal with companies, I can imagine that much of the data they have is sensitive to some degree. How do people that create workflows with AI for companies deal with such constraints?

The blur problem Parallel sessions are anonymous by default. The harness hands each one an ID at boot, and then nothing surfaces it anywhere you actually look. Every terminal pane shows the same shape. Every file that lands on disk carries no mark of which session made it. Anonymous sessions make anonymous artifacts, and once an artifact leaves the session, its provenance is gossip. You either remember which pane produced it, or you dig. The count, from my own week: twelve sessions ran in parallel last week. Builds, audits, research legs, a render pipeline. Today I can tell zero of them apart by looking at their output. Three days after the fact, a handoff doc asked the only question that mattered, which session wrote this, and answering it cost an hour of archaeology through git logs and file timestamps. That hour is the tax, and it recurs every time you add a session. ----------------------------------------------------------------------------------------------------------------------------------------------------------- The signature trick The fix starts from a fact that is easy to miss: every session already has a unique ID. A UUID, a slug, a key the harness assigned at boot. You do not need to invent identity. You need to surface it. The method: 1. Take the session key, append a fixed salt, and run it through SHA-256. 2. Read the digest in Crockford base32, an alphabet that drops I, L, O, and U so no character misreads as another and no code accidentally spells a word. 3. Keep five characters. Twenty-five bits, about 33 million codes. Collision odds across one hundred live sessions: roughly 0.015 percent. The result is a code like `tm:31T2J`. Deterministic. Same session key, same five characters, on any machine, forever. Before: two terminal panes, both titled "session", both indistinguishable. After: pane one reads `tm:31T2J`, pane two reads `tm:K7QX2`. The question "which one is doing the render" stops being memory work and becomes a glance. -----------------------------------------------------------------------------------------------------------------------------------------------------------

This is my own breakthrough after listening to @Curtis Hays. I now know how to add people. All of my ICM builds so far have had stages, and each stage comes with a single costume that my agent puts on to perform that stage. Now I know I can add a roster of people, and I can have the right person work on the stage. Then I am able to have a second person review the stage. The nerdy side of me wants to talk about finding a second degree of freedom.

Hi all, Before I get to my questions, I want to thank Jake for such a valuable resource in his ICM / F&F method. I am an AI and coding newbie, and this has definitely put me on the fast track. I knew I needed something like this, I just didn't know how to even start looking for it, and then the YouTube algorithm served it up for me. The moment I saw what Jake was teaching, I knew it was my next step in the journey. Thank you! On to my questions. I have gone through the Foundation Course, and I have the full Workspace-Blueprint template. The three-layer method (Map, rooms, tools) has become how I actually work, and I have been running it for a little while on smaller projects. Here is my situation. I am building the operating system for a multi-industry business group, and it has grown into several distinct domains: - an identity and philosophy layer: governing principles, values, and leadership and management philosophy, synthesized from a body of books and courses, - a knowledge layer: a large reference library plus custom tools that extract and organize knowledge from books and transcripts (several thousand files), - a research layer, - an operations layer: SOPs and playbooks for running the businesses, - a learning layer that captures lessons and feeds improvements back in, - a governance layer that holds the enterprise map. Right now this lives across roughly ten separate Claude projects that grew organically. Some began as tools, some as libraries, and each became its own project. Many are stages in a workflow. So, work completed in one "stage" needs to move into another. Most of this was built before I discovered Jake. I am fairly certain I need to reorganize what I have already built, and I am also considering turning some, if not all, of the skills I have created into file-based workflows. The method is taught at the scale of one folder with a few rooms, and mine is well past that, so I want to be sure I am applying it correctly rather than drifting into the "too many workspaces" problem at the project level.