First off, hopefully this doesn't break any rules... I am a technically oriented person who wants to learn more about the business side of AI. I'm at a rough spot where I know I have developed a valuable understanding and skill set with AI, but I don't know where to go from here. I've seen a variety of experience and enterprise levels within this community, and I'd love to connect & be mentored directly by anyone who has actually applied my proficiency in AI to build any kind of business service or directly implement systems in businesses. If possible, I would love the opportunity to contribute or work on anything as a learning experience at the intersection of AI and business, but I'm honestly happy to just connect and chat. I'd also love to swap experiences and information with people who are more on the business side, who are maybe not as technical! That's also not to say I'm pushing away anyone who doesn't have either; I would love to chat and help anywhere possible! P.S. my level is too low to DM, so please feel free to go ahead and shoot me one.

If your main files still sit under ~/.claude or ~/.codex, you're still not quite there yet, or more importantly, safe. Think: if the Claude app decided to nuke itself tomorrow, wiped the whole application folder and everything inside it, how cooked are you? With what Grok AI pulled off recently (downloading whole Repos of information without permission), you can never be too safe. <- PLEASE read up on this if you're not caught up. Now, however ridiculous the idea you might think, the proposition still stands. If your instructions, context routing, and memory all live inside ~/.claude (or wherever your app stores its files), you don't have a model-agnostic structure. You have an app-dependent one. If Claude suddenly decides to stop supporting certain file customizability and directly, it'll be an immense and frustrating headache to fix. While it likely won't happen soon, or at all tbh, the simple fix is decoupling. My whole global system, I personally named it "BABEL," lives in its own folder directly, version-controlled, completely separate from any app folder. What sits inside the Claude and Codex apps is just a thin layer of symlinks and shims pointing back to my global ICM structure. If my Claude wiped its own folder right now: - My instructions, memory, registries, skills, docs are completely fine. - Restoring is one simple prompt for me. Re-point the symlinks, and I'm good. - Want to move to a different client entirely? Same source files, new shim layer. The brain doesn't move at all, and even a fresh, completely new LLM harness is good enough to wire itself in with symlinks. Was inspired to post this after the recent Grok incident; happy to break down how the symlink layer works if anyone wants it.

Hi everyone, I'm posting this because I'm curious to hear your perspective on harness engineering within the ICM method. If you have any experience or opinions, please share :)

I am buidling a business website builder for solar companies. I used the workspace builder of Jake. I ran each stage and at the end ran it on local server. There was a css or formating issue. You can take a look at it: https://newmeharemail-ux.github.io/sunreserve/

The cheapest model I run does most of the work in my agent loop. The most expensive one only wakes up when a deterministic check has already decided it is warranted. - Deterministic harvest - the mechanical half. Routes each job's report, updates the index, moves the finished record from pending to completed. Zero judgement calls, so it runs on the cheapest model available. - The verdict - a plain rule, computed at the end of every run, that decides whether the interpretive step is even needed this cycle. - Judgement pass - the one genuinely interpretive step. Runs on the strongest model, and only fires when the verdict says it is warranted. The loop keeps the state of my system current after every job runs. Most of what that involves is not thinking, it is filing - taking what each job reported, sending errors to one place and state updates to another, then moving the finished record out of the pending folder. None of that needs a judgement call, so I run it as a plain deterministic script on Haiku. It behaves identically every time, which is exactly what you want from the mechanical half. The interpretive work is a different animal. Merging conflicting updates by hand, pruning a list down, deciding what is genuinely resolved and safe to archive - that needs real judgement, and it is where a weak model quietly makes a mess you only find two laps later. So it is a separate stage and it runs on Opus. The part that keeps it cheap is that it does not run every cycle. At the end of the deterministic stage the script computes one thing: is the judgement pass warranted right now. The rule is plain - is there a queue of unresolved items, has a file grown past its size line, have enough jobs landed since the last judgement pass. If none of that is true, the expensive stage never fires. The two stages never collide because a single-writer lock hands off between them. The deterministic stage takes the lock, does its filing, computes the verdict, and if the verdict is warranted it keeps the lock held and spawns the strong model to run the judgement pass under that same lock. If the verdict is not warranted it just releases and the cycle ends cheap. One held lock, never two writers touching the same record.