For those running agents on a recurring schedule (daily/overnight), I'm tightening my own setup and curious how you handle two things: 1. Stale or wrong context — how do you stop a scheduled run from acting on yesterday's state or drifting from the current workspace? Cold start every time, a freshness check, something else? 2. Autonomy vs approval — how much do you let a scheduled agent actually do unattended versus leave as a draft for you to approve? Where's your line between "just do it" and "prepare it and wait for me"? Mine currently drafts everything and waits for a human yes, but I suspect I'm leaving easy wins on the table by not letting it act on the safe stuff. Where do you draw the line, and what burned you?

Stack: Claude Code, Opus 4.8 at extra-high reasoning effort while building the workflows, so model tier is not the variable. Symptom: on the machine where I built it, the agent nails conventions and picks the right procedure unprompted. Same repo on another PC (or after splitting the monorepo into per-tier repos) and it gets visibly dumber. Same model, same files, same prompts. I ran several passes of flow debugging, routing tuning, and file cleanup, with no change. So I went hunting for what differs between machines but isn't in the repo. I found two things, both unversioned and both silent. First, the agent's per-project memory store, which is keyed by project path and lives outside git; on the dev box it had been quietly complementing the KB for weeks, and on a new path the bucket is empty, so a whole layer is gone with no error thrown. Second, local harness config (session hooks and settings) that primed routing at startup, which also doesn't travel. The part I almost missed: re-homing those facts into canonical docs is necessary but not sufficient. A rule already written in its canonical home still got skipped, because written is not the same as loaded at task time. Where I landed: performance = model x context actually loaded at runtime. Migration never touches the model, it fragments the loaded context. Fix direction: split durability (one canonical home per fact) from availability (always-on Layer 0 for cross-cutting rules, verb-routed pointers for the rest), then verify in a clean, memory-less session that the rule surfaces by its trigger rather than because I already knew it. Questions: 1. Is leaning on out-of-repo agent memory the classic first mistake, or am I misreading something structural in ICM? 2. Is there an ICM-native pattern for making a fact load-bearing (guaranteed in context at task time) vs just present in the tree? 3. Any heuristic for the always-on vs routed split before Layer 0 bloats? 4. Other unversioned dependencies that silently don't travel, beyond memory and local hooks?

What do you wish you understood better? 👇 I want to hear from everyone. Every level. Day one or day one thousand. There's no question too small, too basic, or too "I feel like I should already know this." If you've ever wondered how something works, what something means, or how to do it, that's exactly what I want. Two quick things 👇 1️⃣ Vote in the poll for the big topics you want more of. 2️⃣ Drop your specific question in the comments. The more specific, the better. The comments can serve as building a list from your answers. The creators in this group are incredible, and once we know what you're asking for, we can make the content that answers it. (This is a post aimed at helping all of us make more engaging content) Even if you mostly read and rarely post, this is an opportunity to have someone write about something you may not have an answer for. One question from you might be the exact thing ten other people were too shy to ask. 😊 We learn together, we grow together, we win together! 🤓💪🏆Bas Question: What do you want us to make more content on?