There are ideas you have to hear many times before they sink in. Years ago I read Atomic Habits, and one of its strongest lines is this: "You do not rise to the level of your goals. You fall to the level of your systems." James Clear It caught my attention, I liked it. But like so many powerful ideas we're not ready to absorb, I filed it somewhere in my brain and never implemented it. I heard the same concept many times over the years, with similar results. What I want to get across is this: ICM isn't about reaching the goal, or the solution. It's about building the structure where the solution is inevitable. Think about a kitchen: it's the 60/30/10 you already know. The 60% is the prep: sourcing, inventory, the stations, the mise en place. Everything is set up before a single order comes in. None of it is cooking yet. The 30% is the line: the timing, the order the tickets fire, who plates what and when. The rules that coordinate the service. The 10% is the cooking itself: the sear, the plating, the part everyone calls talent. The visible part, and the smallest. A chef doesn't rise to a great plate by trying harder tonight. They fall to the level of their kitchen. Build the 60 and the 30 well, and a good plate, the 10, stops being a feat and becomes the default. The structure makes it inevitable. That's what ICM is really doing. You're not chasing the solution. You're building the kitchen where a good one is the only thing that can come out. And it's not just builds. The same move works for anything you're trying to make happen, a habit you want to keep, a business you want to grow, a project you want to ship. You don't get there by pushing harder at the end. You build the structure that makes it inevitable. So, two questions for whatever complex thing you're working on: What structure would make the solution inevitable, instead of something you force at the end? And how could ICM help you build it?

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. ---- 🇬🇧 We're back. Good morning from London. 👋 Thanks for the patience last week. Jake and I needed a few days to breathe before London Tech Week kicked off, and you all responded with nothing but support. We don't take that for granted. Now let's get back to building. ---- 📋 THE CHALLENGE Build a folder-based AI operator that handles ONE operational workflow end-to-end. You pick the workflow. This week's deliverable is one operator folder that someone could drop into a Claude project and use to handle a real business workflow without babysitting. ---- 🎯 PICK YOUR WORKFLOW The workflow is yours. Pick something specific. Pick something you'd actually use. A few sparks to get you thinking: - 🎫 Customer support triage (which tier handles this ticket?) - ✅ Content review and approval - 📨 Lead intake and qualification - 💸 Refund request handler - 🤝 Partnership pitch evaluator - 🎙️ Podcast guest pitch sorter - 💼 Freelance project intake - 📄 Resume screen for one specific role - 📅 Meeting request triage (book, decline, delegate) The more specific, the better. "Customer support" is too broad. "Refund request triage for an ecommerce store doing under 200 orders per month" is right. 📎 If you want a fully written client brief as a reference, the attached PDF walks through one example. Don't build the example. Use it as a template for how to think about scoping your own operator. ---- 🗂️ THE METHODOLOGY If this is your first comp, welcome. Here's what you need to know: This week (and every week) you're learning interpretable context methodology. Folders as architecture. Each file does one job well. Your operator is a folder with five things: - 📄 identity.md (who the operator is and what workflow they own) - 📐 rules.md (the decision logic: criteria, edge cases, escalation rules) - 💬 examples.md (decisions in action, including at least one edge case) - 📚 reference/ (checklists, templates, rubrics) - 📖 README.md (how to use it)

For those who missed the first post or just joined: The Lyceum is a 12-week program we're building. Live instruction from Jake and the Eduba team. Small cohorts. Real projects. You build something from week one, not watch tutorials. At the end, a competition with real prizes. Eduba's first certification, backed by the same methodology we've used to train Fortune 500 teams. Now here's what we've locked in since then. The Structure Three 4-week sprints with a 1-week break between each. Not 12 straight weeks of grind. You build, you breathe, you come back sharper. - Sprint 1: Foundation — Core methodology. Everyone starts here. - Sprint 2: Application — You're building. Real project, real progress. - Sprint 3: Capstone — Finish what you started. Demo day prep. The breaks aren't fluff. They're built in so you can catch up, refine, or just live your life without falling behind. The Cohorts Same curriculum across all three. The difference is where your hours go. Technical — Developers, engineers, technical founders. You're building a tool or production system. 30% of your time goes to Claude Code and integrations. Another 30% to production systems and capstone. This is the builder track. Business — Ops, managers, founders, consultants. You're automating a process or designing a system spec. Heavy emphasis on workflow design (30%) and decision frameworks (25%). You direct the work without writing the code. Creator — Marketers, educators, solo operators. You're building a content production system. One person replaces the team. 25% on content pipelines, 20% on workflow design. This is how you scale yourself. Pick the track that matches how you work. The methodology transfers no matter which one you choose. A 4th Cohort? We're considering adding a team cohort if there's enough interest. This would be for companies that want to enroll multiple employees, or for people in the community who want to form their own team and build together. If that sounds like you, let us know in the comments.

💡Let me start with the truth of things first, because the truth is the lesson. ================= Token Warning ⚠️========== Before anyone comes for me 😅 📝 Note: depending on what you are loading, you are accruing token cost. And token cost can balloon if you are not careful. If any of the files in the initializing phase or handoff phase are large this can become a token intensive practice so when curating this process, BE INTENTIONAL only load what is absolutely needed for the project to start up and for you to get to the fun part, building! I budget for my own needs, for me this initialization for me is between 5k and 10k, I have made the mistake of making 40k, don't do that! If you want to understand an estimate of what your character to token ratio is use the site below: Tokenizer - OpenAI API Anthropic tokenizer has not been released yet, but Its a few % higher than OpenAI in some cases. Plain English sentence (115 characters) - OpenAI GPT-4: 23 tokens - OpenAI GPT-4o: 23 tokens - Claude (content only): 23 tokens - Result: identical Code and markdown snippet (86 characters) - OpenAI GPT-4: 24 tokens - OpenAI GPT-4o: 26 tokens - Claude (content only): 27 tokens - Result: Claude a few percent higher Numbers and punctuation (55 characters) - OpenAI GPT-4: 25 tokens - OpenAI GPT-4o: 25 tokens - Claude (content only): 27 tokens - Result: Claude about 8 percent higher One honest footnote: Claude's API adds roughly 7 fixed tokens per message for formatting. On a single short line that looks like a big gap. On a real document it amortizes down to almost nothing. ✅The takeaway: for the same English text, the tokenizers land within a few percent of each other. The scary "Claude costs way more tokens" headlines do not hold up when you actually measure it. Verified beats confident, every time. You have been learned and you have been warned! ============ Back to it! 👇=================

I'm in over my head and that's fine by me. Wondering how others are managing context windows for big agent projects. Almost like every client should have their own $100 max plan I'm thinking.