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?

I'm working on something I haven't seen discussed much here and genuinely want to know if others are in the same territory. We are trying to solve 2 problems. The first is that every team in our organisation is building AI context in isolation. Same knowledge being captured five different ways, no shared foundation, nothing governed or reusable. We've got enterprise knowledge that technically lives in SharePoint but is effectively invisible to any AI system. We want to fix that by building structured context at two levels: enterprise-wide knowledge that any team can draw on, and domain-specific knowledge owned by each business area — both stored as markdown, governed properly, with SharePoint as the interface for people who don't want to think about files. The second problem is how Technology handles demand from the business. The process for defining requirements, producing the right documentation has always been difficult as business areas often leave it to Technology. The outcome we are trying to achieve would be when a business area raises a need, an AI system — already loaded with the right enterprise and domain context — takes it through a defined process and produces a brief that engineers and their AI coding tools can act on directly. No discovery from scratch every time. The knowledge is in the system, not locked in someone's head or their OneDrive folders. The hard parts are not the AI. They're: - Getting operational detail out of each business domain at the granularity AI can actually reason about - Stopping teams building their own siloed context again the moment you turn your back - Building governance so the system earns autonomy progressively - Getting stakeholders to engage through the system rather than around it We have a later phase in mind where the system proactively surfaces opportunities by monitoring operational data — but we're keeping that parked until the core is stable. We are a small team in the early stages of planning the work.

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?