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

Memberships

Clief Notes

39.9k members • Free

Momentum Society

1.7k members • Free

AI Masters Community with Ed

12.3k members • Free

ChatGPT Users

12.7k members • Free

Hamza's Automation Incubator™

47.1k members • Free

Max Business School™

265.5k members • Free

Content Academy

14k members • Free

AI Automation Agency Hub

327.1k members • Free

Ocean Vibes's Lifestyle Lab

21 members • $12/m

8 contributions to Clief Notes
Why Is a 19th-Century Prussian General Showing Up in My AI Conversations?
Jake made a point in on of his videos that I haven't stopped thinking about: People rarely ask how the liberal arts apply to AI, even though they're often what help us navigate the fuzzy problems where there isn't a single objectively correct answer. As a computational linguist, that got my attention. Someone recently asked me if computational linguistics was "even relevant anymore." That's like asking a structural engineer if buildings are still a thing. So I'm curious: If you could require every aspiring ICM practitioner to deeply study one (or two) disciplines outside of AI and software engineering, what would you choose? Some candidates: - Philosophy - Linguistics - Psychology - History - Political theory - Anthropology - Economics - Literature - Rhetoric - Art history - Architecture - Music theory More importantly: What mental model from that field has fundamentally changed the way you build AI systems? My current research agenda consists of figuring out why Helmuth von Moltke the Elder seems to have more relevant opinions about AI execution than most LinkedIn influencers.
Does your system go to the gym?
The way we build has been on my mind lately. Part of it was @Ruben Aguirre ’s post about memory and drift and the system getting away from him. Part of it was a conversation with @Curtis Hays. Curtis kindly gave me permission to share the following, which is all his: The frame is the one from the thread @Geoff Thilo started. Two layers everybody can see: where the work lives (the folders), and what the model can see when it acts (the context loading). There's a third nobody builds for — discipline. What keeps the first two true after the day you set them up. People conflate organizing files with keeping them true over time. They're not the same job. I keep an index of every client and which version of their brand doctrine is current. I wrote it once. Then a few weeks later I touched it once more for an unrelated change. That was it. Two edits in two months while the actual client work churned underneath it — new versions, new clients, a half-dozen files that moved. By today the index was just wrong. It froze on the day I wrote it and the world walked past it. Here's the part worth noticing. It didn't go stale because I got lazy. It went stale because nothing in the system owned keeping it current. No rule, no gate, no step that said "when a doctrine file changes, the index re-derives." I went looking — there was nothing. It was a hand-built snapshot with no maintenance contract attached. An artifact like that was always going to freeze. The only question was how fast. So that conversation from Curtis got me thinking. I build a lot slower than some people in here - and I’ve already tagged two of them in this post. Part of that is because I spend time worrying about what Curtis calls the discipline. I stop and think about the boring stuff when I build. How is it going to get maintained? Does the skill force it or suggest it? I run a fortnightly reflection for my personal system. For my work one, I run a weekly sweep *and* a fortnightly reflection. I think the discipline is important enough that I baked a version of this into a competition entry in here - adjusted from my own practice to suit use by someone who is not a builder and stop the system from disintegrating over time.
0 likes • 3d
@Mira Bradshaw You named the thing in your reply to Caleb — a deterministic problem getting a probabilistic solution. I'd push it one step further: drift is the symptom, and the underlying problem is loss of interpretability. When the index went stale, its correctness became a probability rather than something you could check directly. Given the "I" in ICM, that's the failure mode worth focusing on. That turns the discipline question into a classification question. Some jobs have a single correct answer you can verify. Those shouldn't run on a schedule at all; they should recompute the moment the underlying data changes — no sweep, no reminder, no discipline required. You only need a cadence for the jobs that genuinely call for judgment. @Alex Brown, your setup is what got me thinking about this. When a CC job bumps the question generator v2.2→v2.3 and writes that to its touchdown, the job already knows the new version — so I keep wondering what the 30-minute loop is re-deriving when it reads that back later. Feels like the touchdown could just write the Machinery map directly at that moment. Where the loop clearly earns its keep is synthesis a single write can't do — "these three jobs together shifted the Storage approach" is real judgment. So the interesting line for me is which of your five maps could write themselves the instant a touchdown lands, and which actually need a model looking across touchdowns. My bet is Machinery and Folders fall on the deterministic side and the loop is paying model cost for them out of habit. Curious whether that matches what you're seeing. Interpretability is the tell underneath all of it. Any job that writes itself becomes inspectable by construction. The ones that stay on the model's side need it engineered back in — for us that's a documented spec the builder complies with, independently checked by a second model. And curious where you're drawing the Haiku line, Mira. My read is it's less about model size and more about which side of that deterministic boundary the slice sits on.
Have not written a proper article in a while, I changed that today.
This will tell you a lot about the future and the way I think, give it a read if you have time. https://jakevanclief.substack.com/p/the-machine-is-smart
1 like • 6d
Great article! Keep writing!
Has anyone here changed careers?
Not long ago I had absolutely no background in programming. I started learning out of pure curiosity after discovering AI and realizing how powerful these systems were becoming. At first everything felt overwhelming syntax, debugging, concepts I had never seen before but I kept showing up every day and building small projects. Fast forward a few months later, after countless hours of learning and experimenting, I managed to land my first role as a Junior AI Engineer. The journey wasn’t easy, but it proved to me that with consistency and the right resources, changing careers into tech is actually possible. I'm curious, has anyone else here made a similar transition?
0 likes • 6d
I’m in the middle of a career transition too, but from a different angle — the AI engineering work itself is the easy part for me. What I’m struggling with is the business side: actually finding and landing clients. I can build systems, deploy agents, architect workflows… all of that feels natural. But getting in front of the right people, earning trust, and turning conversations into paid work has been way harder than I expected. If anyone here has successfully made that leap — especially from “technically strong” to “consistently booked” — I’d love to hear what worked for you. Did you focus on niching down early? Cold outreach? Content? Referrals? Something else entirely? Any advice from people who’ve cracked this would mean a lot! I'm loving this group! Lots of great people here!
I'm giving away my OS map. The map was never the moat.
You built an agentic OS. So did the person three seats over. And when you put your architecture next to theirs, the shapes rhyme. Folders for clients. A governing layer up top. Named agents doing scoped work. An orchestrator routing it all. That's not a coincidence and it's not theft. It's convergence. Builders with no access to my internal architecture keep arriving at doctrine I already wrote down. One builder reasons their way to belief over prompting. Another builder names an agent and discovers that's the hook for giving it a soul. And another builds a routing gate to protect the signal. Different vantages, same destination. None of them copied me. They solved the same problem in their own org and ended up in the same place. I used to find that mildly surprising. Not anymore. Because if a stranger reinvents the doctrine without ever seeing it, the doctrine isn't clever positioning I invented. It's just how this actually works. Convergence is the proof that it's true. Which tells me the map was never the moat. If people can rebuild a system from a screenshot of a folder tree, then handing over the clean version costs me nothing and proves the point. So here it is. An outline of the AgencyOS map is attached to this post. Layers, agent roster, sample folder structure, and tool integrations. Take the shape. Start at Layer 1, not Layer 3. The agents are the fun part, so that's where everyone wants to start. The leverage is upstream. The belief layer governs everything the agents produce. Mine didn't come from a build sprint. It started forming in late 2023, with these ideas spoken aloud on a podcast, before any AI was in the picture. Then I spent over a year encoding that conviction into a system. Then I found ICM and ported it over. I'm still refining it. An agent I can spin up in 15 minutes. The belief layer took years because it had to exist before the machine did. Build the workforce on top of nothing and you get a fast machine with no conviction. And the belief layer is the one thing on that map you can't take from me. I can't take yours from you. You can copy the folders. You can copy the agent names. But you cannot copy what I believe into your system. I can go into my AI and ask it "what do I believe?" and it returns my truth. If you load my doctrine and ask the same question, you get what I believe. Not what YOU believe.
1 like • 6d
@Curtis Hays This distinction is the part worth slowing down on. Organizational architecture and context loading get conflated constantly because they both look like folders and markdown from the outside. The way I read it: your layers answer where work lives and what governs it, Jake's answer what the model can see at the moment it acts. Same substrate, orthogonal jobs. And they're not in tension — your org structure is what makes good context loading possible. You can't load the right context on demand if the work isn't organized so the right context is findable in the first place. The org map is the precondition for the context discipline. The folders being the same in both is what throws people. The discipline sitting on top is completely different. Nicely done! Definitely following your contributions. 🙌🏻
1-8 of 8
Geoff Thilo
2
9points to level up
@geoff-thilo-7708
I have no special talent. I am passionately curious about business, mindset, entrepreneurship, and maximizing life.

Active 3h ago
Joined May 27, 2026
Powered by