Activity
Mon
Wed
Fri
Sun
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
What is this?
Less
More

Memberships

Clief Notes

40.1k members • Free

AI Automation Society

415.4k members • Free

AI Automation Vault

18.4k members • Free

AI Automation Network

5k members • Free

14 contributions to Clief Notes
How do you keep your "voice" from flattening when you scale content through agents?
I run a fair amount of educational / authority content through a folder-based setup — ideas, scripts, articles, newsletters. The thing I keep fighting isn't quality, it's voice. The drafts come back clean, on-topic, technically fine... and generic. Correct, but it reads like the model wrote it, not like me. What I haven't cracked is the structural fix. A voice/style reference the agent loads first? An examples file of my own writing it has to match against? A heavy human pass on the last mile? And whatever you use — how do you stop that voice reference from quietly drifting back to generic as it grows? Curious what's actually held for the people here shipping real volume. Half-measures keep slipping for me.
Running agents on a schedule — how much do you let them do unattended?
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?
0 likes • 23h
@David Herrera The kanban-before-cron move is underrated — most people set the schedule first and bolt the structure on after. Curious how far yours goes: does the board just sequence what the run does, or does it also carry state the run reads — this card is approved to act, this one is draft-only, this one's blocked? The second version turns the kanban into the control surface for autonomy instead of just a to-do list the agent works through. That's the version I'd want.
1 like • 23h
@Mira Bradshaw This is sharper than what I asked — measuring the delta between what was presented and what you actually approved beats a raw intervention count, because it captures magnitude, not just frequency. Two agents can both get corrected once and be in completely different places depending on how much you had to change. The part I'd pull out is your "some areas I'll never promote by choice." That's not a maturity signal, it's a stakes ceiling — and keeping it separate from the earned-trust track is exactly right. The failure I see in most setups is collapsing the two: an agent racks up clean runs and quietly gets promoted into a decision that should never have been delegated no matter how good it got. Is that ceiling written as a hard rule the system reads, or is it discipline on your end?
My Interpretation of ICM - The Weld
Repo Template Here. I originally built my AI workspace based on a Jeff Su video about cross-domain folder hierarchy. Shortly after, I watched Jake Van Clief's videos and the Interpretable Context Methodology (ICM). I thought what I was building was an ICM setup at first. But as I learned more, I realized I was doing something different. So I found a way to weld the two ideas together into a more comprehensive system. Here is how the integration works: Tiers 1-3 (The Reasoning System): This is the Jeff Su inspired structure. It handles routing and context delivery for different topics, sorted by Tier 2 domain. By the time you reach a Project at Tier 3, you hit the reasoning level, where the context and Claude md roles completely change depending on the work. These are organized by State/Kind rules embedded in the system, and reasoning sessions are distilled and indexed with key points synthesized to project context. Tier 4 (The Workflow): Once the reasoning is stable at T3, ICM comes in as the workflow layer underneath it. Figure out what you want to build in the reasoning Tier 3, configure the factory to build it in Tier 4. I've mapped out the basic folder structure in the diagram below, and attached the actual markdown doctrine file that runs it. CoworkOS Workspace Structure ============================ ROOT/ ├── CLAUDE.md (Tier 1: Root Map & Routing) ├── CONTEXT.md (Tier 1: Operator Contract & Global State) ├── 00_Resources/ (Tier 1: Global Reference docs) │ ├── Workstation_A/ (Tier 2: Broad Domain) │ ├── CLAUDE.md (Tier 2: Workstation Map & Routing) │ ├── CONTEXT.md (Tier 2: Domain Posture & State) │ │ │ └── Project_1/ (Tier 3: Reasoning Project) │ ├── CLAUDE.md (Tier 3: Project Identity) │ ├── CONTEXT.md (Tier 3: Live Reasoning Synthesis) │ ├── _reasoning-log/ (Tier 3: Spent thinking & ideation) │ ├── references/ (Tier 3: Settled constraints) │ │ │ └── tier-4-workflow/ (Tier 4: ICM Pipeline)
My Interpretation of ICM - The Weld
1 like • 3d
@Daniel Terry Appreciate that Daniel. And the part you flagged as half-built is the right thing to leave half-built for now, full per-stage isolation costs you (orchestration, latency, more moving parts), so you dont want it everywhere. You want it only on the stages where a silent divergence would actually hurt. Which is where the diff stops being just a check and starts paying rent: run cold vs in-session across the pipeline, and the stages that disagree are the ones worth hardening into their own scoped context first. The ones that never diverge stay on cheap cold-entry. No isolation tax where it buys you nothing. So the sequence I'd steal back from you: diff first, let it rank the stages, harden top down. Let the structure tell you where it's actually load-bearing instead of guessing.
0 likes • 23h
@Daniel Terry No apology needed, genuinely. Pushing back on a critique of your own system isn't being defensive, it's doing the work. You held the design until the evidence actually landed, then you updated in public. That's the whole skill. Most people do one of the two failure modes instead — fold fast to sound agreeable, or dig in forever. You did neither. And "this is my voice not an llm" came through — it's exactly why the exchange was worth having. When you run the cold-vs-in-session diff across the stages, I'd actually like to see what it surfaces. The stages that disagree are the interesting part: that's where the system was quietly leaning on something it shouldn't have been.
If Your Specialized Agents Don't Think Differently. They Should.
My daughter @Brooke Hays has been studying cognitive functions for five years. She's 17, just graduated, and looking to become a holistic health coach. Last month, she typed 18 of my OS agents in one night using this framework. Today, she ran a live experiment for us on the Bullhorns & Bullseyes podcast. Two ChatGPT Projects (specialized agents). Same base model. Same prompt. Same input. Different cognitive functions wired into the instructions. Leora (Ne-Ti): came back with five ranked hypotheses and started asking unprompted follow-up questions. Her job was to explore the possibility space before locking anything down. Malachi (Ni-Te): one sentence on what was happening, then step-by-step logic, then exact next actions. No hypotheses. No exploration. Just the path. Same prompt. Different mind. Here's the operator problem: most agent teams are built like a roster of Michael Jordans. Same base model, same instruction pattern, same cognitive shape. You get consistency, but you lose the thing Rodman gave the Bulls - the guy who couldn't shoot and was irreplaceable anyway. The Bulls of the 90's had Jordan, Pippen, Grant, Kerr, Cartwright, Rodman, Kukoc. The argument we're proposing is that you want a diverse team. A diverse team of specialists, correctly assembled, is better than a team full of 5 Michael Jordans. Or take the 2002 Oakland Athletics, for example, made famous by the movie Moneyball. The A's featured a mix of college draftees, veteran players, and international all-stars. The diversity of the team wasn't just in their backgrounds; it was cognitive as well. With a front office that was willing to value unorthodox styles, older players, and statistical indicators that the rest of MLB ignored. Here's how we see it: your research agent and your copywriting agent should not think the same way. A Ne-Ti research agent generates possibilities and asks questions you didn't think to ask. An Ni-Te execution agent closes the loop and tells you what to do next. Run them in sequence and you've got a team. Wire them the same and you've got one guy doing everything at half capacity.
1 like • 23h
Curtis — this is the part most people miss when they spec "specialized agents." They give them different knowledge and the same reasoning, then wonder why every output feels like the same model wearing a different hat. Brooke wired the actual thinking. That's the harder and more valuable move. What I'd add from running these in production: different cognitive functions don't just give you different strengths, they give you different failure modes — and that's where the leverage is. An Ne-Ti agent like Leora hands you five ranked hypotheses, but leave it downstream and it'll keep generating when you needed it to commit. A Te/Si-weighted agent will close and ship, but it won't surprise you. So you don't have a roster of personalities — you have a pipeline. Divergent type upstream where the job is to open the space, convergent/critical type downstream where the job is to kill the weak options. Run it the other way and the critic strangles the ideas before they exist. One question for you or Brooke: when she typed the 18, did she assign the function stack to each agent's task — the cognitive work that stage actually does — or to a persona? That single choice is what decides whether this stays a clever character exercise or becomes an orchestration layer you can build a system on.
Folder Architecture Methodology in Restrictive Enterprise?
Hi Jake & Community — Working through your folder architecture and markdown file methodology and genuinely seeing the value. The context load sequence, the living CONTEXT.md approach, the layered structure — it maps well to how I think about systems. Here's my constraint: I'm working inside Cowork & Chat without access to Claude Code. No terminal, no hooks, no automatic file loading on session start. The files are there. The structure is there. But Cowork doesn't appear to auto-load them at the start of a session — Claude only reads what it's explicitly pointed to. So the architecture exists but the context doesn't load unless I remember to trigger it manually, which defeats part of the purpose. My question: Has anyone implemented this approach in an environment without Claude Code — no CLI, no hooks, no programmatic session triggers? And if so, what's the workaround for the auto-load problem? Specifically wondering: - Is there a reliable way to trigger context load at session start without Claude Code hooks? - Is a "load my context" opener prompt the current best practice for non-Code environments? - Are there tools or patterns that approximate the Claude Code experience for desktop/non-developer users? I'm working on making the case to my org for this approach — so understanding the real implementation path for non-technical users matters a lot. Also, being in a highly restrictive, governed, and large enterprise company creates so many bottlenecks for this approach, but the value and impact of application outweighs the "risks." TYIA, Colin
1 like • 3d
@Colin Swift the mechanics are mostly covered above, Tristen's right that the instructions field is your Claude.md and a single CONTEXT.md as the one loader gets you deterministic-by-ritual without hooks. So let me add the part nobody's said yet, because for an enterprise it's the part that actually matters. Reframe the constraint as a feature. In a non-Code env you trade automatic-and-invisible for explicit-and-auditable, and for a governed org thats an upgrade, not a workaround. Every context load becomes a visible, logged step. You can show security exactly what got read and when, and nothing fires against the filesystem on its own. Taking this to compliance, lead with that, it clears the room way faster than "it loads itself." One thing decides which version you get: can you edit that persistent-instructions field, or has your org locked it down? If you can edit it, you're basically at auto-load, the system gets told to read CONTEXT.md first every session and the burden's off your memory. If it's locked, you're on a one-line manual opener saved as a snippet. Both work, but know which one you're building for before you design the rest.
1 like • 2d
@Colin Swift great news!
1-10 of 14
Leo Saraiva
3
22points to level up
@leo-saraiva-7733
Leo

Active 1h ago
Joined May 3, 2026
Portugal
Powered by