🎟️ 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)

Hey everyone. I've had too much free time this week so I've been trying to formalise ICM, and it sent me into a paper called "Build Systems à la Carte." I think it points straight at something we need to build, and I'd like to poke holes in it with you. Start with the gaps ICM names about itself. The paper is honest that it has two problems it doesn't solve: - Staleness (§6.1). A stage declares which files it reads in its Inputs table. Change one of those files and the stage's output might now be stale, but nothing makes that concrete. The paper explicitly leaves "dependency tracking and change propagation" as future compiler-theory work. - Self-tracking edits (§6.3). Editing a stage's output is like patching a binary, it fixes this one run. Editing the source fixes every future run. And recurring edits to the same place are debugging information a future ICM could track, but doesn't yet. Both of those are build-system problems. Which is exactly what "à la carte" formalises. The paper's move is to take the vague idea of a "build system" and split it into two independent parts: - a scheduler: what order tasks run in. - a rebuilder: whether a task actually needs rerunning, or its result is already current. ICM already has the scheduler. Numbered stages running in a set order is exactly that, you decide what runs when. What it doesn't have is the rebuilder, the part that answers "is this stale." The mechanism it uses is a verifying trace: you store the hashes of the inputs a task used last time, and on the next run you re-hash. Anything different means the task is dirty and reruns. Nothing different means you skip it. It's the build system's memory. That is the staleness fix, almost directly. A verifying trace over a stage's Inputs table means you hash the files a stage reads, and when one of them changes you know exactly which stage went stale. §6.1, handled. The rebuilder has a second trick that lines up with §6.3. You don't only track the inputs, you track changes to the tasks themselves, the rules. The paper calls this self-tracking. For ICM I think that means treating a stage's instruction file as a tracked dependency too, so editing a stage re-triggers exactly what depends on it, and recurring edits to the same file become visible signal instead of lost effort. That is §6.3's "recurring edits are debugging information," made concrete.

Hey Everyone. Quick one for anyone who's shipped a comp or two and wants to push up a level. I won Comp 6 (Mayston, a stroke rehab researcher) and a few people asked what actually went into it. I saw a community post by @Ariel Ortiz with 20 votes on a poll for people asking thoughts. So here's a quick summary of what I'd tell past-me, starting with the thing I got most wrong this time round **The mistake** I spent the first three or four hours of Comp 6 designing a product for a problem that didn't exist, for users who didn't exist. Lovely idea, real momentum, completely made up. Then I got on the phone with my dad (he's been a physio 30+ years) and within ten minutes it was obvious those people weren't real and neither was the friction. I binned it and started from scratch. The lesson isn't just "talk to an expert," though do that. It's that I started building before I'd asked the questions that decide whether there's anything there at all. **Ask the questions first** Before any design, before any code, the actual work is answering these honestly: - Do I understand this user domain? - Do I understand their real frictions, not the ones I'm imagining? - Do I understand who the audience is? If you can't answer those, you don't have a problem yet, you have a guess. Everything I built after I could answer them was real. Everything before was the three hours I threw away. **What I think actually wins** Here's the rough model I've landed on. It's a multiplication, not a checklist: **strong submission ≈ depth of build × visibility × founder credibility** A zero on any one term zeroes the whole thing. The deepest build nobody can see still scores nothing. **Depth** is a genuinely hard, nuanced technical problem that solves a real friction for real people, without just swapping their old friction for a new one. The questions above are what protect it. No real users, no real depth, just complexity dressed up. **Visibility** is making that depth seen, by two audiences. The engineer who wants the architecture made legible, and the user who needs the domain story: who they are, what hurts, why your thing fixes it. The judge reads as both. For Mayston I put the depth in a README with diagrams, written so the user's problem is obvious, and I told the domain story as a video: who physios in the UK actually are, what they deal with, what the educators deal with, then why and how Mayston fits. That walk is the part judges feel.

Hey everyone, Going to be transparent with you all. We're pausing the weekly competition this week. No comp #7. We'll be back next week with the next one. Here's the real reason. Jake and I are both on family vacations right now, and we're buried in enterprise work on top of it. We've been running 15+ hour days since this community started, and we've hit a point where we need a few days to actually breathe. This community has grown faster than we ever imagined. None of that happens without you all. The posts, the help in the comments, the bad ass builds people are shipping every week, the way you all show up for each other. It's real and we don't take it for granted. But if we're going to keep this thing high-quality long-term, we can't run on empty. A week off the comp grind so we can rest, catch up on enterprise work, and come back sharp is the right call. The 7-day leaderboard still runs as normal this week. Keep posting, keep engaging, keep helping each other. The leaderboard winner still gets the prize on Monday. Weekly comp #7 picks back up next week. We'll come back with something good. Thank you for understanding. And thank you for being here. ❤️

We’re about to wrap up Comp #6 this week and they’re gaining steam. But there are still a lot of folks who haven’t thrown their own hats in. Made me wonder, would anyone be interested in a “Behind the Build” post from any of the winners, runners up or honorable mentions? If so, are there any specific questions or people you want to hear from? Jump in the comments.