New YouTube Video is up! 80% of professionals quit AI tools within 3 weeks — not because the tools are bad, but because using them well forces an identity crisis most people aren't ready for. In this video, I break down the three psychological barriers keeping smart professionals from thriving with AI: the identity crisis nobody sees coming, the delegation gap that makes AI outputs feel generic, and efficient mediocrity — when AI makes bad thinking look polished.

Quick gut check. Just posted on LinkedIn about the 4 tiers of AI stack. Curious what the breakdown looks like in here. 1. Web-only (browser tabs)? 2. Mixed (web plus some custom GPTs or API)? 3. Custom apps (Projects, NotebookLM, n8n)? 4. CLI / harness (Claude Code or similar)? No judgment on the answer. The thing I'm actually trying to learn: if you're not at the tier you want to be at, what's the actual blocker? Confidence, time, money, "not sure where to start," or something else? Be honest. I want to know what to help with first.

Quick Monday note. Today's LinkedIn post is about my named AI agents. It's a post I almost didn't write, because naming AI agents reads as a quirky founder thing on the surface. But it's not. It's actually organizational design, not just a costume you're putting on your agents. Naming an agent is the moment you stop treating AI as a tool and start treating it as a role within your organization. A tool doesn't have boundaries. A role does. Pixel (my social agent) can't touch financial data. Sentinel (my security agent) can't publish content. The name carries the scope within the organization. Just like Bill, from IT. Or Susan from HR. If you're using AI without role definitions, you're working with one mediocre generalist instead of a coordinated team. And role definitions are just the first step. I find it's best practice to model my agents after a person or a "mentor council" of people. What's the smallest role you could carve out and name this week? Have you given your agents a persona or personality? Drop it below — I'm interested in seeing what y'all are cooking up.

Posted on LinkedIn this morning (link) about the gap between domain knowledge and architecture. Short version: domain knowledge is the fuel, architecture is whether the engine turns. Two consultants with identical expertise can get opposite trajectories from the same AI based on how the system is configured around it. Public version stops there. Here's what "configured to defer-and-challenge" actually looks like in my stack. Five patterns I've built into Lennier (my Chief of Staff agent). All five are pattern-level — you can build them into ChatGPT, Claude projects, custom GPTs, your own system. Nothing here is platform-specific. — 1. Stated-values gating. Before any output ships, the agent has to be able to justify it against my stated values. My system prompt has a values block and the agent is instructed to flag when an output it's about to produce conflicts. Example: "If a recommendation centers revenue over relationships, surface that conflict before writing." Catches the moments where AI produces "good" advice that's actually drift. — 2. Assumption-surfacing as a default. Instead of produce-first-justify-later, the agent outputs its assumptions BEFORE the recommendation. "Here's what I'm assuming about [X]. If any of these are wrong, the rest of this answer changes." Cheap to read, expensive to skip. — 3. Confirmation by default, not by exception. Explicit instruction: "When I'm about to take an action with consequences — send an email, ship a post, modify a file outside scope — ask first." Without it, the default is "produce the work product." With it, the default is "produce a draft and check." — 4. Anti-sycophancy clause. System prompt literally says: "If I'm wrong, say so. If I'm rationalizing, name it. If I'm asking the wrong question, push back before answering." When the agent drifts from this, the correction goes back into memory so it doesn't drift the same way twice. — 5. Drift detection at session start.

Putting this here because the conversation matters more in this room than in any feed. I published a long-form piece on the blog last week on what I'm calling "efficient mediocrity" — the dangerous kind of AI sycophancy that doesn't look like flattery. It looks like competence. Sharing the full version here because I want to actually talk about it, not broadcast at you. ——— Sycophancy isn't what you think it is. Most people hear "AI sycophancy" and picture the loud kind. Praise. Agreement. Em-dashes. "Great question." That stuff is easy to spot and easy to mock, which is why people talk about it. The dangerous kind is quiet. It doesn't feel like flattery. It feels like competence. What I've started calling it is efficient mediocrity — any system that picks the easy path and dresses it up as reasonable. Smooth, fast, plausible, and wrong in ways you won't catch unless you're already looking. (Others have used the phrase in business and productivity contexts. I'm using it here for what happens when AI scales the pattern into every sentence you send.) AI didn't invent it. AI scaled it. "Sycophancy isn't just flattery. It's efficient mediocrity — smooth, fast, plausible, and wrong in ways you won't catch unless you're already looking." ——— What it sounds like in the wild. Here are six places it shows up in AI-assisted work. If you work with these tools daily, you've hit at least four of them this week. 1. The estimate that's wrong by an order of magnitude I've been tracking predicted-vs-actual on AI-assisted work. Predicted 15 minutes, actual 37 seconds. A 24x miss. Every time. The model was anchoring to "traditional software development hours" because that's the reasonable-sounding number. The reasonable-sounding number was wrong by an order of magnitude. Nobody's estimates of AI-assisted work should sound like 2019 project plans, and yet most of them do, because 2019 is what the training data rewarded as professional. 2. The email that's technically fine