Quick update on the competition schedule so everyone knows what to expect. 📅 NEW CADENCE: TWICE A MONTH We're dropping comps on the 15th and the 30th of every month. Two chances to compete, every month, on a set schedule you can plan around. ✍️ WHY THIS SCHEDULE Spacing them out this way means we can give tailored feedback on every single submission. Not just the winners. Everyone who enters gets notes on what worked, where it's weak, and what to do next. 🎁 WHAT WINNERS GET Along with the prize, every winner gets a 15-minute one-on-one with Jake. Use it to talk through your build, ask questions, or bring whatever else is on your mind. Two comps a month. Feedback on every entry. Direct time with Jake for the winners. Mark your calendar for the 15th and let's get to work!

I've been working on this and have something that somewhat works, but I keep running into pieces that get messy and don't hold up well in practice. My current approach: the image I've attached lives in my AGENTS.md at the root of the project, so any time I build, the AI has the structure to reference. What I'm really after is the best way to implement the ICM system so that anything I build, Claude/AI already knows the way to build and stays inside that structure. Is anyone else doing this? Would love to hear how you've set it up.

We've been experimenting with treating ICM not as the whole system, but as one layer inside a larger orchestration architecture. For us, ICM solved something much bigger than prompting. It solved context. How do you keep models focused? How do you stop them from reading entire repositories? How do you bound work? How do you reduce drift? How do you move toward convergence? ICM gives us work packets, context contracts, routing, validation, and controlled handoffs. Once we started implementing it, we found ourselves asking: What happens if we build around that? Internally we've been experimenting with a governance layer we call AQ-CMF (just our internal name for it), but I think the more interesting thing to share is the orchestration itself. Right now it's basically a small "Swarm Orchestration Starter Pack." The idea is simple: Use the smallest model capable of doing the work. Reserve larger models for judgment and reasoning. Current setup: RTX 3060 12GB • 2,200 binary filtering workers • Qwen 0.6B • yes/no decisions • triage • filtering • classification RTX 5060 Ti 16GB • 150 structured extraction workers • Qwen 4B • schema completion • information extraction • template generation Cloud reasoning layer (introduced to me by @Ari Evergreen 's post https://www.skool.com/cliefnotes/i-run-100-agent-workflows-on-a-budget-model-heres-the-catch) • up to 200 Kimi 70B workers • interpretation • reasoning • code generation • higher-complexity analysis Claude Code • orchestration • synthesis • validation • architecture decisions • final judgment The smaller models don't really "think." They observe. They classify. They extract. They filter. Claude assembles. Claude validates. Claude decides. One thing we've noticed is that this also changes the economics considerably. Instead of paying frontier-model prices for every operation, we let local models perform the cheap labor.

Last night I dispatched 235 agents to review a codebase. The model wasn't Claude. The harness was though. Claude Code ran the whole thing. The model underneath was a budget one. Here is the thing nobody tells you about dynamic workflows. They are not a model feature. They are a harness feature. ————————————————————————————————— Claude Code has a mode called UltraCode, and UltraCode runs the dynamic workflows for you. Turn it on and it fans out tens or hundreds of agents by default, runs them in parallel, verifies each finding adversarially, then synthesises the survivors. That whole dance is orchestration Claude Code performs. The model just fills the seats. Which is also a cost bomb. Automatic fan-out to hundreds of agents on a premium model is a serious bill arriving by default. So I started renting the conductor and swapping the orchestra. The conductor is Claude Code, the harness: UltraCode, dynamic workflows, dispatch, the fan-out and verify loop. That stays fixed. The orchestra is the model underneath, and the model is swappable. Claude is one player you could seat. GLM and MiniMax are others. Point the same harness at a cheaper provider, GLM or MiniMax, and you keep the orchestration while the token bill collapses. Same UltraCode, same automatic dynamic workflows, a fraction of the bill. You utilise the same UltraCode, you just stop paying premium rates to run it. ————————————————————————————————— Now the catch, because there is one. You do not get all the benefits. A cheaper model reasons worse per agent. One GLM agent is not one Opus agent. What you are buying is the right to run fifty of them for the price of one, and to let structure do the work the raw model cannot. That is the trade. Depth per agent goes down. Breadth goes way up. And the workflow shape, fan-out then adversarial verify then synthesise, claws most of the quality back, because three cheap sceptics catch what one of them misses. ————————————————————————————————— The numbers from one run:

Come chat about your goals for the week! If you are new here, this is a chat room for general talk about the past week and the week ahead. Share what you’re working on and network with others! If you‘ve been here before, you know the drill. Leave a comment below: - What you’re working on - Something you hope to ship - Blockers you’re running into at the moment - Where you’re looking for help currently - Anything else you’d like to share Have fun and enjoy your week everyone! This weeks poll: lately I’ve been feeling like I’ve moved more from building and learning to a good portion of my time utilizing the systems I’ve finally shipped. This has been a big and welcome shift for me and I feel like I actually am grasping this stuff. Where are you on your journey?