MCP servers are the plug-ins that give AI apps their tools: email, web search, scraping, payments. Most AI app on your machine (Claude Desktop, Claude Code, Cursor, ChatGPT) starts its own private copy of every one you configured, once per session, and most of them never clean up.

You installed 15 servers. Your machine is running hundreds.

I lived in that state for eleven weeks. This is the whole story of fixing it, told in the order it happened. By the end you can run the same diagnosis on your own machine, and know exactly what has been running your fan.

What’s inside:

• Why Your Desktop Runs Hot With AI Apps

• How to Check the Root Cause of an Overheating Desktop

• Why the Same MCP Server Multiplies

• How to Fix the Problem for Good

• The MCP Health Kit

By the end you can run the census, move every server behind one shared daemon, and prove the count stays flat the next day.
The MCP Health Kit (the diagnostic, the runbook, the working files): paid members claim it at the end.

Subscribe now

Why Your Desktop Runs Hot With AI Apps

For eleven weeks my Mac kept running out of memory. I ran a health check 37 times, and it came back CRITICAL in 29 of them.

Free RAM sat under 200 MB for weeks at a stretch, the compressor held 6 to 10 GB, and the fan ran constantly while I did nothing heavier than write markdown.

You know the surface symptoms. The fan spins up while you type. Apps beachball on switch.

Activity Monitor says 23 of 24 GB used, and when you scroll the process list you find dozens of identical node processes you never launched and cannot name.

Every standard fix helps for a while, then stops. Restart the app: good for a day. Remove unused servers: good for a week.

Close Chrome tabs: good until lunch.

I tried each of those more than once across those eleven weeks, and the reports kept coming back CRITICAL, because the advice treats the symptom while the process count climbs right back.

The cause has a number attached. Mine was 797.

How to Check the Root Cause of an Overheating Desktop

Before any theory, get your own number, because the number is what makes the rest of this real.

Run this before you read further:

pgrep -f mcp | wc -l

That counts every process on your Mac with MCP in its command line. Then see who they are:

ps -eo command | grep -oE "npm exec [a-z0-9@/._-]+" | sort | uniq -c | sort -rn

The morning I finally counted, it said 797.

One gmail server, 123 running copies. Together they held roughly 13 GB of RAM, which on a 24 GB machine explains the 59 MB of free memory the health check found that morning.

Nothing was broken. Every process was healthy, idle, and waiting for a session that had already closed.

Your number will be smaller if you run one app with three servers. It will not be 15 if you have 15 installed. Hold onto that gap between 15 and 797, because closing it is the whole story.

Share

Why the Same MCP Server Multiplies

A number that strange demands an explanation, and mine had three separate layers, each of which made sense to somebody.

First, the protocol layer. MCP’s default transport is stdio: the spec says the client launches the server as a subprocess and talks to it through stdin and stdout. Those pipes belong to one parent.

A stdio server cannot be shared, by construction, so every new session spawns a fresh copy of every configured server. Ten servers, four sessions: 40 processes, working exactly as designed.

Second, the cleanup layer, and this is where it goes wrong. The MCP lifecycle spec says the client SHOULD shut the server down when the session ends. SHOULD, not MUST.

When an app skips that step, the orphaned copies keep running with no client connected to them. This is a known open issue in Claude Code, and the same bug lives in Copilot CLI. The leak shows up across tools because the spec only recommends the cleanup, it does not require it.

Third, the layer nobody expects: your AI apps read each other’s configs. ChatGPT’s Codex engine imports Claude’s MCP configuration and spawns the same fleet on its own.

I watched it happen. Three minutes after I cleaned the fleet out of my Claude config, ChatGPT spawned a fresh copy of all ten servers from a snapshot it had taken at launch. Configure a server once, and three apps each run their own copies of it.

A normal working week: 14 sessions across 6 projects, three still running, the oldest open for two days. In the per-session world, every row in that sidebar owned a full copy of every server. (UI reconstruction from the app’s design system.)

Now the math behind the 797. I had five gmail accounts configured as separate servers.

Multiply by the sessions I opened across a working day, then by the apps importing the same config, and 123 gmail processes stops being mysterious. It is arithmetic.

Why killing them never holds

The obvious move is to kill them all, so I did, and measuring what happened next is what taught me the real shape of the problem.

A SIGTERM sweep of the whole fleet freed 5.1 GB in seconds: free RAM went from 173 MB to 5.3 GB, and the machine was fast again.

Eighteen hours later the census read 474. The processes were back because the architecture that spawns them was untouched. Every new session rebuilt its private fleet, and closed sessions kept failing to reap.

Cleanup scripts have a second, quieter problem: they hunt for orphans, and there are none. The classic definition of a leaked process is one whose parent has died, leaving it reparented to the system.

Across all 37 reports, the orphan count was zero in 21 of them, report after report, while the machine kept running out of memory. All 797 processes had a living parent process. They were legitimate child processes, not orphans, and orphan-hunting logic cannot see them.

Sometimes the honest fix is deletion, not architecture. For me, a Cloudflare MCP server with 87 tools pinned a CPU core near 100% for five and a half hours, twice.

I replaced it with the wrangler CLI, which covers the same platform on demand with zero idle processes. If a heavy server duplicates a CLI you already have, remove it and keep the CLI.

For everything else, the fix is structural.

Share

How to Fix the Problem for Good

Everything above is the diagnosis. This is the repair: the architecture that ends the multiplication, the tool that packs it into one install, and the exact steps to move every server behind it and prove it held.

The fix is architecture: one server, many clients

Once you see the problem as multiplication rather than leakage, the fix follows directly, and the computing world solved this problem decades ago.

Unix solved shared-service access with daemons: one long-lived process, with many clients connecting through a single socket. Databases repeat the pattern with connection poolers like PgBouncer. MCP’s ecosystem is converging on the same pattern, and the pieces sort into three groups.

The first group is daemons and brokers, which keep one instance of each server alive for every client that asks.

The second is transport bridges, which translate a stdio server into the kind that can be shared over a local address.

The third is framework proxies, which bundle several servers behind one endpoint in code. What every one of them does, underneath, is replace many private copies with one shared instance.

The daemon shape works because MCP’s second transport allows it. Streamable HTTP servers run as one independent process handling many client connections, each carrying its own session.

So the design becomes simple to state: run every server once, expose each at a local address, and point every AI app at it. Clients that speak HTTP spawn nothing of their own. Clients that only speak stdio get a thin shim, a pipe adapter of a few dozen MB, instead of the full server.

Who built mcporter, and why it fits

Before you install anything, it helps to know who made the tool you are trusting with every server on your machine. The provenance here is unusually good, and it explains why the tool fits so well.

I built mine on mcporter, from OpenClaw creator Peter Steinberger. He built the agent and its MCP layer together, rather than bolting one onto the other, and it shows.

The daemon, the HTTP bridge, and the stdio shims all live in one installed tool that already knows how they fit. That is why one tool covers the whole job here, instead of three stitched together.

There is a second reason I trust the pattern, and it is the most convincing kind. Two of my agents never had this problem at all.

If you run Hermes, it uses mcporter as its MCP layer by default, so it started life with the shared architecture this whole fix builds toward. OpenClaw centralizes its own server definitions too, which keeps its duplication surface small, though its registry is its own rather than mcporter’s.

The point stands either way. Every client above broke in its own way precisely because each one keeps its own copy of the wiring. The two that keep none stayed clean the whole eleven weeks, while my Mac overheated.

Set up the mcporter daemon

Start with one server and prove it works before you touch a single existing config, because a shared daemon becomes a dependency for every client and you want to trust it first.

The commands below pin mcporter 0.12.3, the version I tested. Newer releases may change the config format, so check the docs before mixing a newer package with this exact block.

Install it, and confirm the version:

npm install -g mcporter@0.12.3
mcporter --version

Define one server in ~/.mcporter/mcporter.json, copying the command, args, and env straight from one of your existing client configs:

{
  "mcpServers": {
    "tavily": {
      "command": "npx",
      "args": ["-y", "tavily-mcp"],
      "env": { "TAVILY_API_KEY": "YOUR_KEY" },
      "lifecycle": { "mode": "keep-alive" }
    }
  }
}

That file holds credentials, so lock it down with chmod 600 ~/.mcporter/mcporter.json.

Start the daemon, then expose every server at one local address:

mcporter daemon start
mcporter serve --http 8848

Each server now answers at http://127.0.0.1:8848/mcp/<name>, and mcporter list tavily verifies it end to end by returning its real tool names. Run that check on every server as you add it. Mine caught a search server that had been silently broken in every config for months, because its package had renamed its binary and nothing had ever tested it.

Make it survive reboots with a LaunchAgent, so the bridge starts at login and restarts if it dies. Mine respawned in four seconds when I killed it as a test, and the plist ships in the kit.

One warning before you wire any clients in. I lost about an hour each to three separate traps.

One is a config key that gets silently ignored.
One is a behavior where the bridge does not see new servers until you restart it.
One is a fallback mode where a client spawns its own copy anyway if the daemon is not ready when it starts.

Each has a fix, and all three are written up in the kit’s runbook. The path above works; the traps cost time when you do not know they are coming.

Connect Claude, Cursor, and ChatGPT

Move one server at a time, verify it with a real call, and only then delete its old entry, so a working client never breaks mid-migration.

Each client speaks to the daemon differently. Claude Code and Cursor both accept a plain local URL, so they connect to the shared server and spawn nothing of their own. Claude Desktop only validates stdio entries in its config, so it gets a thin shim: a small adapter that forwards to the daemon instead of starting a full server.

ChatGPT is the one to get right, and it is where the migration broke for me. On my build, a plain URL in ~/.codex/config.toml produced an error that blocked the thread from resuming at all: url is not supported for stdio. The fix that worked was the same shim Claude Desktop uses, pointed at the daemon with the full path to mcporter:

[mcp_servers.tavily]
command = "/absolute/path/to/mcporter"
args = ["serve", "--servers", "tavily", "--stdio"]

Finally, comes the step that actually ends the sprawl: delete the old stdio entries from every config, keeping a backup first. As long as one config still defines a server the old way, sessions on that config rebuild it, and ChatGPT will faithfully import and copy whatever you leave behind.

Prove it held: the soak test

A fix that survives an afternoon proves nothing, since mine already regrew from 23 to 474 processes in eighteen hours once. The real test is the next morning.

Run the census test again a full day after you migrate. Three signs tell you it held: the count stays flat instead of climbing, mcporter daemon status shows your servers connected with recent activity, and no app shows its own npm exec servers after a relaunch.

One pattern is not a failure, and it is worth knowing so you do not misread it. ChatGPT threads you created before the migration carry their old config and respawn the old servers when you reopen them. Those die when the thread closes, so judge the soak by whether new sessions stay flat, not by what an old thread brings back.

Here is the gap I asked you to hold onto at the start, closed. The 797 processes are 15, and the 13 GB is under 1.

The health check that came back CRITICAL 29 times out of 37 came back clean, and stayed clean through a full day of the same work across all four apps. Same servers, same machine, same load. The only thing that changed is that each server now exists once.

Run the census tonight. If your number is close to your server count, you are fine. If it is ten times that, you now know exactly what has been running your fan.

Share

The MCP Health Kit

You can rebuild everything above by hand, from the census to the LaunchAgent. If you would rather drop it in, the MCP Health Kit is the apparatus as working files.

It has three pieces.

The system-health skill is the diagnostic that generated this article’s 37 reports. It drops into Claude Code, and you run it monthly to catch the next round of multiplication before it heats your Mac.

The migration runbook is the ordered walkthrough, with all five traps documented and fixed. Those are the silently-ignored config key, the snapshot that hides new servers, the shim that spawns a duplicate, the ChatGPT parser that rejects a URL, and the old threads that respawn their birth config.

The working files are the parts you would otherwise write from scratch: the mcporter config template, the LaunchAgent that keeps the daemon alive across reboots, and the copy-paste wiring block for each client.

Claim it with your paid-member account here.

Upgrade to Premium

Next Steps

What you can do today:

1. Run the census now: pgrep -f mcp | wc -l. If the number is far above how many servers you installed, you have the sprawl.

2. Stand up the shared daemon with one server, verify it with a real call, then move the rest over one at a time.

3. The next morning, run the census again. A count that stays flat is your proof the fix held.

If this made your hot, slow Mac make sense, pass it on to someone who runs several AI apps and cannot work out why their fan never stops.

Share

And if someone shared this with you, subscribe free so you catch the next guide.

Subscribe now

What did your census return the first time you ran it?

— Jenny

If you work in AI, odds are you have heard of Hermes Agent.

Not the Hermès handbag. But it is trying to earn the same kind of permanent place in your daily rotation.

You may already use ChatGPT, Claude Code, or OpenClaw. Each can give you that fantastic agent feeling: hand it real work, step away, and come back to progress.

So why add Hermes?
Is the setup another project?
What can it do that the agents you already use cannot?

To answer those questions, I gave Hermes the work that tripped me up most often. The tedious jobs that kept blocking whatever I wanted to do next.

By the end, Hermes had earned a permanent seat in my crew.

This article shows you the three runs that changed my mind, where Hermes failed, and the prompts you can copy into your own setup. Run the same tests, then decide whether Hermes belongs in your stack.

What’s inside:

• What Hermes Agent is, and how it compares to your current tools

• Hermes Agent runs on your existing subscriptions

• Hermes Agent keeps work moving across sessions

• Hermes Agent improves its skills through use

• Is Hermes Agent good? My honest verdict

• Run X research with 1 Hermes Agent prompt

• Keep a rolling job moving with 2 prompts

• Limit unattended Hermes Agent work with 1 setup prompt

• The 3 ways Hermes Agent will burn you, and the rules that stop it

• The Hermes Agent Prompt Kit: grab it at the end

Subscribe now

What Hermes Agent is, and how it compares to your current tools

Long chats slow down. Context gets expensive. So you clear the session and explain the work again as the tool forgets your instruction.

Hermes, built by Nous Research, takes the opposite bet by persisting chat sessions. That persistence runs on three mechanisms:

• Bounded memory.
  A USER.md capped at 1,375 characters and a MEMORY.md capped at 2,200. When the files are full, Hermes must consolidate and decide what to keep.

• Skills it writes itself.
  Every ~15 turns, a background process replays the session and asks whether a completed workflow is worth keeping. If permitted, it writes the procedure as a SKILL.md and loads it next time instead of re-reasoning from scratch.

• Recall you can query.
  Every conversation lands in a local searchable session database. Past work comes back by search, not by you re-explaining it.

On top of being a CLI tool, Hermes now also ships as a desktop app. On my Mac, I downloaded it, dragged it into Applications, and opened it. The terminal install is still there if you prefer one curl command.

That setup was much shorter than the one I used for my OpenClaw series.

My install opened with 27 built-in toolsets, 18 of them enabled: browser automation, code execution, macOS computer use, cron jobs, cross-platform messaging, and more.

The gateway was running. The model picker sat in the status bar. Sessions, skills, messaging, and artifacts each had their own pane.

In my stack, Claude Code, Codex, and Cursor center the active work session.

Hermes and OpenClaw add memory, schedules, messaging, and state that survives the chat.

OpenClaw is gateway-first. One long-lived process handles scheduled events and messaging. Its skills come from a marketplace.

Hermes adds an agent-managed learning loop. It writes skills from completed work, then loads them the next time the same job appears.

Hermes also lets me choose the provider. I ran it on my ChatGPT and Grok subscriptions instead of sending the work through metered APIs.

Share

Hermes Agent runs on your existing subscriptions

Direct X API calls were costing me about $1 a day for light scraping.

Hermes moved that work onto the Grok subscription I already paid for.

I connected Grok through xAI OAuth, then asked Hermes to research Marc Lou’s product portfolio. It used native Grok x_search, while my personal X API stayed on the unused-tools list.

The full pass spent zero X API credits.

Hermes mapped 20 to 30 products and isolated the five receiving real attention. It kept @zilvestro’s customer story beside the claim and marked a viral “government ban” post as satire.

It was faster than any X API workflow I had run. It also returned a research trail already separated into founder claims, user claims, and jokes.

That is the 1+1>2 effect: one subscription became both the search layer and the reasoning layer.

Share

Hermes Agent keeps work moving across sessions

Marc Lou is just one person I track. The rest sat across GitHub repos, product pages, posts, and experiments.

Most of them were parked in a browser tab I swore I would get to.

One Chrome profile held 20 tabs. Several profiles were open at once. The laptop ran hot enough that I could hear the fan.

Closing them felt like losing work I still wanted to read, test, or run. So the pile stayed open.

This time I handed the pile to Hermes. It collected 76 tabs across four Chrome windows.

I narrowed them to 47 tasks: read this article, scout that method, test the skill, tear down the repo.

Then I gave Hermes one rolling job to work with.

Across fresh runs, Hermes executed code, trialed a skill against a sample folder, and surveyed 159 repos. It reached 15 of 47 tasks before I called it.

Below is an example of how it tested an instagram skill I had parked in my trial list for too long:

And after that are the statuses of each of the 47 tasks.

Incomplete. Still moving.

Getting the cron to fire on its own took one fix. Before that, I was the heartbeat.

Once the pile became a ledger, I closed the 76 tabs and let the laptop cool.

The ledger helped me close the learning loop I had always wanted: queue the work, run it, decide what to do with the result, then move to the next task.

Share

Hermes Agent improves its skills through use

The learning loop had one more thing to prove. Could Hermes correct a bad procedure after the work exposed it?

The session exploring vidIQ MCP gave it the chance. VidIQ MCP is built for Youtube analytics, I wanted to use this to help me explore youtube in batches.

Hermes found the vidIQ MCP configured but disabled. It enabled the server, hit a 401, switched to OAuth, opened the browser flow, and verified 46 tools after authorization.

It checked. Failed. Fixed. Confirmed.

Then the skill told me to run /reload-mcp.

That command did not exist.

Hermes checked the official command reference and patched its own SKILL.md while I watched. The corrected instruction held for the rest of the session.

That is what makes agent skills useful here. The skill kept the working route, the dead end, and the correction that replaced it.

The same loop can overwrite a skill you set by hand. With learning enabled, Hermes writes new skills and edits existing ones in the background.

Turn on write approval. Then every proposed change waits for your sign-off, and the record shows exactly what Hermes tried to rewrite.

Share

Is Hermes Agent good? My honest verdict

Hermes is strongest when the work needs to outlive one chat. It can run through models you already pay for, resume a job from files, and correct a skill after the procedure fails.

I use it inside the wider AI agent system I run in production. I still supervise the result.

Three things will bite you. All are fixable.

• It can mark the wrong result done.

• An enabled cron job does not prove the gateway is running.

• Its chat history does not give you a clean job status.

I run it as supervised autonomy. The agent grinds, I keep the verdict and every release action.

Starting the run is easy. Making it reliable takes the real work. You need to know it used the right provider, resumed the right job, and produced something safe to trust.

The paid section gives you the step-by-step setup and exact prompts for four jobs:

• Run X research through Grok

• Keep a job moving across fresh sessions

• Bound unattended work

• Catch false completion

The Hermes Agent Prompt Kit packages the complete setup into one folder.

Upgrade to Premium

How to run X research with 1 Hermes Agent prompt

Read more

Claude runs my Substack growth now. For a long time, the thing slowing it down was me.

Not the strategy. Not the tools. Me.

I knew what to do to grow on Substack. I just could not keep up with doing it.

In the last six months, I moved houses twice. Twice.

Every writing cadence I had set, every posting schedule, every plan, I dropped most of them because I was living out of boxes.

On top of that: a full-time job and two little kids. There is not much spare time in that, and there is even less spare energy.

I kept coming back to the Pareto principle, the old 80/20 rule. Most of a job is the mechanical, repeatable, trackable part, call it 80%. The meaningful part, the judgment and the voice, is the 20% left over.

So I started asking simple question about Substack: what can I hand off, and what do I want to keep for myself? The answer turned into eight workflows.

Gradually, I took the parts of Substack growth I cannot realistically keep track of, and handed them to Claude. And only kept the parts I enjoy.

Of course, Claude did a much better job than I could (before March).

All Claude handled were just eight workflows that took over the 80% I used to grind through by hand. This session will break down all of them.

What’s inside:

• The 3 stages everyone on Substack moves through

• The one MCP that runs all eight workflows (it is already included in your subscription)

• The full live build, all eight workflows in Claude:

  • How to turn your entire subscription inbox into one scannable read

  • How to size a niche before you spend a month on it

  • How to tear down exactly how a top creator wins: their titles, their SEO, their cadence

  • How to turn one post into a week of notes in your own voice

  • How to schedule a week of notes and walk away

  • How to find the utility winner, the note that quietly did the work

  • How to rank your posts on real conversion and pull your next article ideas

  • How to read the subscribers you already have and see who actually converts

  • The complete loop, where measurement feeds the next week of writing

  • Live from the session: the workflow that broke on camera, how I debugged it, and what the room is using Substack for

• What to do this week, in order

• Session timeline with timestamps

🎁 The full recording, the deck, and all eight workflow prompts are in the Build to Launch community portal.

The Three Reasons You’re on Substack

I opened the session with one question in the chat: what are you using Substack for?

One, to learn and read. Two, to build your own publication. Three, to grow toward monetization.

Four people answered, and I got four different stages.

One was mostly here to learn. One was building his own publication. One named brand, one picked all three at once.

That spread is the point. Most of us do not live in one box. You start by reading, you drift into building your own voice, and eventually you want the work to pay you back.

The engine has three stages because the path has three stages, and it meets you at whichever one you are standing in.

This is the same arc I laid out in everything I have learned about growing on Substack. The difference now is that the manual clicking runs as workflows instead.

What I Hand to Claude

Across those three stages, I run eight workflows. Here is the whole set, in the order I reach for them.

1. Subscription Brief turns my entire subscription inbox into one short, themed read. Reach for it when you follow more than you can keep up with and want the two worth opening today.

   

2. Landscape Explorer sizes a niche before I commit a month of my life to it. It is for weighing a topic or a pivot: how crowded it is, whether anyone pays, before you write a word.

   

3. Creator Study tears down exactly how a top creator wins. Use it when someone in your lane is clearly working and you want their real playbook: their cadence, their titles, what they gate.

   

4. Notes Engine turns one long post into a batch of notes in my voice. This is daily visibility without daily writing: one article becomes a week of notes.

5. Scheduler queues those notes so I write once and walk away. It is for when you can write but cannot keep showing up.

6. Notes Performance tells me which notes worked, and which quietly did the work. Reach for it when likes are lying and you want the note that pulled clicks and subscribers.

7. Posts Performance ranks my articles on real conversion and hands me what to write next. Good for the blank page: your next ideas, each traced to a post that already converted.

8. Subscriber Study reads the readers I already have and shows who converts. Use it when you are chasing new subscribers and forgetting the list you already own.

You do not need all eight to start. You need the first one today, and the rest as each stage becomes practical for you.

The full live build

Here is what we built, step by step.

Read more

You have read that open-source AI is catching up.

DeepSeek beat this. Qwen beat that. Llama is free and everywhere.

That story is real. It is also hiding two things that change what you should do about it.

The first: almost none of it is open source. The second: the free models are not a gift. They are a weapon aimed at whoever charges you for AI, and in 2026 the weapon changed hands.

I went looking for an open model to run a high-volume job cheaply. I expected to spend the afternoon comparing benchmarks.

Instead I spent it figuring out which “open” models I was actually allowed to build on. Why the one topping the leaderboard is Chinese. Why the same model charged me four different prices depending on where I clicked run.

The landscape is not confusing because the technology is hard. It is misleading because three different things wear the same word. A license, a strategy, and a hosting bill all call themselves “open,” and nobody separates them for you.

So here is the map, in the order it actually matters.

What’s inside:

• The Open-Source LLM Field Guide: Five Buckets for Every Name: the map that sorts every lab, model, license, host, and metric, so no name is left homeless.

• Open-Source vs Open-Weight: Why Most “Open” LLMs Aren’t Actually Open Source: what “open” really means, and the license clause that can bill you.

• Who Ships Open Models Now, and Why the Leaderboard Went Chinese: the current map, and the surprise at the top of it.

• Why Would Anyone Give Away a Frontier Model? Open Weights Are a Weapon: the strategy behind free models, and what makes them survivable.

• How to Read an Open Model’s License Before You Ship: the pre-build check that keeps a “free” model from becoming a legal problem.

• How to Pick Where Your Open Model Runs: Groq, Together, Bedrock: same model, different physics, and how to choose.

• How to Decide Between an Open Model and Claude or GPT: when open saves real money, and when closed still wins.

• The Open-Model Decision Card, and Why Your Moat Is Never the Model: the one-page call sheet, and where durable value lives.

By the end: you can pick an open model, its license, and its host for a real project, and know when not to bother.

Subscribe now

The Open-Source LLM Field Guide: Five Buckets for Every Name

The map has five layers, and every name you are about to meet sits on one of them.

They stack in an order, so start at the top.

A lab trains the model: DeepSeek, Meta, Alibaba’s Qwen team, Mistral, Moonshot.

What they ship is a model, an actual file of trained weights, usually a family in a few sizes: DeepSeek V4, Llama 4, Qwen3, GLM-5.

Every model ships under a license, the fine print on what you are allowed to do with those weights. This is where “open” gets slippery enough to fill the next section.

Then comes the layer that decides your build. You never need to download a frontier model onto your laptop, so it runs on someone else’s GPUs behind an API, and that someone is a hosting lane. There are five of them, and picking one is discussed in depth below.

The last layer is the measuring sticks you judge lanes on. A token is a chunk of text, very roughly three-quarters of a word, and it is the unit everything is priced in. The rest are dollars per million tokens, tokens per second for raw speed, and time to first token for lag.

Five layers, one order: a lab trains a model, the model ships under a license, you run it through a host, and you judge the everything on a few numbers.

Open-Source vs Open-Weight: Why Most “Open” LLMs Aren’t Actually Open Source

Open source has a definition, and most “open” models fail it.

The Open Source Initiative sets the bar: release the weights, the training data information, and the code that built it. The license must let anyone use, study, modify, and redistribute it for any purpose.

Open weight clears a much lower bar. You get the finished weights, a license, and little else.

That gap is not academic. The OSI looked at Llama and ruled it out: “Meta is confusing ‘open source’ with ‘resources available to some users under some conditions.’”

Some conditions. Here is one.

Llama’s license has a ceiling at 700 million monthly active users. Cross it on the model’s release date, and you must request a license from Meta, granted “in its sole discretion.” A size exists at which your right to use the model switches off.

There is another place. Llama 4’s multimodal rights are not granted to companies based in the European Union, and every Llama 4 model is multimodal. A European company installing Llama 4 to train on images is outside the license before it writes a line of code.

The traps are not only Meta’s. MiniMax M3 sits near the top of the open leaderboard, yet its license grants use “for non-commercial purposes”. Commercial use above $20M a year needs “separate, prior written authorization.”

A model everyone calls open, and you cannot legally build a business on it without asking first.

For contrast, look at what fully open looks like. AllenAI’s OLMo 2 ships the weights, the training code, the checkpoints, the logs, and the actual dataset, under Apache 2.0.

You can rebuild it. Almost nobody else lets you.

That is the real cost of open weight. Without the data and the recipe, you cannot audit the model for what it was trained on, you cannot reproduce it, and you inherit whatever legal exposure is buried in data you never saw.

You are not owning open source. You are renting a black box under a EULA. Read the license before the benchmark.

Who Actually Ships Open Models Now, and Why the Leaderboard Went Chinese

The roster changed faster than my mental model.

Here is who ships a current open-weight flagship as of July 2026:

On Artificial Analysis’s open leaderboard, the top open models are GLM-5.2, MiniMax-M3, DeepSeek V4, and Kimi K2.6.

Surprisingly (or not), every one of them is Chinese. Meta, Google, and Mistral trail.

The companies that made “open” a marketing word are quietly walking away from it.

Meta shelved Llama 4 Behemoth, its biggest model, and in April 2026 shipped Muse Spark, its first closed, API-only frontier model. Alibaba kept its small Qwen tiers open and made its flagship, Qwen3.7-Max, proprietary.

Read those two moves together and a pattern falls out. Leading on open is now a challenger’s play, not an incumbent’s. The labs that already have distribution are hedging back toward closed, while the labs trying to take share give their best work away.

Which raises the obvious question.

Why Would Anyone Give Away a Frontier Model? Open Weights Are a Weapon

Nobody spends nine figures training a model and releases it out of generosity.

Mark Zuckerberg said the quiet part in his 2024 open-source letter. Meta open-sources so it is “not locking into a competitor’s closed ecosystem where they can restrict what we build.” He compared it to being “constrained by what Apple will let us build on their platforms.”

Strip the framing and the logic is simple. Push the price of one layer to zero so you can sell or protect the layer next to it.

Meta’s real business is apps and ads, not model API calls. A free frontier model does two jobs at once: it commoditizes the paid product that OpenAI and Anthropic sell, and it keeps Meta off anyone else’s platform toll.

Meta never needed to sell the model. It needed the rival’s version to stop being worth paying for.

Then the weapon changed hands.

Once Meta had ecosystem share, it started hedging back to closed. Meanwhile the Chinese labs picked the weapon up and aimed it at everyone. DeepSeek V4-Flash runs at $0.09 per million input tokens, and Chinese open weights now make up around 61% of the top-model token traffic on OpenRouter.

When your capability is a commodity, giving it away costs you little and costs the incumbent charging for it a lot.

That only works if serving the model is cheap. The design decision that makes it cheap is the mixture-of-experts architecture.

DeepSeek V3 has 671 billion parameters, but only 37 billion are active per token. A router picks a handful of expert sub-networks for each token, so the compute and the memory bandwidth you pay for scale with the active count, not the total. The model holds 671B worth of knowledge and serves at roughly 37B worth of cost.

That decoupling is the reason frontier-grade output costs pennies in 2026 and could not in 2023, when a dense model computed every parameter for every token.

One more number deserves a second look. You have seen the claim that DeepSeek trained V3 for $5.6 million.

That figure is the final training-run compute only, about 2.788 million GPU-hours at $2 each, and the paper says so plainly. It excludes the research, the failed runs, and the hardware.

SemiAnalysis put the real server bill closer to $1.6 billion, noting the headline number “does not include research and development, infrastructure, and other crucial costs.” Same lesson as the license. The number everyone repeats is not the number that is true.

That is the strategy and the economics. You can see the game now: open weight, not open source, and a price war nobody is calling a price war.

The rest of this guide is the part you can act on: which license won’t bite you, where to run the model, and whether to use an open one at all. It all comes together in the Decision Card at the end.

How to Read an Open Model’s License Before You Ship

The license, not the benchmark, is what can stop your product. Read it first, and read it for four things.

First, a user or revenue ceiling. Llama switches off above 700M monthly active users; Kimi K2’s Modified MIT adds attribution duties above 100M users or $20M a month. You will likely never hit these, but “likely never” is a business decision, not a default.

Second, a geographic carve-out. Llama 4 excludes EU companies from its multimodal rights. If your users or your servers are in the wrong place, the license is already broken.

Third, a commercial gate. MiniMax M3 is non-commercial unless you get written authorization. This is the one that surprises people, because the model is free to download and still not free to sell against.

Fourth, attribution and naming. Llama makes you display “Built with Llama” and prefix any model you train on its outputs with “Llama.” Minor, but it is a contract term, not a suggestion.

Sort every model into one of three tiers and the decision gets fast.

Apache 2.0 and MIT models ship freely: Mistral Large 3, Gemma 4, DeepSeek V4, GLM-5.2.

Open-weight-with-limits models need a ceiling check: Llama, and Qwen’s larger tiers.

Non-commercial models like MiniMax M3 you skip unless you plan to ask.

One trap: licenses change per version. Gemma 1 through 3 shipped under Google’s restrictive terms; Gemma 4 moved to Apache 2.0. Check the version you are shipping, not the family you remember.

How to Pick Where Your Open Model Runs: Groq, Together, Bedrock

The same open model is a different product depending on where you run it. Speed and price swing wildly with the host, and picking one is a real decision, not a detail.

Take gpt-oss-120b. In July 2026 on Artificial Analysis, identical weights run at 1,987 tokens per second (raw output speed) on Cerebras. They run at 480 on Groq.

DeepInfra serves it at about $0.05 per million tokens. Their summary: a 314% speed spread and a 2.6x price spread on one model.

Step back, because the word host hides the mechanics.

An open model is not something you download and wrestle onto your laptop. It sits on someone else’s GPUs, behind an API endpoint you call over the internet.

The question is whose GPUs, and that comes down to your workload:

• Just starting: a serverless API. Together, Fireworks, or DeepInfra keep the model running and bill per token, from roughly $0.09 to $1.74 per million. You grab a key and you are calling it in minutes.

• Latency is the product: speed silicon. Groq and Cerebras run open models on custom chips, several times faster for a small premium.

• Regulated: a cloud bundle. AWS Bedrock, Vertex, or Azure run the same models on the invoice you already pay, next to your data and behind the IAM you already set up.

• Past ~100 million tokens a month: self-host. Rent GPUs and serve with vLLM, or run a smaller model locally with Ollama; a fixed GPU bill finally beats per-token pricing.

• Don’t want to choose: an aggregator. OpenRouter fronts seventy-plus of these providers behind one API key, so you switch hosts by changing a string.

Prices swing by host and model: the same DeepSeek V3 runs from $0.38 to $0.89 per million tokens across hosts. Artificial Analysis has the exact figure for every model on every host, so check it before you commit.

Whichever you pick, using it looks almost like using Claude or GPT. You get an API key and point your code’s base_url at the host’s endpoint. Most are OpenAI-compatible, so the call you already write barely changes.

Now, why the spread? Same outputs, different physics underneath, and it comes from hardware, not quality.

Groq’s LPU keeps the model in on-chip SRAM, runs deterministically with no runtime scheduling, and drops the high-bandwidth memory that GPUs rely on. That buys latency and gives up capacity, so the model has to be sharded across many chips. Cerebras makes the same trade at wafer scale.

The GPU hosts, Together and Fireworks and DeepInfra, batch many requests on H100s and B200s. That maximizes throughput per dollar and raises the time to first token.

So fast and cheap are not two quality tiers. They are two design philosophies, and you pick by your workload: real-time voice needs the fast lane, bulk overnight processing wants the cheap one.

The cloud bundle looks overpriced until you see what it sells. AWS Bedrock runs open models at a premium to Groq, but it is not selling the model. It is selling unified billing, IAM, no data egress, compliance, and keeping inference next to data you already store on AWS.

For a regulated team, that bundle is the product and the model is the loss leader.

Notice the move, because you have seen it before. The provider’s margin on the model itself is racing toward zero, that $0.38 floor barely above the cost of serving it. They give the model away at cost to sell the thing beside it: raw speed, custom silicon, or the cloud bundle.

It is the same play the model labs ran, one floor up.

How to Decide Between an Open Model and Claude or GPT

Start with the honest part. At the frontier, closed still wins.

The best open models trail the best closed ones by a 3 to 6 point Intelligence Index gap, down from about 13 a year ago but not gone. The gap widens on the hardest reasoning and agentic tasks, and closed models hallucinate less. If your product lives or dies on the single hardest 5% of requests, pay for the closed model and move on.

Everywhere else, open has real, specific wins. There are four worth knowing.

The first is cost at scale.

The crossover sits around 100 million tokens a month; below it, a managed API is usually cheaper once you count ops. One team that moved two high-volume pipelines to self-hosted Qwen cut costs from $1.50 to $0.15 per million tokens, 90%, and still warned that below roughly 100k requests a day the managed API wins.

The second is privacy.

If you cannot send data to OpenAI at all, a self-hosted open model is the GDPR-clean path, and there is no closed equivalent.

The third is latency.

For real-time work, Cerebras serves Qwen at about 525 tokens per second against roughly 92 for a standard closed API.

The fourth is control.

You own the weights, so no vendor deprecates your model out from under you, and migrating is a change of base URL.

What working builders do is route by task. Send bulk, private, and high-volume work to an open model, send the hardest reasoning to a closed one, and keep a closed fallback wired behind a feature flag.

The question was never open or closed. It is which job, at what volume.

The Open-Model Decision Card, and Why Your Moat Is Never the Model

Everything above collapses into one page. Save it for your references:

THE OPEN-MODEL DECISION CARD  (as of July 2026)

1. LICENSE: check before the benchmark
   - Apache 2.0 / MIT: ship freely (Mistral Large 3, Gemma 4, DeepSeek V4, GLM-5.2)
   - Open-weight + limits: check the ceiling (Llama = 700M MAU + no EU multimodal;
     Qwen large tiers = 100M MAU)
   - Non-commercial: needs written OK (MiniMax M3). Skip unless you'll ask.
   - Grep the license for: user/revenue ceiling, geographic carve-out,
     commercial gate, attribution.

2. HOST: same model, different physics
   - Need speed (real-time, voice): Cerebras / Groq (specialized silicon)
   - Need cheap (bulk, batch): DeepInfra / Together / Fireworks (GPU batching)
   - Need the bundle (already on AWS/Azure, compliance, data-gravity):
     Bedrock / Vertex
   - Compare the same model across hosts on artificialanalysis.ai first.

3. OPEN vs CLOSED: which job, what volume
   - Under ~100M tokens/mo, no privacy need: closed API usually wins
   - Over ~100M tokens/mo, or on-prem/regulated, or need sub-0.3s latency: open
   - Hardest reasoning / agentic / multimodal: closed, still (3-6 pt gap)
   - Default: route by task, keep a closed fallback behind a flag.

Now the part that outlasts the card. The same logic that made the model free is already eating the layer that runs it.

Gartner expects inference on a trillion-parameter model to cost over 90% less by 2030. In 2023, a16z argued that infrastructure was capturing the value in AI. By 2026 that flipped: the durable moats are proprietary data, deep workflow integration, and distribution, and “model selection is closer to a commodity choice than a competitive advantage.”

Which tells you where to spend your effort.

So pick the cheapest model that clears your quality bar, run it on the host that fits the workload, wire a fallback, and stop treating the model like the asset. The model is the commodity. What you build around it is the company.

Next Steps

What you can do today:

1. Pull the license of the open model you are eyeing and check it for the four clauses: a user or revenue ceiling, a geographic carve-out, a commercial gate, and attribution.

2. Drop one model into artificialanalysis.ai and compare it across a fast host and a cheap host before you commit to either.

3. Write down the monthly token volume where you would move a task off Claude or GPT to an open model. That number is your switch point.

If this made the open-model landscape navigable, share it to someone who will also benefit from reading it.

Share

And if someone shared this with you, subscribe free so you don’t miss the next guide.

Subscribe now

Which open model are you reaching for first, and what are you running it on?

— Jenny

Why Upgrade · Practical AI Builder Program · Claude Hub · AI Agents

For a long time, I was my AI’s memory.

Not because it had none. It had plenty. ChatGPT remembers. Claude remembers. My agents on OpenClaw remember.

The problem is the kind of memory.

It’s linear. A running log. Each new thing pushes the old ones down, then out. It keeps what’s recent and drops the arc.

So it can’t answer the question I actually care about. Pull up one topic across my whole history. What I thought, what I researched, what others said, how it evolved, where every file lives.

A log was never going to hold that shape.

You could make the AI read back through everything, every time, to find what connects. I tried. It is slow, and the token bill is brutal. You can’t afford that on every lookup.

So what you need isn’t a better log. It’s a second brain.

A connected store of everything you know and have done. You land on one idea, and everything tied to it comes up with it. Across your whole history. Without re-reading it all.

That’s the thing I was missing.

I got there sideways. Every time I asked AI to read or write my work, it kept pulling me toward markdown. Plain text files.

And markdown is the first thing Obsidian is built on.

So the jump was small. Put my notes where the AI already reads best. Then connect them.

I went through every question I had about Obsidian until it clicked. Then I wired it to Claude.

That was the day I stopped being the memory.

This is the build, start to finish. The notes, the connection, the setup.

What’s inside:

• What makes Obsidian so good

• Why Obsidian and AI work together, and the tools that extend it

• What a connected Obsidian + Claude second brain looks like

• How to connect them: the bridge

• How to set up Claude to run it

• How to keep the vault organized so Claude finds the right note

• By the end: an Obsidian vault Claude Code reads, updates, and interlinks as your second brain

• The obsidian second brain kit: grab it at the end

🎁 The Obsidian Second Brain Kit: the pre-built vault, the context-file templates, the bridge setup sheet, the self-updating skills, and the cleanup checklist.

Subscribe now

What Makes Obsidian So Good?

Obsidian is a free notes app that stores every note as a plain .md file on your own computer.

No cloud account. No database you can’t open. If Obsidian disappeared tomorrow, your notes still open in any text editor.

It has three parts:

1. A folder, also called vault, is where all your notes are saved;

2. .md files, also called notes, is the format that stores your notes, one idea at a time;

3. A graph, shows the connection between all saved notes.

The connection and relation of files are made possible by two built-in features:

1. Links.
   Also known as wikilinks after the wiki-style brackets. Type a note’s name in double brackets in another note, [[Example Note Name]], and the two are connected.

   

2. Properties
   They are custom fields at the top of a note: status, source, project, date. Written as plain YAML, they let Claude read the note as data, not just prose, and you can sort and filter on them like a table.
   Tags are a special type of property, they are searchable and clickable in Obsidian.

   

The links + notes build a graph view, which turns your vault into a picture.

Every note is a dot. Every link is a thread.

A vault with no links is dust: notes floating, nothing touching. Add links and it clusters. You can see which ideas belong together and which are stranded.

The search within Obsidian is cheap and crazy fast.

A developer tested it on a 4,663-file vault. Finding the disconnected notes by brute-force grep took 15.6 seconds. Through Obsidian's index: 0.26, about 60 times faster. Have an AI do the same scan by reading every file and it burns roughly 7 million tokens. Through the index, about 100. Same answer, 70,000 times cheaper.

Why?

When your vault loads, Obsidian reads every note once and builds an in-memory index called the metadataCache: every link, tag, heading, and property in the vault.

After that, it works from the index. A link resolver maps every [[wikilink]], so backlinks and orphans surface instantly, with no full-vault scan.

Your notes are still plain .md files. The index sits on top. You get database speed without trapping your notes in a database.

You made the connection once. Next time you land on one idea and the connected ones come with it, because the connections were stored once and the index keeps them ready.

That is the Obsidian side.

Now you may say, sure, Obsidian seems powerful in note-taking and graph-drawing, but what makes it so special with AI?

Share

Why Do Obsidian and AI Work Together?

If you’ve been building with AI for a while, you already know the pattern: Markdown files are first-class citizens.

Obsidian treats Markdown files the same way.

Same foundation. That is why the pairing works.

Obsidian gives Claude four things at once: readable files, a steady stream of source material, writable memory, and paths to follow.

Put those together and you get the shape of a graph memory agent: your vault as long-term memory, Claude as the part that reasons over it.

Reason 1: Claude can read it

Obsidian’s rules happen to match what Claude reads and writes best:

• Markdown gives it clean text.

• Wikilinks give it paths between ideas.

• Properties and tags give it filters.

• One idea per note gives it the exact thing, not a 5,000-word file to wade through.

You do not have to teach Claude a new format. Obsidian already speaks it.

Reason 2: the vault keeps getting fed

Obsidian is built for capture.

Your own ideas, meeting notes, book quotes, articles, and videos can all land in the same vault.

The online half is the Web Clipper, Obsidian’s official browser extension. Click once on an article and the page lands in your vault as clean markdown. On YouTube, the same button saves the page in a stripped-down read mode. Highlight as you read, and each saved sentence keeps a link back to the exact spot.

Everything you read and watch becomes something Claude can reason over.

Reason 3: Claude writes back

Open a normal AI chat, solve a problem, close the tab.

Tomorrow the work is gone.

A vault breaks that. Claude is not read-only here. Every session can write what it worked out back into your notes.

What you figured out today is there tomorrow.

That creates the flywheel:

• The AI writes better notes.

• The better notes give it more context.

• The next answer is sharper, and that gets saved too.

Your knowledge compounds instead of evaporating. After a few weeks, the vault stops feeling like storage and starts feeling like it’s thinking with you.

Reason 4: Claude can navigate without drowning

Claude does not need to read the whole vault.

It reads a small map first: a short file that says what exists and where. Then it follows the links to dig only where it needs to.

Ask it, “Which of these people haven’t I followed up with?” It reads the list, follows each link to that person’s note, checks the last date, and answers.

The map gives it orientation. The vault gives it depth. The index keeps every link ready, so following one is near-instant, even across thousands of notes.

The ecosystem extends it

Plugins extend the vault in two directions: how you see it, and how you talk to it.

• Copilot lets you chat with your own notes.
  (I’ve written about how Obsidian Copilot works well with the concept of RAG and building a second brain here)

• Smart Connections surfaces related notes by meaning, even ones you never linked.

• Dataview turns your notes into a database you can query and lay out any way you want.

You need none of them to start. They’re there when you want them.

What that looks like in real work

Once wired, the vault can:

• Pull one topic across your whole history: what you thought, what you researched, how it changed.

• Answer “what did I decide about this?” with the note where you decided it.

• Draft from your own past work instead of a blank page and generic advice.

• Read across everything you’ve saved on a subject and hand back the patterns and the gaps.

• Surface a note you’d forgotten, right when it’s relevant.

Your version will depend on what you feed the vault and how you connect the dots.

Mine became a working memory layer. This is what that looks like.

Share

What Does a Connected Obsidian + Claude Second Brain Look Like?

My vault went through several versions before it settled into this.

Now I use it for five things, all from the same connected vault.

Pull one topic from everywhere

A connected vault lets me ask one question across my whole history.

I can ask, “What did my vault say about SEO?” and Claude pulls the answer from strategy docs, draft notes, GSC data, and old decisions. It gives me the point, then shows the file each piece came from.

No folder-hunting. No rereading everything.

When I want the raw cluster, I can search by tag instead. obsidian search query="tag:#mcp" pulls 428 MCP notes across articles, short-form posts, programs, and products.

One question gives me the synthesis. One tag gives me the whole cluster.

Turn a cluster into a dashboard

A tag search is useful, but 428 notes is still a wall.

So I asked Claude to build me a Base. The structure was already there: status, category, date, tier, tags, folder. Claude turned those fields into a sortable table in one pass.

Now the MCP cluster is a dashboard. I can sort by status, scan stale drafts, filter by category, and decide what to do next.

The notes stay the source of truth. The table is just a view.

Let the graph connect itself

I did not link those notes by hand.

Claude linked as it worked. The graph changed from scattered dots into clusters, then those clusters started connecting across topics.

That is the part I wanted: the vault getting more useful every time work passes through it.

Turn the same cluster into a map

Same notes, different shape.

I asked Claude to lay the MCP cluster out as a mind map. Because the links were already in the vault, it could build the map from the structure: central topic, themes, and the articles under each theme.

Every title is still a real note. Hover to preview. Click to open.

The map is not separate from the vault. It is another way through it.

What changed in my day

The screenshots are the easy part to show.

The real change is the workday.

Before, I was the memory. I guided the AI step by step. I reminded it where to look, what mattered, and what connected.

Now I hand more of that to Claude. It files the note. It links what relates. It pulls old decisions back when I need them. When I write, it drafts from my notes, my past work, and my voice instead of a blank page.

And it does it cheaply without burning tokens, because the index does the work instead of a full re-read.

That is the second brain working.

Something that remembers for you.

Share

You have seen the shape now: Obsidian gives Claude a memory it can read, update, and move through.

The rest is the build.

• Connect Claude to your vault: the setup that lets Claude read your notes through Obsidian’s index.

• Give Claude the right jobs: the prompts that connect, clean, and organize the vault without breaking it.

• Install the skills: so Claude knows how to search, link, write, build Bases, and make maps.

• Set the vault structure: folders, hubs, tags, and note shapes that still work after hundreds of files.

• Keep it alive: the output contract and cleanup loop that stop new captures from becoming clutter.

The Obsidian Second Brain Kit packages that system: the pre-built vault, the skills, the prompts, the setup sheet, and the weekly cleanup. Build it by hand from the steps below, or start from the kit and customize it from there.

Upgrade to Premium

How Do You Connect Obsidian and Claude?

Read more

I lost one entire afternoon arguing with Claude over one rule.

It was right there in my CLAUDE.md. Bold, clear, impossible to miss. Sitting in the middle of a long file.

Claude broke it anyway. So I wrote it again, lower down. Then a third time, louder.

It got worse.

My wording was never the problem. My placement was.

The model doesn’t read your file top to bottom.

It parses it.

It scans for boundaries and weighs position. A rule buried in the middle gets the least attention of all.

I write skills files, prompts, and Substack posts for AI every week. The same placement hides a rule from Claude, and a line from AI search.

Once you see text the way the model sees it, the fix stops being guesswork.

The same move every time: clear boundaries, the important part where it looks.

It works on a prompt, an agent file, and a post you want cited. We walk through all three.

What’s inside:

• Why does it matter if AI can read your writing?

• How does AI read your text?

• How do you write so AI follows it?

• What formats do LLMs like to read: Markdown, XML, JSON, or YAML?

• How do you get cited by AI?

• By the end: you can format any prompt, CLAUDE.md, or post so the model actually uses it

• 🎁 The LLM Format Decision Cheat Sheet: grab it at the end

Subscribe now

Why does it matter if AI can read your writing?

Your words have two readers now. You, talking to the AI. The AI, talking about you to everyone else. Most people write for one and forget the other, and the formatting is what decides whether either one lands.

Three reasons it is worth getting right.

So the AI does what you actually asked. When the model can parse your prompt, you stop running the same request three times to get one clean answer. The fix is small, and it pays off on every prompt after it.

So what you build on top of AI holds up. Wire a model into an agent, an automation, or a workflow, and it only runs reliably when it reads its instructions the same way every time. Readable instructions are a reliable system. Sloppy ones are the bug you cannot reproduce.

So AI can find you, understand you, and recommend you. More people ask ChatGPT or Perplexity now instead of Google. If a model cannot parse your post, your product page, or your site, you are invisible in the one channel that is growing. Format it so the machine reads cleanly, and you become the answer it hands back.

The first two are AI as your tool. The third is AI as your audience. Same move, pointed two ways: write so the machine can parse it. That starts with seeing how it reads.

How does AI read your text?

It scans for structure and pulls out the parts it can find. It does not read top to bottom the way you do.

Picture how you read a page. Left to right, line by line, holding it all in your head. A model does not do that. It breaks your text into tokens and leans on the cues that mark where one thing ends and the next begins. A heading. A blank line. A bullet. Those boundaries are what it grabs.

There is a mechanism under this. A 2025 study called SepLLM (arXiv 2412.12094) found that separator and punctuation tokens pull a disproportionate share of the model’s attention, more than the meaningful words between them. The model leans on your dividers to find its place. A boundary is not decoration. It is a handhold the attention actually grabs.

So a wall of text and the same text broken into labeled sections carry different amounts of signal, even when the words are identical. The prose version makes the model guess where the parts are. The structured version tells it. That is the first thing the model does with your text: it organizes by the boundaries you give it.

But position matters even more than structure. Researchers named this “lost in the middle.” A 2023 study from Stanford, Berkeley, and Samaya AI (arXiv 2307.03172) tested models on long inputs and found a U-shaped curve. Information at the very start and the very end gets used. Information in the middle falls off by more than 20 points of accuracy.

A bigger context window does not fix this. It adds more middle. NVIDIA tested 17 long-context models on a benchmark called RULER (arXiv 2404.06654). Most degraded as the input grew, and only about half held up at 32,000 tokens. A 2026 analysis (arXiv 2603.10123) argues the curve is baked into how a causal transformer attends, present from the start of training, which is why a longer window does not erase it.

The cleanest proof that position alone moves results comes from Anthropic. They buried one fact in a long document and asked Claude 2.1 to find it. Recall sat at 27%. They changed nothing in the document. They added one line near the end, “Here is the most relevant sentence in the context:”, and recall jumped to 98%. The same lab found that on complex inputs, placing your question at the end, after the context, improves quality by up to 30%.

Same model. Same document. Same question. The only thing that moved was where the model was pointed.

That is the model you are writing for. It organizes by the boundaries you give it, and it spends its attention on the edges, not the middle. Once you can picture that, writing for it stops being mysterious. You are not learning some AI dialect. You are making the model’s job easier, and it comes down to a handful of rules.

Share

How do you write so AI follows it?

Give the model clean boundaries, and put the important part where it looks. That is the answer, in five moves. No new research here, just what the section above tell you to do every time you write a prompt.

Separate the kinds of information. Instructions in one block, context in another, examples in a third, not fused into one paragraph. There are a few ways to draw those boundaries. The lightest is Markdown headings:

# Instructions
# Context
# Examples

OpenAI’s GPT-4.1 guide says to start there. When the blocks get long or you need harder walls, XML tags do it:

<instructions> ... </instructions>
<context> ... </context>

Anthropic recommends exactly this so Claude can parse each block “unambiguously.” There are no magic tags. Any consistent label works. The point is the boundary, not the syntax.

If Markdown and XML are new to you, do not worry about the syntax yet. You have only met them in passing here. The next section introduces all four formats properly, with what each one actually is.

Put your most important instruction first. This is the CLAUDE.md from the start of this piece (if you have not set one up yet, I’ve written a Claude onboarding guide that covers it). My rule did not fail because it was wrong. It failed because it sat in the middle of a long file. Top of the file, first line under the heading, not buried three rules deep.

For a long input, repeat the key ask at the end. The model reads the edges best, so bracket your request: state it before the context and again after. That is the move behind the jump from 27% to 98%.

Do not strand one critical line in the middle. If something has to live deep in a long document, lift it out. Put it at the top, or wrap it so it reads as its own block. The middle is where attention goes to die.

Keep your formatting consistent. Pick one structure and hold it across the prompt, instead of mixing headings, tags, and loose lists. Which structure to pick, Markdown, XML, or JSON, is exactly the next question.

Share

What formats do LLMs like to read: Markdown, XML, JSON, or YAML?

Four of them: Markdown, XML, JSON, and YAML. Markdown and XML are for talking to a model; JSON and YAML are for handing it data.

You met the first two in passing last section, so time to meet all four properly, definitions first, because the names hide what they are.

Markdown is a lightweight way to format plain text with a few symbols. Simply put: # for a heading, - for a list item, ** for bold. It was built to stay readable as raw text and to convert cleanly into web pages. It is the format you are reading right now.

# Task
- Tone: friendly
- Length: under 50 words

XML (eXtensible Markup Language) wraps every piece of content in a named, nestable tag: <thing>...</thing>. You invent the tag names yourself, which is the “extensible” part, so you can label each piece exactly.

<task>
  <tone>friendly</tone>
  <length>under 50 words</length>
</task>

JSON (JavaScript Object Notation) stores data as key-value pairs and lists, inside braces and brackets. It is the default way programs pass structured data around, and the model reads and writes it natively. OpenAI calls it “highly structured and well understood, particularly in coding contexts,” though it found JSON “performed particularly poorly” as a wrapper for many documents, and every brace is a token.

{
  "task": "write a description",
  "tone": "friendly",
  "length": "under 50 words"
}

YAML (YAML Ain’t Markup Language) holds the same key-value data as JSON, but uses indentation instead of braces, which makes it easier for a person to read and edit. It is what most config files are written in.

task: write a description
tone: friendly
length: under 50 words

Now the split is easy to see. Markdown and XML are how you talk to the model. JSON and YAML are how you exchange data with it. The four side by side:

All three labs land in the same place: structure beats no structure, and the choice matters less than staying consistent. Gemini’s guide puts it in one line, “choose one format and use it consistently within a single prompt.” Mixing Markdown headers, XML tags, and loose JSON in one prompt is worse than picking one and holding it.

Does format actually change accuracy? On older or smaller models, yes, a lot. A Microsoft and MIT study (arXiv 2411.10541) found GPT-3.5-turbo’s accuracy swung up to 40% on the same task from the template alone, and on one task JSON beat Markdown by 42 points. A separate study, FormatSpread (arXiv 2310.11324), found up to 76 accuracy points of spread on Llama-2-13B from formatting choices a person would call cosmetic. Bigger models are more robust. More robust is not immune, and you do not always control which model runs your text.

On token cost, the honest version. There is no authoritative per-format table, so be wary of confident percentages. As a feel for the spread, a quick tiktoken count of the same content lands plain text and Markdown lowest, then YAML, then JSON (in one run, roughly 65, 76, 98, and 117 tokens). The order is solid. The exact numbers are not.

When does structure backfire? When you over-constrain. Forcing a model to answer inside a rigid schema can cost it reasoning room: a 2024 study (arXiv 2408.02442) found stricter format restrictions hurt performance on reasoning tasks. The counter, from dottxt, is that structure matched or beat free-form when you let the model reason first and convert to the format after. The takeaway holds either way: structure your input generously, but do not strangle the output into a tight schema before the model has thought. Let it reason, then format.

That covers what each format is for. The decision, on one page:

Two of those carry a number worth keeping. On a complex prompt, Anthropic found that putting the question last, after the context, improves quality by up to 30%. And on a CLAUDE.md, lean wins: a 2025 benchmark (arXiv 2507.11538) found per-rule adherence drops as instructions stack, to about 68% at 500 instructions, the model favoring the earliest. The “under 200 lines” rule of thumb (techsy) points the same way.

That is writing to a model. The other direction is getting a model to quote you, and that is where the last format finally comes in.

Share

How do you get cited by AI?

Structure a page the way a model likes to read, and you are far more likely to be the source it quotes.

When someone asks ChatGPT or Perplexity a question, it pulls from pages it can parse cleanly and lift in pieces. Same physics as your prompt: boundaries it can find, answers it can extract. The pages that get cited are the ones built like lookups.

This is where HTML finally earns its place. You strip it out when you feed a page to a model, raw HTML is mostly markup, and converting to Markdown can cut the tokens by roughly a third or more. But when you publish, HTML is how a model finds you. Semantic HTML, real headings, lists, and tables, with structured data underneath, is the boundary system a crawler reads. Same principle as everything above, pointed outward.

A few patterns show up again and again in citation studies. These are correlations from SEO and vendor research, not promises from the model makers, so hold them loosely:

• Tables get pulled. Nectiv’s study found ChatGPT citations were 2.3x more likely to include a table than Google’s results, 30% against 13%. A comparison table is a pre-chunked answer.

• Comparison listicles lead. The Digital Bloom’s 2025 report put comparative listicles at 32.5% of all AI citations, the single most-cited format.

• Short answers win. kime.ai found self-contained passages of 40 to 75 words cited about 3x more than longer ones. State the answer, then explain it.

• How-to beats opinion. Presence AI’s data shows how-to pages cited 54% of the time and FAQ pages 58%, against just 18% for opinion pieces. Teach a step; do not just take a stance.

One honest limit, since the question is what crawlers actually parse best. These studies measure content structure, the table, the short answer, the how-to. The narrower question of file format, plain Markdown versus semantic HTML versus JSON-LD, has much thinner public data. The safe read: publish clean, semantic HTML with structured data underneath so the crawler can tell a heading from a caption from an answer, and shape the content itself as answer-first chunks. Structure at both levels, since only one of them is well-measured.

Notice the mirror. To feed a model, you strip a page down to clean text. To get cited by one, you publish structure the crawler can read. Same goal from both ends: make the boundaries legible.

This article is built that way on purpose. Plain question headers. Short answers up top. A table you can lift. That is the thesis in practice.

You have the physics, the formats, and the publishing side. One move ties them together.

What’s next for you

Open your CLAUDE.md right now and move your single most important rule to the top.

That single move uses everything above: position (the top, where attention lives), a clean boundary (one Markdown line), and the rule that outlasts every format debate.

Here is that rule, the one under all the others. Models do not read, they parse. So write for the parser: give it boundaries it can find, put what matters at the edges, and say what to do instead of what to avoid. That last part is its own small fix, and it is measured: a 2026 study (arXiv 2601.08070) found “don’t do X” instructions failed far more as the pressure rose, and when they failed, the model was attending to the forbidden word more than to the “don’t.” So “use sentence case” lands better than “do not use title case,” because “title case” is a phrase you just handed it.

The jump from 27 to 98 at the start was not a smarter model. It was the same model, finally pointed at the right place. Your prompts, your CLAUDE.md, and your posts each have a right place. Now you know where it is.

If this article made AI feel a little more predictable, pass it on to someone who’s still fighting with prompts instead of building with AI.

Share

And if someone shared this with you, subscribe free so you don’t miss the next guide.

Subscribe now

What is the one rule your AI keeps ignoring? Move it to the top, and tell me in the comments if it finally sticks.

— Jenny

Claude Hub · Vibe Coding · AI Agents · Shipped Products · Substack Growth

Canva is one of the most-used design tools in the world. Hundreds of millions of monthly active users, creating everything from social posts to presentations to infographics.

Even on the free plan, you can make professional-looking designs.

But I could never master Canva the way I wanted. Getting an idea out of my head and into a finished graphic meant arranging the layout, adjusting the spacing, replacing elements until it felt right.

For over a year, that was where I got stuck.

Too many panels, too many buttons, too many decisions. I could picture what I wanted. I just couldn’t get there fast.

Now that’s changed.

Instead of designing inside Canva, Claude builds the design and imports it straight into Canva as a fully editable file.

Give Claude one article, and it generates:

• An infographic

• A 9:16 story

• An Instagram square

• A YouTube thumbnail

• A 7-slide carousel

Every one arrives as a real Canva design you can edit and export. All on the free plan.

That’s what caught my attention. Canva’s own AI tools cap out at ten generations, lifetime. The import has no cap at all. Generate as many as you want, no credits burned.

So I tested how far a free Canva account actually goes.

What’s inside:

• What the Canva MCP gives you

• Creating infographics, carousels, and charts from one article: all on a free plan

• The skill that makes the Canva MCP effortless: the kit and the exact prompts

• Run it, step by step: to your first finished kit in about 20 minutes

• Make it yours: your brand, every design coming out on-brand

• Forty tools, five that matter on free: the tool calls the whole workflow rides on

• Where the free plan stops: the Pro walls, and the free path around them

• By the end: a finished, exported, on-brand visual kit from Claude on a free Canva plan.

• 🎁 The Free-Plan Visual Kit: grab it at the end.

  • The skill, the on-brand templates, the prompts that run it in your own Claude, plus the tool reference, the by-hand recipe, and my test log of what a free plan does and doesn't do.

What the Canva MCP Gives You

An MCP is a connector that lets Claude operate another tool directly.

The Canva one lets Claude build designs inside your Canva account and hand them back as real files. PNG, PDF, a full slide deck.

Not a flat AI image with the text baked into the pixels, where fixing one typo means regenerating the whole thing and hoping it lands. A Canva file you own, reopen, and change one element at a time.

Setting it up takes two steps, both free:

1. Register on Canva.com. I just log in with Google.

   

2. Connect Canva to your AI. In Claude, add it under Connectors. It works the same from ChatGPT and other assistants that support connectors.

Creating Infographics, Carousels, and Charts From One Article

First, to get familiar with it, I started with the simplest input I could: one plain page. No design, just the content from a single article. I asked Claude to bring it into Canva.

It came back as a real, editable Canva design.

That verified the workflow. Time to explore what it can actually make.

Every format I’d post

Formats are the finished shape, sized for where it gets posted.

I tried the formats I was actually interested in with one article:

• Instagram square

  

• Vertical story

  

• Wide YouTube thumbnail

  

• Tall infographic

  

Same content, reshaped for each slot.

Multi-slide carousels

Seven slides from the same article, sequenced, each its own page.

I even used Canva MCP to collage the set into one grid to show the whole sequence at once.

Custom Image Backgrounds

I dropped in a workspace photo and asked for a muted overlay so the text stayed readable. Both came through the import clean.

And I tried more background images, with my own article covers.

Every file above came out of one article. None of it touched Canva’s UI button.

Different Layouts

How the content is arranged inside any format? I’ve always had a few I’d love to include in my blocks.

I asked for the layouts I reach for when I’m explaining something.

Start with A stat hero.

Then the rest, in one pass:

• Bar chart

• Donut

• Comparison table

• Checklist

• Flowchart

• Cycle

• Pyramid

• Venn

• Code card

Every one came back clean and on brand. Not a chart widget I had to wrestle into shape. A finished layout I could export or keep editing.

Branded colors and styles

The above are all using my brand color in purple, so I tested different color and styles on the same content:

Different surfaces

Then I tried the thing I’d half given up on:

• Whiteboard surfaces.

• Chalkboard.

• Kraft paper….

I used to make these with AI image tools, and they landed maybe half the time. The text warped, the lines smeared, the same prompt gave a different mess every run.

Canva just made them.

On demand, legible, the same every time.

Elements

Along the way I collected the element styles I kept reaching for, now in one place Claude can pull from.

Many of these used to mean half a day in the editor, or paying someone to do it.

This run took one afternoon, all on the free path, and the files can be reused as many times as I want.

The one thing it didn’t solve: making every new design match the last. That, and the rest of the how, is past here.

• Claim the skill: the kit I built, plus the exact prompts that drive it.

• Run it, step by step: the full walkthrough to your first finished kit, prompt to exported files, in about 20 minutes.

• Make it yours: set your colors, fonts, and logo once, so every design after comes out on-brand, design #10 still matching design #1.

• Where the free plan stops: which Canva Pro walls are real, and the free path that routes around the ones that aren’t.

It’s all in the Free-Plan Visual Kit. Grab it below.

Read more

Multi-step agents scanning covers via API drift: each handoff loses context and prompts slip from your brand. FastMCP’s Image type keeps everything in one Claude session.

Two modes via one skill: reverse-engineer any cover style (one article or a full brand audit), generate a prompt per article.

One MCP URL that you just connect and let the skill handle the rest.

I’ve spent the past year building systems to get consistent Substack covers.

Not consistent-ish. Not “close enough.” The kind where someone scrolls your archive and sees a coherent visual identity instead of a collection of experiments.

I wrote about this in How I Create Consistent Hero Images.

The system works. Attach a reference image, document the prompt, maintain a brand template file. But since publishing that piece I started getting the same follow-up question:

What happens when the model drifts two weeks later?
When you paste in the same prompt and get something that looks slightly, subtly, wrong?

The honest answer: re-attach the image. Re-seed the context. Start over.

To make it less painful, you could write skills, connect to MCPs, and build an autonomous agent around it.

Alejandro tried the ambitious version. A multi-step agent: call Claude’s vision API on each cover, extract brand learnings per image, aggregate them, then generate a prompt to feed into DALL-E or GPT-image-2.

It worked. But each handoff between steps dropped context. The generated prompts drifted from the actual brand. The agent took more effort to maintain than just eyeballing the covers manually.

So he rebuilt it at the protocol level.

What I appreciate about how Alejandro works: he treats the tool layer as real infrastructure.

We both agree on this: the setup work should happen once at the system level, not every session at the prompt level. That’s what a skill does. That’s what this piece shows.

If you want to go deeper into Alejandro’s thinking before reading:

• Why Skills and MCP Work Better Together

• Hands-On: Building a Substack Agent with Skills and MCP

• AI Observability for Data Engineers

In this piece, Alejandro walks through how FastMCP’s Image type solves the context-loss problem, how the visual-brand skill runs in two modes (reverse-engineer any publication’s style, or generate a prompt for your next article), and how to connect and use it right now from Claude Desktop, Claude Code, or Cursor.

Here’s Alejandro!

The Gap in Every Image Workflow

When I read Jenny’s article about consistent hero images, I recognized the system and the problem it’s trying to solve immediately.

Thing is, consistency becomes a manual operational process you keep repeating, praying that image generation models follow without drifting.

How do you extract your visual brand DNA and hand it to someone else? You explain it manually or use custom prompts-skills, but the image reference still needs to be attached one way or another to build the context.

That’s still manual work, moved from the creation stage to the audit stage.

I ran into this gap while building a multi-step agent to solve it for my own publication.

The setup: call Claude’s vision API on each cover, extract brand learnings per image, aggregate them, then generate a prompt to feed into DALL-E or GPT-image-2.

It worked, but each handoff between steps dropped context.

The generated prompts drifted from the actual brand. Maintaining the agent took more effort than just eyeballing the covers manually.*

Two additions to the Substack Author MCP collapsed that entire pipeline to end up with a prompt that will help you with this brand consistency pain.

Part 1: Teaching the MCP to See

Most MCP tools return text. Strings, JSON, structured data: all things the AI reads like a document.

FastMCP also has an Image type. When a tool returns it, the AI doesn’t read. It sees.

from fastmcp.utilities.types import Image

def get_article_cover_image(article_url: str) -> Image:
    ...
    return Image(data=img_resp.content, format=fmt)

Two differences from returning a URL as text:

1. Image(data=..., format=...) wraps the raw bytes with format metadata

2. The MCP client (Claude) receives it as visual input, not a string

In the multi-step agent approach, Claude received a text description of the image passed from one API call to the next. Here it processes the visual data directly in a single session without context loss between steps.

When I tested this on my most recent article, Claude returned without any prompting:

And the breakdown was quite spot on.

Subject / Focal point A person (you?) center-frame, smiling, hands raised like conducting chaos. Relaxed, confident posture. No stress despite the chaos around him. The 💩 with sunglasses on the shirt adds personality and humor.

Background / Environment Dark background (near black) with neon glowing elements. A “digital universe” aesthetic — particle streams, graph networks, floating UI panels. Orange/red on the left, pink/magenta on the right, blue/green in lower corners. High contrast, high density.

Floating UI elements Multiple neon-framed panels surrounding the figure...

Let’s see how this gets combined with skills.

Part 2: Skills and What They Do

Seeing covers is one thing. Without a workflow on top, you prompt from scratch every session, explain your intent, repeat yourself each time.

That’s where Skills come in, and this is the part most people haven’t seen yet.

The Substack Author MCP uses FastMCP’s SkillsDirectoryProvider. Two lines on the server:

from fastmcp.server.providers.skills import SkillsDirectoryProvider

if skills_path.exists():
    mcp.add_provider(SkillsDirectoryProvider(roots=skills_path))

This scans a .claude/skills/ directory, finds every SKILL.md file, and exposes each one as an MCP resource: a doc the AI can read on demand when it recognizes the right context.

The difference between a tool and a skill:

The MCP currently ships with 6 skills. One of them, visual-brand, was built specifically for what Jenny’s article was about. (I wrote a full breakdown of how Skills and MCP work together if you want to go deeper.)

The visual-brand Skill: Two Modes

When you connect to the MCP and ask about covers, the AI loads visual-brand automatically. Two modes depending on what you’re trying to do.

Mode 1: Generate a New Cover Prompt

“I’m writing a new article. Give me a cover prompt consistent with my brand.”

Give it your publication URL and article title. The skill fetches your recent covers, establishes your visual DNA, then composes a prompt that fits the article’s specific topic and mood while staying inside your visual system.

Output comes out with just a ready-to-paste prompt block.

Mode 2: Reverse a Style

“What’s this cover doing that makes it work?”

Give it a URL, a single article or a full publication, and tell it how many covers to scan. The skill calls get_cover_image on each, analyzes palette, layout, subject, mood, and style, then outputs a ready-to-paste prompt.

Single article gives you a bullet breakdown and a style prompt. Multiple covers flag outliers and output a brand template with [variable] placeholders for what changes per article.

This came out from my latest article on AI Observability for Data Engineers.

Scanning 5 covers outputs something like this:

Photorealistic digital illustration, newsletter cover, portrait 2:3, high resolution.

Subject: curly-haired man with glasses and a 💩-with-sunglasses emoji t-shirt, center-frame, [expression and gesture: smiling + open hands for approachable

topics / serious + pointing for critical topics / dynamic riding pose for architectural concepts].

Background: near-black or deep navy, dense particle field with neon light streams — orange/amber radiating from center-left, pink/magenta on the right, [accent: green for validation/success / blue for data/structure / purple for AI/LLM themes].

Floating UI elements: 2–4 neon-framed panels surrounding the subject, each labeled with [article-specific technical concept]. Border colors: orange for

process/pipeline, pink/magenta for AI or warnings, green for success states, blue for data schemas.

Style: hyperrealistic rendering, cinematic lighting, neon glow with soft bloom, dark cyberpunk aesthetic with dense technical detail.

Mood: [confident and chaotic for overview articles / focused and analytical for deep-dives / kinetic and motion-forward for architecture articles].

That’s your visual brand DNA in text form. Paste it into ChatGPT, Midjourney, Flux — any generator you’re already using. The [variables] swap per article. The DNA stays fixed.

How I Use It & You Can Use It Too

This won’t fully solve the need to attach the image on ChatGPT, but it will solve a lot of the consistent breakdown.

My current workflow relies on:

• A brand template file saved to my Obsidian vault

• The MCP skill to create a prompt just like the one you saw

• Then I attach one image or keep reusing a ChatGPT conversation

Whenever Claude releases image models or ChatGPT allows proper MCP usage, this might become even more straightforward since the attachment won’t be needed at all.

No installation. Add this to Claude Desktop, Claude Code, Cursor, or any MCP-compatible client:

https://substack-author.fastmcp.app/mcp

In Claude Code, skills are exposed as MCP resources — the server instructions tell it which workflow to activate based on what you ask, no manual @ mention needed. Claude Desktop and Cursor work the same way.

Then try:

“Look at the last 5 covers from [your publication URL] and build me a brand template prompt.”

Or point it at any publication you admire:

“Reverse-engineer the cover style from [any public Substack URL].”

The tools, image processing, and visual-brand skill are all already there when you connect — just tell it what you want.

What's the one thing in your current image workflow that you keep redoing every session?

— Jenny

Claude Hub · Vibe Coding · AI Agents · Shipped Products · Substack Growth

Tell me if this sounds familiar.

You hand Claude something real. A long task, the kind you wrote a careful prompt for. Ten files to refactor. A full section to draft. A dataset to clean end to end.

It runs. It looks finished.

Then you actually read it.

Half the files got a one-line change and a note saying it is handled. The draft skipped the part that was actually hard. The cleanup stopped three steps in and declared the job done.

That was me, more times than I want to admit.

Claude is good at looking done. The hard part is exactly what it learns to route around, because the hard part is where it might fail, and a confident summary reads like success. You only catch it when you read every line.

I fought this for a long time. Hard rules in the prompt. Code that checked the output. Skills, gates, hooks, workflows. Each one fixed it for some jobs and left others open.

Then I leaned on the loop. Gradually, it became the first thing I reach for. It kept getting better, and it kept closing the gap the others left. It is feels like one of the most underrated features in Claude Code.

Turns out I am not alone. Boris Cherny, who built much of Claude Code, put it plainly: his job is to write loops.

A loop is just Claude working until something is true. The whole game is which command, and how you tell it what “done” really means. Get that right and Claude stops faking the finish.

This guide is how.

What’s inside:

• What a Claude Loop Actually Does

• The Claude Loop in Its Simplest Form

• The Writing Loop That Won’t Accept a Fake Finish

• The Coding Loop That Closes Claude’s Shortcuts

• The Research Loop That Won’t Stop at Plausible

• How to Write a Claude Loop That Actually Finishes

• When Your Loop Might Run Forever

By the end: you’ll have a loop running for your own work that keeps going until the job is genuinely done.

🎁 The Loop Starter Kit: 5 ready conditions and a safety-net config, grab towards the end.

Subscribe now

What a Claude Loop Actually Does

Run a loop and Claude works until the job is confirmed done.

Claude Code calls this keeping a session running between prompts.

One moving part: Claude takes a turn, a check fires, it either goes again or stops. That check is the whole engine. Everything else is just how you run it with normal prompt.

The tools: The behavior is not new. People have been prompting Claude to keep going since day one. What changed is that Claude Code built tools around it.

/loop landed in March 2026, built for polling: check the deploy every five minutes, babysit a PR. It runs on a timer. Drop the interval and it becomes self-paced: Claude works, checks its own stop condition, goes again or stops.

Then in May 2026, /goal followed. Same loop behavior. The difference is who enforces the stop.

/loop (self-paced): Claude checks its own work inline each turn.
/goal: a separate small model reads the transcript independently and decides. Both are loops. The distinction is just the judge.

Beyond code: Almost every tutorial still frames this as a developer tool. Run the tests until they pass. Fix the failing PR. Code, code, code. That framing hides what it is actually good at. A loop does not care whether the job is code. It cares whether the job has a clear “done.”

I used it on code for weeks before that clicked. Then I pointed the same shape at a research brief. At a content draft. At a skill I was fixing. The only thing that changed was the finish line.

Four Ways to Run the Check

• Prompt it yourself. Tell Claude every turn to check its work and keep going. It works, and you babysit it.

• /loop (self-paced). Drop the interval and Claude enforces the stop inline. The condition lives in the prompt itself.

• /goal. You write the finish line in plain words. After every turn, a small fast model reads the transcript and decides: condition met, or keep going with a reason.

• A Stop hook. Your own code that fires when Claude tries to stop and checks the work directly, for jobs that can’t be proven from the transcript alone.

The first option runs in any AI interface. The other three are in Claude Code.

Loop runs best when paired with an independent agent:

• /goal uses a separate Haiku model that reads the transcript independently, so Claude in the main session is not judging its own work.

• /loop can match this by spinning up a subagent as the verifier, and that subagent has tool access.

Either way, Claude cannot route around the hard part. The condition has to be proven.

Share

Below is four loops paired with visuals and videos. Each one ends when the work is actually done, and not when Claude thinks it is.

• The simplest loop: run it once, watch it work. You’ll take the concept and hand off any repeating task.

• The writing loop: walk away from a draft mid-progress. Come back to a finished write-up following your exact criteria.

• The coding loop: walk away from broken code. Come back to a working build.

• The research loop: hand off a topic. Come back to a complete report, action, experiment, scout, done for you.

• The framework: three parts. Build a loop for any job you have.

• The safety net: make sure your loop stops when the work is done. Even when done lives outside the conversation.

The Loop Starter Kit, 5 ready conditions and a safety-net config in one file: grab it at the end.

Upgrade to Premium

The Claude Loop in Its Simplest Form

Run these four prompts. You’ll be able to run any repeating task hands-off, with a real stopping condition.

Step 1: Output to chat.

/loop print Tick in the chat every 5 minutes, end after 5 turns

Claude prints “Tick.” Five times, then stops. Watch what’s happening: Claude re-enters the same task on a timer, one turn at a time. That’s the loop.

Step 2: Output to a file.

/loop write the current time to ~/test-loop.md every 5 minutes, end after 5 turns

Same loop, different output. Now Claude writes to a file. The work goes somewhere real; the chat stays quiet.

Share

Step 3: Read from a file, stop when it’s done.

Create test.md:

- [ ] request 1
- [ ] request 2
- [ ] request 3

Then:

/loop Read test.md, find the next unchecked line, add a checkmark, save the file. Stop when all lines have checkmarks.

Now the loop has an input and a natural end. It doesn’t run for N turns because you said so. It runs until the file is finished. The file defines done.

Step 4: Intake, execute, update.

Create test2.md:

- [ ] output Tick 1
- [ ] output Tick 2
- [ ] output Tick 3

Then:

/loop Read test2.md, find the next incomplete line, follow its instruction, mark that line complete in the file. Stop when all lines are marked complete. 

The loop reads its own instructions, executes each one, marks it done, and stops when the file runs out. The file is the agenda. The loop works through it.

Upgrade to Premium

You can now run any repeating task and trust it to stop on its own. The writing loop, next, applies that shape to a draft.

Read more

In our Practical AI Builder inner circle, a member told me they love to use Firecrawl as the research MCP.

Then they asked: is there any reason to use a different MCP instead?

Yes. There is.

You’ve probably done the same thing. You find one scraping tool that works, and you point it at everything.

Then it hits a wall.

Amazon throws a login wall. A run reports “SUCCEEDED,” returns zero rows, and still bills you.

That was me.

There isn’t one best scraper. There are many. These four are my favorites, and each owns a different job.

Firecrawl deep-reads a URL you already have. It can’t find where the signal is. It can’t punch a login wall.

Search is one job. Meaning-match is another. Cracking a locked platform is a third.

I tested all four across 15 platforms: Reddit, Amazon, YouTube, Hacker News, Product Hunt...

Real runs. Real costs. Real walls.

One MCP billed me ten cents and returned nothing. Another pulled 25 clean posts for seven.

Match the tool to the job, and the walls mostly disappear.

This guide is that map.

What’s inside:

• Why one tool hits wall after wall: login walls, blocks, billable dead-ends

• Tavily, Exa, Apify, Firecrawl: the four, named, one per wall

• Mapping the territory: the best one for fast discovery

• Find the complaint you can’t name: meaning-match, not exact words

• Cracking the locked platforms: data where search can’t reach

• Reading any URL: the deep-reader for a page you have

• The Routing Card: which MCP for which job

• By the end: you can reach for the right research MCP for any job, on free tiers, without forcing one tool everywhere

🎁 The Research MCP Routing Card: which MCP for which job, plus the free-tier setup for all four. Grab it at the end.

Subscribe now

Why one tool hits wall after wall

Point one MCP at every target and you don’t hit one wall. You hit a different wall each time.

I learned the four the hard way, testing across 15 platforms.

The walls one tool keeps slamming into:

• The login wall. Amazon returns a sign-in page, not reviews. Firecrawl scrapes it and gets the login screen.

• The engine-level block. X refuses every scraper before the request even runs. The response is “all scraping engines failed,” not a page.

• The billable zero-row run. On Reddit, an Apify actor on a datacenter proxy returns nothing, reports “SUCCEEDED,” and still charges the start fee.

• The snippets-only wall. Search LinkedIn and you get the post title and one line. The full post and its comments stay behind the login.

None of these is your fault.

Each is a different defense. No single tool is built to clear all four.

That is why “just use the one I like” breaks. You are not using a bad tool. You are using one tool for a wall it was never built to climb.

So I stopped hunting for the best scraper and started matching the tool to the wall.

Tavily, Exa, Apify, Firecrawl: One for Each Job

Pulling research into Claude looks like one task. It’s four, and the walls from a minute ago were all the same mistake: one tool sent to do all of them.

Four jobs, and a different tool owns each:

• Tavily finds where the signal is. Point it at the open web and it returns the threads, issues, and posts worth reading.

• Exa matches by meaning. Describe the complaint you can’t keyword and it surfaces the post that never used your words.

• Apify extracts from locked platforms. A marketplace of ready-made scrapers for the sources that demand a login: Reddit, YouTube, Amazon.

• Firecrawl reads a page you already have. Hand it a URL and it comes back as clean markdown.

Find, match, extract, read. The searcher can’t read; the reader can’t search. That’s why the one tool you like keeps hitting a wall: you’re handing it three jobs it was never built for.

Knowing what each does is the easy part. The how, and which to reach for when, is the rest of this guide.

Read more

Ten minutes. Claude created a landing page, hooked up payments, and made it a live URL. I didn’t open a single dashboard.

That happened at the end of this live session, and it is the most appreciated moment I have of what a fully connected Claude can do.

In previous sessions, we’ve used Claude as a thinking partner, running dialogues that surface your own edge.

Useful. But every session ended the same way.

Claude had the plan. I was the one clicking buttons, switching tabs, copy-pasting outputs into other tools. The insights stayed in the chat. The execution stayed with me.

This session completely changed that.

What’s inside:

• How AI use has advanced

• Fix this old habit to be ready for agentic AI

• MCP work has 3 types

• 3 workflow levels, live:

  • VOC research

  • Visual design

  • Live product page build → deploy in 10 min

• The change point when you connect the dots

• 9 workflow prompts you can run today

• Session timeline with timestamps

• Which workflow to run this week

🎁 Session resources: Installation and workflow materials in the BTL portal — slides, full recording with captions, and live outputs from all three demos.

How AI Use Has Advanced

Most people start using AI as a chatbox and gradually go through these three stages.

Stage 1 is the chatbox.
You ask a question, get an answer, go back and forth. This is where almost everyone started. It is also, for many people, where they still are.

Stage 2 is the advisor.
Claude becomes a thinking partner. You stress-test ideas, get second opinions on decisions. It is genuinely useful. But it stops short.

Stage 3 is the hand-off.
Claude does not advise, it executes. You stay in the conversation. Claude does the research. Claude edits visuals. Claude handles payments. You keep thinking. The mechanical work leaves the room.

MCPs (Model Context Protocol) are what make Stage 3 possible. They are connectors: a standard protocol that lets Claude communicate directly with the tools you already use. Gmail. Notion. Canva. Stripe. Vercel. If a tool exists, there is usually an MCP for it.

The technical setup is a few minutes. That is not the hard part.

Fix This Old Habit to Be Ready for Agentic AI

The reason most people do not use MCPs is that leaving the chatbox feels normal.

You have been doing it for years. A notification comes up, you click over.

You need to update a spreadsheet, you open a new tab.

You finish the Claude conversation, then go execute the thing it told you to do.

The break feels like work.

MCPs require you to notice that break and decide not to make it.

I use one rule to catch that habit. Whenever I am about to leave the chatbox to go do something, I stop and ask:

Does this have to be me?

If it is a one-time task, fine. But if I have done it twice, I look for an MCP. If one exists, I install it. If not, I build one.

The overhead of installing a connector is often less than ten minutes. The overhead of leaving the chatbox every time that task comes up is permanent.

If you are evaluating which MCPs are worth installing, I use these Claude MCPs daily and listed the installation guide and personal verdicts for each.

In the session, Eike mentioned a preference for CLI-first over MCP when a command-line interface is available: it connects more cleanly, machine-to-machine.

I agree for technical workflows. For most builders getting started, MCP is the lower-friction path in.

MCP Work Has 3 Types

Once you decide to stay in the chat, you need to know what to ask Claude to do.

MCPs can help in three ways. Most introductions only cover the first.

Retrieve is pure data gathering. Search LinkedIn. Pull a Reddit thread. Download analytics. This is mechanical work with no real risk — you are collecting information. Safe to start here.

Change is modification. Draft an email. Generate a Canva design. Create a Notion page. This is where people get cautious, because changes can be wrong. A sent email cannot be unsent. That caution is reasonable. Build in a review step before executing.

Execute is the full workflow. Claude builds the thing and ships it. A working product page with a live payment link. A deployed website. A complete process that runs while you are in another conversation. This is Stage 3 in practice.

The session had one live walkthrough for each level.

Read more

I usually build my own research tools.

If I need to scrape a site, collect a dataset, or track something over time, I just build the thing and move on.

But a member of my program pushed back on that instinct.

Building a custom tool every time is too much overhead when you just need an answer today.

They were right.

So instead of building, I was also exploring the research-tool space.

Five rose to the top. Each has an MCP server, a small connector that plugs a tool straight into Claude so I can call it in plain language. Each does one job well enough that together they cover almost any research task:

Tavily, Exa, Firecrawl, Perplexity, Apify, etc.

If you’re tight on time and want results today instead of a weekend build, that stack is the shortcut.

Today, I want to draw your attention on Apify.

Because it isn’t just a tool. It’s a place where tools get bought, and the buyer doesn’t have to be human.

I tried the tools (they call them actors) there, the results were genuinely good. That trial inspired me to build one too. Put it up where those other tools live.

Then I pointed my own AI at this tool and watched the AI session pay me two-tenths of a cent. No checkout, nobody approving anything.

I was on both sides of that transaction, which allowed me to watch every part of it.

That tiny payment is the clearest look I’ve gotten at how product gets bought when the customer is an agent.

What’s inside:

• What this Apify actually is

• How an AI agent paid me per result

• What pay-per-result pricing means for you

• How to find tools inside Apify without overpaying

• The playbook for building your own tools that make money

🎁 Download the AI agent market research and build template at the end

Subscribe now

What Is Apify? (And How Does It Work)

Apify is a marketplace of tools that do that.

Each tool is called an actor: feed it an input, it runs in the cloud and hands back structured data, neat rows with labeled fields.

You never touch a server, a browser, or a proxy; you pay for what comes back.

It started in 2014 as a web-scraping company in Prague and quietly grew into something bigger. By late 2024 the store held more than 35,000 actors, used by 52,000 customers. The company had doubled its revenue to $13.3 million in a year on almost no outside funding.

What that means for you: almost anything you’d think to scrape, someone’s already built.

Instagram, TikTok, YouTube, X, LinkedIn, Google Maps, Amazon, most directory and review sites.

Debating a weekend building your own? Apify probably has one, or ten.

It’s that deep for a reason: every actor is built and maintained by a developer who earns each time it runs.

The most-used tool on the platform, a Google Maps scraper with 440,000 users, isn’t even Apify’s, it’s one developer’s. It keeps working because their income depends on it, the upkeep you’d skip on a tool you built yourself.

As the AI wave hit, and Apify now calls itself tools for AI builders.

The tell: it shipped an MCP server, the same connector I use to plug tools into Claude. So an agent can search the store, find an actor, and run it on its own, no human in the loop.

So look at what’s forming.
The buyer is turning into a machine, an agent that finds a tool and pays for a result on its own.
The seller is a person: one developer, one tool, one slice of knowledge kept alive because the pay depends on it.

Machines on the demand side, individuals on the supply side. The rest of this piece is what that means for you, on both sides.

How an AI Agent Paid Me Per Result

An agent found my tool, ran it, and paid me.

I built a small actor, listed it in the store, and set a price: two-tenths of a cent per result. Then watch what happens when an agent needs it. In Claude, I typed:

“does apify mcp have any tools to analyze the Substack newsletter platformer.substack.com. I want to see their engagement rate and publishing cadence.”

Claude didn’t answer from memory. It searched the Apify store, found my actor ranked #1, ran it, and pulled the results back. Two tool calls later it had real data:

Platformer by Casey Newton
Subscribers: 176,000 · Engagement rate: 9.1% · Posts/week: 2.4 · Cadence: irregular · Trend: up

Then I asked the obvious question: what did that cost?

The whole run came to about $0.0036, under four-tenths of a cent: a $0.00005 actor-start fee, $0.002 for the one result, and roughly $0.0015 in platform compute. My cut as the developer is about $0.0016 of it.

No checkout. No invoice. No human approving the purchase.

The price is the part quietly shifting under all of this.

Apify has moved 2,000 tools onto pay-per-event pricing. The developer charges per action, and the one most agents want is a returned result. That's pay-per-result, a price that only rings up when the tool hands back something real.

At the same time the old model is going away. Apify is retiring flat monthly “rental” pricing for tools entirely within six months, and 73% of surveyed customers preferred paying per event.

The reason they gave names the buyer directly:

An AI agent cannot effectively manage a dozen different $50/month subscriptions; it needs to ‘pay-as-it-goes.’

Make it personal: this isn’t only about agents.

Think about what you already pay every month: the SEO tool, the research suite, the analytics dashboard. A hundred dollars here, fifty there, for software you open a handful of times.

The flat fee is a bet that you will use enough to make it worth it. Most months, you lose that bet.

Pay-per-result quietly dissolves it.

Now that AI can run the exact job you need, you pay for the single answer instead of renting the whole suite. Often, the calls fit inside the $5 monthly credit a free Apify account gives you.

A human pays for access they might use. A machine pays for the outcome it needs, then leaves.

To be fair, this is not the finished model. Apify still runs a monthly plan with a credit balance, the same hybrid most AI platforms use. Pay-per-result is the per-call layer poking through, riding on top of a subscription still built for humans.

I am betting it is the start, not the end.

What Pay-Per-Result Pricing Means for Users and Builders

Two positions just opened, one on each side of this marketplace. As a buyer, your agent shops it for you. As a supplier, you stock a shelf an agent pays to reach.

That door is open to anyone right now. Below, the exact how for both.

Find the tool that actually works, skip the trial and error:

• the exact prompts to find, vet, price, and run a tool

• the four signals that tell a live tool from a dead one

• the shortlist of the best actor for ten common jobs

Build your own, in an afternoon:

• the real build with AI in one afternoon

• the failures and the exact fix for each

• follow the package with: market research brief, the build reference, and code template

Read more

Claude ships features faster than anyone can track.

Within 8 months, it’s pushed out major updates including Skills, MCP servers, plugins, connectors, cowork, routines, and model upgrades.

After a while you stop looking.

For new drops, I usually let it settle into how I already work, and trust it will find its place when it matters. Most features do, so I let them slide.

But this one caught me off guard.

I had asked Claude to research about MCP servers. A normal Tuesday. It spun up 101 agents and ran them for 13 minutes, 723 searches and page-reads, before it handed me anything. 75 of these agents were fact-checking, each trying to prove a finding wrong.

I was not expecting that. That is not my usual workflow. So I stopped the research and took the feature apart instead.

What it ran is called a dynamic workflow. Claude had reached for a built-in one, deep-research, on its own.

This article goes through what happened: what a dynamic workflow is, what those 100 agents actually did, what it means for your work, and how to take the same pattern into workflows of your own.

What’s inside:

• What dynamic workflows are in Claude Code

• What 100 agents do in one workflow run

• Why dynamic workflows change how you work with AI

• How a dynamic workflow is built

• How to build your own workflow without the feature

• When a dynamic workflow is worth the tokens

• One more thing I found in the binary

• By the end: a workflow pattern you can run on your own research, writing, or analysis, with or without the feature built-in

Subscribe now

What dynamic workflows are in Claude Code

A dynamic workflow turns one request into many agents working in parallel, with the results checked before they reach you.

You describe the task. Claude writes a small program that breaks the work into pieces, runs many copies of itself on those pieces at the same time, and merges what comes back.

In Anthropic’s own words: “a dynamic workflow is a JavaScript script that orchestrates subagents at scale.”

The feature shipped May 28, 2026, as a research preview. It runs in Claude Code v2.1.154 or later.

Two questions matter before anything else, because the answers decide whether this is even for you.

Where does it run?

Dynamic workflows live in Claude Code: the command line, the desktop app, and the VS Code extension. Plus the Claude API, Amazon Bedrock, Vertex AI, and Microsoft Foundry.

They are not in claude.ai web chat. They are not in the mobile app.

Is it only for coding?

No. The one workflow Anthropic ships ready to use is called deep-research, and it does not touch code.

The official examples include a research question that needs sources cross-checked and a plan worth drafting from several angles before you commit.

This is the thing that ambushed me was a research run.

So the feature lives inside a coding tool, but the work it does is general: research, writing, planning, analysis. Any task you want split many ways at once.

Share

What 100 agents do in one workflow run

In one run, the workflow went from my question to a cited report with the weak claims already thrown out.

What those 101 agents did, in order:

It split my question into 5 angles. One agent read “research free MCP servers” and turned it into five different searches, each pointed at a different part of the problem.

It searched all 5 at once. Five agents, five web searches, running at the same time instead of one after another.

It read the sources and pulled out claims. More agents fetched each page, judged whether the source was solid, and extracted specific checkable statements. Nineteen sources fetched in this run.

It tried to disprove its own findings. This is the part that made me stop. It pulled 85 claims from those sources, ranked them, and sent the top 25 to 3 separate agents each, told to refute them and assume false unless proven. A claim survived only if it could not be knocked down.

It merged the survivors into one report. 18 claims survived the vote. 7 were killed outright. Synthesis collapsed the 18 into 7 final findings, the duplicates merged into the survivors.

That last number is the point. The cost was not buying me seven facts. It was buying me the seven bad claims that never reached the page.

One was the stat everyone repeats about the MCP registry: 2,000 servers. I paginated the registry myself. It is past 3,000. The workflow caught the wrong number and cut it before I ever saw it.

I asked for research. I got research that had already argued with itself.

Share

Why dynamic workflows change how you work with AI

You already break big tasks into steps. You ask Claude to plan, you spin up subagents, you run things in order and stitch the results together.

It works. You are the one holding the plan.

A dynamic workflow moves that job to Claude.

It reads the task and decides what to split, what runs in parallel, what waits, and what needs checking, then runs the whole thing as the orchestrator.

The planning and sequencing and edge cases you would have had to think through, it handles itself.

On my runs it sequenced the work better than I would have.

That is what changes. Not that AI can run a hundred agents, you could arrange that yourself. What changes is who does the arranging and cleaning up.

The scale comes free on top.

Each agent gets its own clean memory and one small job, reads its slice, returns a short answer. The heavy reading stays inside that agent and never piles into your conversation, which is why a hundred can run without slowing your session.

What is left for you is the outcome. You describe what you want. Claude works out how.

• For research, that means more sources cross-checked than one chat could hold.

• For writing, drafting several sections at once and checking each against your voice.

• For analysis, running the same question from four angles and keeping only what holds up.

Not orchestrating the work yourself. Describing the outcome and letting Claude orchestrate it.

The feature is the easiest way to run that, but not the only way.

Underneath it is a pattern you can run anywhere: break the work into pieces, run them at once, check them before you trust them. It works in any AI tool you already have open.

Upgrade to Premium

So I built the pattern into a template. The next part has the full teardown of the run that shocked me, the real runs behind each piece, then the template itself.

• The full teardown of the dynamic workflow structure

• The custom workflows you could runs

• The workflow blueprint: a fill-in template plus 3 copy-paste recipes

• Run it without access: how to get the same result in plain Claude or ChatGPT, no feature required

• The other built-in workflows

Read more

If you’ve ever purchased an online course, tell me if this sounds familiar.

You bought the course. Started it. You’re two hours in and you already know half of what you’re watching. The part you actually need is somewhere in the next six hours. Finding it means watching through everything you already know.

So you stop. Tell yourself you’ll come back. The recording sits in your user portal.

That was me.

AI summaries didn’t fix it. I asked Claude to summarize transcripts and got 600-word overviews. Covered everything. Answered nothing specific.

The problem is retrieval, not content.

I was stuck on my article title performance. CTR was low. I had been testing for three weeks. There was a writing course in my library that covered headline testing. Eight hours long. I was not going to rewatch eight hours.

I asked the notebook instead.

“I’m working on article title performance. CTR is 0.6%. What does the Writing notebook say specifically about how long to run a headline test before drawing conclusions? Give me the one-sentence rule, not the full explanation.”

Answer in 42 seconds. Exact passage. Specific recommendation. Timestamp.

That moment is what this system is built for. Stuck on one problem. One specific question. One specific answer from content you already paid for, in the format that’s actually useful right now.

I have hundreds of hours of recordings. Courses I bought. Cohort calls I hosted. YouTube channels I learn from. I built a workflow with Claude and NotebookLM to make all of it queryable. Without rewatching any of it.

The MCP connection lets Claude query your notebooks from inside any session.

The prompt structure is what determines whether you get the answer in the format you actually need.

What’s inside:

• Why recording libraries stay passive

• How the pipeline works

• How to add and organize sources in NotebookLM

• How to connect NotebookLM to Claude via MCP

• How to index YouTube videos

• How to index paid course recordings

• How to index your own meeting recordings

• How to query recordings mid-work

• How to repurpose your recordings into content
  

Subscribe now

Why recording libraries stay passive

The problem has a name: the mixed-knowledge problem.

Every course or recording you buy overlaps with what you already know. That overlap is exactly why you bought it. The content matched your existing mental model. The topic was relevant. That’s the purchase signal.

But the same overlap is what makes extracting value so slow. You already know a significant portion of the content. You cannot filter in real time. There is no mechanism to skip directly to what you don’t know. So the options are rewatch everything, or skip to a section you can’t locate without watching the whole thing first.

So the recording sits there. That tells what research find out: the median online course completion rate is 12.6%.

AI summaries made this worse in a specific way. A summary covers the full content. It tells you what’s in there. It does not tell you whether the thing you need right now is in there. You read the summary and still don’t know if the recording answers the specific problem you have today.

The gap is a query layer. You need a way to ask a specific question and get the specific answer from the specific recording, without watching any of it.

That’s what NotebookLM does. It’s a research tool that indexes your uploaded sources and answers only from what you’ve uploaded. Answers are grounded only in your uploaded sources. Every response cites the exact passage. If the answer isn’t in your sources, it says so directly.

How the recording-to-knowledge pipeline works

Three parts. Each does one job.

1. NotebookLM indexes your recording and makes it queryable.

2. The Claude MCP connection lets you query your indexed content from any Claude conversation without opening NotebookLM. MCP (Model Context Protocol) is the standard that connects external tools to Claude. NotebookLM is one of them.

You can use Claude Cowork or Claude Code. Both work similarly.

I prefer using Claude Code because I’m usually already building or writing in Claude Code, you hit a question, you ask the notebook, Claude returns the answer and keeps going. No tab switching.

3. Your query prompt determines whether you get a pinpointed answer in the format you need, or another generic summary. The framing matters more than most people expect.

The pipeline handles four source types:

• YouTube videos: paste the URL. NotebookLM extracts the transcript automatically.

• Paid course platforms (Teachable, Hotmart): extract audio via browser DevTools, then upload the .mp3.

• Your own meeting recordings: download from Google Meet or Zoom, extract audio, upload.

• Standalone audio or video files: upload directly. NotebookLM transcribes internally.

What you need: a NotebookLM account (free tier is fine to start) and either Claude Code or Claude Desktop with MCP support.

What a queryable process look like:

I was stuck mid-work. I know I bought a course that covers this. So I asked:

“I’m stuck on my upgrade CTA copy. What does the Content Monetization notebook say specifically about what makes a reader convert to paid? Give me the single most important principle.”

Claude queries my indexed notebook. In 40 seconds it returns the specific section from the recording, the exact recommendation, and the timestamp where it was said.

How to add and organize sources in NotebookLM

Before the MCP and the query prompts, there’s a step most people skip: setting up the notebook so it returns useful answers rather than noise.

What NotebookLM accepts:

• YouTube URLs (requires captions on the video)

• Audio and video files (.mp4, .mp3, .m4a, .wav)

• PDFs

• Google Docs

• Plain text files

• Websites

Notebook organization: one topic cluster, not one source per notebook.

A notebook that holds all your writing courses, editorial frameworks, and headline testing videos is more useful than 30 separate notebooks. The query spans everything in the notebook, so clustering by topic gives you broader coverage per question.

Three types of notebooks that cover most use cases:

• Content and writing: writing courses, editorial frameworks, content strategy recordings

• Business and growth: conversion, pricing, audience-building, sales courses

• Technical skills: coding, tools, workflow recordings

The free tier allows 50 sources per notebook. For most users, that covers a full domain.

Naming your sources matters.

When you add a source, NotebookLM uses the filename or title in its citations. “Lecture 7.mp3” tells you nothing. “content-teardown-pt4.mp3” tells you exactly what it is.

What makes a source queryable:

• Clean audio is better than poor audio. If you can hear it clearly, NotebookLM can transcribe it accurately.

• Long recordings (90+ minutes) index fine. NotebookLM handles them without splitting.

• YouTube videos with no captions won’t process from a URL. Use the direct upload path instead.

You understand how NotebookLM works and how to organize it. That’s the foundation. The sections below make the pipeline useful mid-work:

Upgrade to Premium

• The MCP setup: connects NotebookLM to Claude so you can query notebooks from any Claude session without switching tabs.

• How to get recordings into NotebookLM: no extra tools to pay, no screen recording needed.

  • YouTube videos

  • Paid course platforms (Teachable, Circle, Substack)

  • Meeting recordings

• How to query recordings mid-work: the exact prompt structure

• How to repurpose your own recordings into content: the exact queries I use to pull scenes from cohort recordings into articles, with a worked example showing query sent, output returned, and what made it into the piece.

Read more

I wrote an article earlier this year about building apps with Claude Code. 15 projects, tiered by difficulty, with the exact first prompt for each.

The most common reply wasn’t “great, I’ll try Project 4.”

It was some version of:
- “I don’t actually want to build an app. I just want to fix the stuff that’s eating my time.”
- “I have Claude Code now, but I don’t really know how to or want to do code”

Tell me if this sounds familiar.

You have Claude Code open. You’ve run through the basics. Maybe you even shipped something small. And now you’re looking at a list of Claude Code project ideas. Nothing on that list matches the friction you actually have right now.

The contract you need to understand before tomorrow’s meeting.
The survey responses nobody has had time to read.
The family plan you need to update but never get around.

None of those are apps.

All of them are builds.

That’s what I felt too since building with Claude Code in 2024. (At that time, Claude Code was Anthropic’s terminal-based coding tool: plain-English instructions, runs on your machine, no prior coding required.)

My first project was a local photo search: 30 minutes, 12,000 images now searchable by description, nothing uploaded anywhere. I shipped it, then retired it. I built it because I was spending 20 minutes a week digging through folders. That problem is gone.

The Gmail digest I built later: 918 emails processed in 40 seconds, before I open my inbox. Did not make to an app. But stayed as a workflow, which I later turned it into a cluster of workflows with multi-account gmail MCP.

The thing I learned: any friction point is a build.

That build to friction could be:

• A Task you do once.

• A Workflow that runs every time.

• An App you can hand to someone.

• An Agent that runs without you.

You don’t have to go all the way. Instead, you pick the level that actually solves the problem.

The previous article was about building apps. This article is about everything between “I opened Claude Code” and “I shipped a product.”

We’ll map out 19 friction points from real daily work, personal life, and family time. Each one shown across these four possible levels.

What’s inside:

• What Task, Workflow, App, and Agent mean

• The full loop: one starting point, all four levels

• Work problems with Claude Code

• Personal problems with Claude Code

• Family problems with Claude Code

• How to pick your level

• By the end: a starting point from your own friction and the level of build that fits this weekend

• The build map: grab it at the end

Subscribe now

The Four Levels

Not every friction point needs an Agent. Not every problem is worth building an App.

The four levels exist so you can match the build to the time you have and how often the problem comes back.

Task. You do it once, right now. No setup, no build. Bring a file or a situation, get a result. Works in Claude Code or claude.ai. Good for one-off problems. Not building in the engineering sense, but going from friction to result in one shot. That’s enough.

Workflow. You build it once so it runs the same way every time. Usually a skill or a slash command in Claude Code. Good for anything you do more than twice a week.

App. You ship it so other people can use it without opening a terminal. Good when the friction isn’t just yours.

Agent. It runs without you. Scheduled, connected to your real accounts, triggered by events. Good when you want the result to exist before you even think to ask for it.

The rule: stop at the level that actually solves the problem. A Task that takes 5 minutes is worth more than an Agent you spend three weeks building for a problem you have once a month.

Share

The Complete Loop: One Starting Point, All Four Levels

Every entry in the article follows this same shape. Here’s the full progression on one real problem.

Starting point: You finished the call. You have rough notes. You promised a summary, an action list, and a follow-up email. It’s been three days.

Everyone has this. Consultant, manager, IC (individual contributor), coach, contractor conversation. The notes exist. The deliverables don’t.

Task: do it once, right now

Paste your raw notes into Claude Code (or any AI). Ask:

Turn these into:
(1) a 5-bullet meeting summary,
(2) a numbered action list with owners and deadlines,
(3) a short follow-up email I can send today.

All three in under 2 minutes. You paste, edit lightly, send. The whole thing takes less time than writing the email alone used to take.

This is Task level. You brought the input, you got the output, nothing was built. Useful. Done.

Workflow: build it once so it runs the same way every time

If you’re running more than two meetings a week, doing the Task version manually starts costing you.

Build a /session-debrief skill: a saved set of instructions that tells Claude how to format your summaries, what to call out in the action list, and what tone to use for the follow-up. Load it once. Every future debrief runs in your structure, in your voice, in under 60 seconds.

What changes at Workflow level: you stop thinking about how to prompt it. Paste the notes, type /session-debrief, done.

Built with: skill + slash command · one afternoon.

App: ship it so others can use it without a terminal

If you’re a coach, consultant, or team lead, and the people around you have the same problem, App level makes sense.

A simple web interface: paste notes, click Generate, get summary + action plan + follow-up email. No Claude Code. No terminal. No friction for the people using it.

What changes at App level: it’s no longer just yours. Other people get the same quality without needing to know how it works.

Built with: plan mode + deploy · a weekend (if you’ve deployed before; add a day if you haven’t).

Agent: it runs without you

Agent level is where the problem stops existing.

Connect Claude Code to your calendar via MCP. When a meeting ends, the Agent triggers: pulls notes from a watched folder, runs the debrief skill, saves the output to a shared doc, drafts the follow-up in your email. By the time you close your laptop, it’s done.

You didn’t think about it. You didn’t paste anything. The summary exists because the meeting happened.

What changes at Agent level: you’re not in the loop anymore. The build replaced the task entirely.

Built with: MCP (Calendar + Gmail) + hook + scheduled routine · half a day on top of the Workflow.

That’s one starting point across all four levels.

The gap between Task and Agent isn’t complexity. It’s how often the problem comes back.

That meeting happens once a month: Task is enough. It happens every day: build the Agent and stop thinking about it.

The next sections map 18 more starting points the same way across the Daily Work, Personal Life, and Family Time.

Each build shows you where to stop. A few show you not to start at all.

Upgrade to Premium

Next:

18 friction points with prompt examples explained in detail. With daily work, personal life, and family time, each mapped across all four levels.

• Work builds (6): contract review, survey analysis, content repurposing, literature synthesis, job research, competitive intelligence scanning

• Personal builds (6): purchase research, negotiation prep, travel planning, deal tracking, file organization, home reappraisal and financial disputes

• Family builds (6): math worksheets, grammar drills, craft step-guides, drawing guides, rainy day activity planning, learning explainers for any question your kid asks

• Every build starts at the friction already exists. Every build tells you exactly which level to stop at.

• 🎁 The build map with 99 builds total across Work / Personal / Family friction points.

Read more

Near the end, asked: “do you have an example of turning this into a paid product?”

I didn’t have anything packaged up yet. But the question stuck.

My instinct: selling with AI is no different from selling without it. Except I had no evidence.

So I took the three AI mentors I built that session, Dan Koe, Justin Welsh, and Alex Hormozi. Put up the simplest landing page I’ve ever made. Added a price.

Someone bought it the same day.

That’s the first step: validate fast, prove the idea, make the first sale.

But one sale doesn’t tell you everything on how to make money with AI. The real work is what comes after.

The iteration. The testing. The parts you can’t hand off to a model.

That’s what has actually done.

This is his second time writing here. Last time, he broke down the Creator Character System behind a 14M+ view content strategy.

He runs Write Your Way To Wealth, where he’s building a $2K/month Substack while holding down a 9–5.

Write Your Way To Wealth

The exact system I use to build a $2K/mo Substack while working a 9–5. Get clear, practical strategies to grow to 1,000 subscribers, monetize your audience, and build a newsletter that compounds into real income.

By Timo Mason🤠

If you’re trying to turn a Substack into a real revenue stream, this one is worth your time.

Timo, take it over.

Howdy, Wealth Gang🤠

“I need more traffic to successfully sell digital products”

That’s what most creators on Substack think, so they keep on writing more articles, and Notes.

Meanwhile, their sales page is sitting there with a 1% conversion rate, quietly leaking sales every single day.

Well… that was me in February.😅

I launched Substack HQ (my Substack content management system inside Notion) promoted it to my list, and waited.

163 people looked at the landing page.

2 bought.

161 people looked at my offer and said “nah, im good.”

I had a conversion problem not a traffic one, so when I recognized this I started an experiment…

Every month I changed one thing, tracked the numbers, and let the data tell me what was broken.

Over time, my CR actually improved…

February: 1% conversion rate.

March: 2%. conversion rate.

May: 8%. conversion rate.

In this article you’ll learn:

✓ Why a low conversion rate is a product problem, not a traffic problem

✓ The exact 3 fixes I tested to go from 1% to 8% conversion rate

✓ The 5 Digital Product Lessons This Experiment Taught Me

In this article I’m walking you through every change I made, why I made it, and what you can steal to generate more sales with your own digital products.

Let’s goo! 🤠

The Numbers Don’t Lie (And Mine Were Ugly)

For every 100 people who saw the Substack HQ landing page, 99 walked away.

A healthy conversion rate for a digital product is anything above 5%.

I was at 1%.

The gut reaction is to blame traffic. “Maybe the wrong people are clicking.”

But these clicks came from my own email list, so these were warm leads and they still didn’t buy.

That told me the problem was somewhere on the landing page, in the mails, or the product itself.

So instead of just writing more content and hoping the numbers fixed themselves, I treated the Substack HQ like an ongoing experiment.

My goal was to find the answer to “Why the hell is my conversion rate only 1%?!”

So each month I picked one thing that could be the reason, fixed it, and checked the numbers 30 days later to see if my 1% conversion rate went up.

Here’s my whole process to 8x my conversion rate, and how you can copy it for your digital products...

Fix Attempt 1: Add Urgency and Collect Feedback

The first thing I looked at was the offer itself.

The price was $29, with no real deadline or urgency.

That means no reason to buy today instead of tomorrow and “tomorrow” for most people means never, so I made two changes.

Change 1: I raised the official price to $49, but added a 50% discount code inside my email automation.

Anyone clicking through from my emails would see the general price is $49, but they’d get it for $25 as a limited-time subscriber perk.

This creates real urgency, makes them feel like they’re getting a deal, and gives them a reason to act now instead of closing the tab.

Change 2: I added an automation that asked every person who clicked the sales page why they didn’t buy.

If people aren’t converting, the least you can do is ask them why.

Maybe the product wasn’t what they expected or maybe the page was confusing.

You won’t always get responses, but the ones you do get are gold.

Here’s what you can apply right now:

If you have a digital product with no urgency on the page, add some.

A limited-time discount inside your email automation or a limited quantity discount inside Gumroad is the easiest way to do it.

Also set up a simple one-question follow-up for people who don’t buy “What stopped you from grabbing this today?” even a handful of replies will tell you more than any analytics dashboard.

Did it work for me?

Sort of.

March 1st to 25th I had 52 cart views with 1 order, which is a 2% conversion rate.

Better than 1%, but still nowhere near good enough.

The urgency tweak moved the needle slightly, but something bigger was still broken.

Fix Attempt 2: Kill the Video

Urgency helped a little, but 2% is still ugly.

So I looked at the page itself.

I had a promo video sitting at the top of the sales page. The idea was that video builds trust, explains the product better than text, and warms people up before they hit the buy button.

Good theory, but data doesn’t care about theory.

I started wondering if the video was actually hurting me, because it got perceived as low quality, or my audience was just into reading, not watching, or it slowed the page down and people were bouncing before it even loaded.

So I replaced the promo video with a clean product thumbnail.

Here’s what you can apply right now:

If your video feels low effort or off-brand, cut it. A clean product thumbnail with a clear headline will outperform a weak video every time. Only keep the video if it’s genuinely good and adds something the rest of the page can’t.

If you’re not sure, test both versions and run the page without the video for a month and compare your numbers.

Did it work for me?

Nope, the conversion rate stayed flat, which actually told me the video wasn’t the problem.

So I had one thing left to test, and this was honestly my last chance to make this experiment work.

The pricing.

If this didn’t push my conversion rate past 5%, I was done. I would stop the experiment and accept that there was no product-market fit.

Fix Attempt 3: Attack the Price Point

This was my last shot.

Maybe $49 was just too much to ask, So I made 2 changes at once.

Change 1: I dropped the official price to $25.

While keeping the 50% discount code inside my email automation, so anyone clicking through from my emails could grab it for $12.50.

Change 2: I removed the bonus that came with Substack HQ

I wanted to save it to launch as a separate product later, but also make the price drop justifiable.

Here’s what you can apply right now:

If you’ve already tested urgency and page elements and nothing moved, go after the price and drop it further than feels comfortable.

The goal isn’t to maximize revenue but to find the price point where your audience actually converts and once you know that number, you can build a money-making funnel around it. :D

Did it work?

May had 53 cart views with 4 orders which is a 8% conversion rate.

Finally past the 5% mark.

Turns out $49 wasn’t the move, but $12.50 for my audience was a 🎯bullseye🎯!

The 5 Digital Product Lessons This Experiment Taught Me

Three months, Three fixes, and a lot of internal doubt in the process😅.

Here’s what I took from the whole thing.

1. Traffic is not your problem until conversion is solved

Most creators pour energy into growing their audience while their sales page sits at 1% conversion. That’s like filling a bucket with a hole in it.

Fix the hole first and then fill the bucket.

2. Test one variable at a time

I changed urgency first, then the page element, then the price.

If I had changed everything at once, I’d have no idea what actually moved the needle.

One change per month, then wait for 30 days to take a peek at the numbers.

It’s slow, but the only way to know with relative certainty what you need to get a good conversion rate.

3. Price is often the last thing creators want to touch

It feels like admitting defeat. Like your product isn’t worth what you thought, but…

Sometimes, your audience is not as willing to spend money as th you expected, and that’s okay. Meet them where they are, get them through the door and show them through their first small purchase how much value you can provide.

4. A cheap front-end product is an introduction, not a money-maker

My goal was never to get rich off $12.50 sales.

My low-ticket solutions intend to turn readers into customers so they get introduced to my product/service ecosystem.

The money is in the upsell and funnel that comes after that first purchase.

5. It takes time and a system to track it

This experiment ran from February to May.

That’s four months of checking numbers, making changes, and resisting the urge to panic or give up too early.

Most people would have killed the product after month one.

The only reason I didn’t was because I had a structure. I knew exactly when to check the numbers (every 30 days), what I was testing, and what the result meant.

And it’s the exact same with content…

Creating consistently on Substack isn’t just about writing but also tracking what’s working, knowing when to post and managing your ideas.

That’s exactly what Substack HQ is built for.

It’s the Notion system I use to run my entire Substack:

✓ Goal Center
✓ Writing room
✓ Content calendar
✓ Inspiration library

So feel free to see what the talk of this whole article is all about. ;)

And if you want to build the foundation of a $2K/month Substack business on top of that system, the Substack Side-Hustle Sprint is the next step, a free 5-day masterclass I built to take you from zero to having a real newsletter business in place.

Subscribe to Write Your Way To Wealth and get the Substack Side-Hustle Sprint for free.

See ya soon

Timo Mason🤠

P.S. Big thanks to Jenny Ouyang for the idea of this article! :D

I just had this as internal documentation, and she gave me the idea to turn it into an article. :)

P.P.S Dominic Kristianto was my sparring partner (or rather my therapist, in case of me telling him all my conversion problems😅) when it came to ideating potential fixes for the landing page, so big thanks to him too! :)

Liked this post? 2 ways you can support me

1. Share it with a creator friend who will benefit.

Share

2. Ask a question or share your thoughts in the comments.

Leave a comment

Tell me if this sounds familiar.

You learned Claude skills. You built one. You wrote a description, added some rules, tested it once.

It worked.

So you started maintaining it. Updating it when outputs drifted. Adding rules when something went sideways. The more you maintained it, the less reliable it got.

Not broken. Just slower. Less precise.

That was me. I spent weeks adding rules.

The rules were never the problem.

Where you put them was. Claude reads the rules at the top first, before it knows the task. Then it starts executing. By step four, the rules from the top have faded.

They’re still in the file. They’re just out of focus when the work happens. Adding more rules to the top just adds more things to forget.

I have close to 100 Claude skills in my Claude setup. The ones that held up weren’t the ones I maintained most carefully. They were the ones built with the right structure from the start.

Structure is fixable. This is what we’ll resolve.

What’s inside:

• How Claude skills work

• How is Claude skill triggered

• What are the types of Claude skills

• How to build a Claude skill body that executes

• How to structure Claude skill references

• How to test a Claude skill

• How to maintain a Claude skill after it ships

• 🎁 A complete build sequence checklist you can run on your next Claude skill

• 🎁 A voice skill template: a plug-and-play skill folder with fill-in markers Claude completes from your writing samples.

How Claude Skills Work

Every Claude skill is three parts, and each one fails in its own way.

The format is small. A folder with one file, SKILL.md: a few lines of metadata at the top, the instructions below, and optional supporting files alongside.

Claude reads the folder, decides whether the skill applies, and runs the instructions when it does.

The three parts, in the order the rest of this article follows:

• Frontmatter: name and description. What Claude reads to decide whether to load the skill at all.

• Body: the instructions Claude follows once the skill is loaded.

• References: supporting files Claude pulls in only when a task calls for them.

Get the frontmatter wrong and the skill never runs. Get the body wrong and it runs but forgets your rules. Get the references wrong and it bloats every session it loads into. Three parts. Three distinct failures. The build sequence takes them in that order.

The mechanic underneath is timing: the three parts load at different moments. The description is always in context. The body loads only when the skill triggers. The references load only when a step calls for one.

Most of a skill sits unloaded most of the time. That’s by design, and it’s why where you put a rule decides whether it’s even in the room when the work happens.

The same SKILL.md runs in Cursor, Claude Code, Cowork, and OpenClaw. I’ll use Claude Code here because it’s the most documented runtime.

The best way to understand skill structure is to open a skill Anthropic actually ships.

Skill-creator comes with Claude, and it's the most complete example I've seen. Beyond the basics it bundles scripts/, assets/, an eval-viewer/, even an agents/ folder of subagents that run from inside the skill.

The left panel is the folder. The right panel is what Claude reads before opening any of it: the description field, the trigger label, how it was built.

How to Write a Claude Skill Description That Triggers

The description is the only thing Claude reads to decide whether your skill runs.

You saw the lifecycle: descriptions load at startup, the body waits for a trigger. Get this one field wrong and the skill never wakes up.

A description that fires does two things, and both decide whether the skill ever runs:

• name the moment it should fire, as a condition and not an option

• put that trigger first, where Claude weighs it most

Follow the right language formula

What the skill does + when to trigger it, in slightly pushy language.

“Slightly pushy” is deliberate. “Can help with X” signals optional, so Claude might invoke it, might not. “Use when Y happens” is a condition, and Claude reads conditions as instructions.

Bad and good, side by side:

❌ Vague, optional, trigger buried
   "A skill for improving writing quality. Can help with
    posts, emails, and more. Use it when writing."
   → no firing condition up front; Claude can't tell when it applies

✅ Specific, pushy, trigger first
   "[Name]'s writing voice. Use whenever you write, draft, or
    revise any prose, even if the user doesn't say the skill name."
   → the condition leads; Claude reads it as an instruction

Write it in the third person. The description talks to Claude about the skill, so “I help with writing” muddies who’s speaking.

Front-load the trigger

Put the trigger in the first sentence, because crowded sessions truncate descriptions and you can’t predict where the cut lands.

You can’t design around the limit either. Claude skills started at 250 characters, then climbed to 1,536 in v2.1.105 while Anthropic’s official guide still listed 1,024.

flagged exactly that confusion after my previous piece on fixing skill triggers.

The number keeps moving. A trigger in the first sentence outlives every change to it.

An example is my own voice skill, the description running this article:

“Jenny Ouyang’s writing voice for Build to Launch. Use whenever Jenny asks to write, draft, revise, or edit any prose: articles, Substack notes, product pages, emails, or any section of content. Trigger proactively before generating any prose. Also trigger when output sounds generic, too polished, or AI-like. This is the universal voice layer for all Jenny’s writing.”

368 characters. It fires reliably because the trigger lands at character 51: “Use whenever Jenny asks to write.”

Two trigger conditions sit inside the first 100 characters. The last sentence is reinforcement, not load-decision material.

Cross-check the front-load part

Read the first sentence of your description. Does it say when to invoke the skill, or only what it covers?

If it’s what it covers, rewrite. Lead with the trigger.

Write the description last, after you know exactly what the skill does and when it should run. Write it as if Claude is reading with one question: should I use this right now?

The description gets the skill in the door. The body is where it earns its keep.

But the body has no single shape. It depends on the kind of skill you’re building, and the type you pick decides how the body runs.

How to Pick the Right Claude Skill Type

Build the wrong type and you’ll rewrite the body.

I rebuilt skills from scratch because the type was wrong. Not the rules, not the description. The fundamental architecture:
- A checklist skill can’t evaluate its own output.
- A guiding skill built as a checklist runs once and stops at the exact moment it should route.

That happened enough times (different skills, different failure modes, same root cause) that the actual structure became clear. Two axes, derived from Anthropic’s agentic patterns research and mapped to SKILL.md bodies: who drives the session, and how the work flows.

Axis 1: Who drives the session

Agent-driven:

The skill controls pacing. It asks questions. It decides when to advance. It loops on quality before finishing.

User-driven:

You ask, the skill responds. No back-and-forth unless you initiate it. The skill executes on what you give it.

Axis 2: How the work flows

Sequential:

Fixed steps, in order, predictable output.

Dynamic:

The path changes based on what you describe or what gets discovered mid-session.

Cross those axes and you get four types. The names are mine; the distinctions trace back to those sources:

Type 1: User-driven + Sequential = Checklist skill

You hand over input. The skill runs fixed steps. Done. The body looks like this:

When given an article:
1. Check title for target keyword
2. Scan for missing header structure
3. Flag sections under 150 words
4. Suggest 3 internal link opportunities
5. Output a prioritized fix list

Numbered. No branching. No questions. It works because the process is the same regardless of the input. Input varies, steps don’t. Most skills you build will be this type, and they should be. The body is simple because the path never forks.

Type 2: User-driven + Dynamic = Diagnostic skill

You describe a situation. The skill reads what you gave it and routes to the right playbook. The body looks like this:

When the user describes a decision:
- Reversible + low-stakes → run the "test fast" playbook
- Reversible + high-stakes → run the "pilot first" playbook
- Irreversible → run the "pre-mortem" playbook
If the decision type is unclear, ask one clarifying question before routing.

Conditional logic everywhere. It works because different inputs genuinely need different responses. Forcing a single fixed path applies the wrong framework to every case that doesn’t match the one you designed for.

Type 3: Agent-driven + Sequential = Automation skill

The skill kicks off a pipeline on a trigger and surfaces a result without back-and-forth. The body looks like this:

On schedule (every Monday):
1. Fetch last 7 days of channel data
2. Identify top 3 videos by retention rate
3. Extract recurring patterns from top performers
4. Write pulse report to /reports/weekly-[date].md

No interaction needed. It works because the trigger is a schedule or event, not a user question. The skill has everything it needs from the environment: a URL, a date range. The output shape is always the same. The body is a pipeline, not a conversation.

Type 4: Agent-driven + Dynamic = Guiding/Mentor skill

The hardest to build. The skill drives the session: it asks, evaluates, loops on quality, and only advances when conditions are met. The body looks like this:

Step 1: Ask which article this is for. Do not proceed until answered.
Step 2: Ask the reader scenario. Do not proceed until answered.
Step 3: Draft a hook. Evaluate against gate criteria.
  → Gate passes: advance to Step 4
  → Gate fails: rewrite and re-evaluate. Max 3 loops.
Step 4: Ask "Does this feel right?" Do not advance until confirmed.

It works because the quality of the output depends on things only discoverable mid-session. A checklist version runs once and produces something generic. The back-and-forth loop is what produces the output worth using. Explicit advance conditions and quality gates aren’t optional. Without them, the skill runs through all steps regardless of whether each one actually worked.

Pick your type before you write the body. If you're unsure which you have, ask one question: does the skill need to ask follow-ups to know what to do? Yes is agent-driven, no is user-driven.

You know the structure and trigger layer. What's left is the build, and the build is where skills actually break.

The rest of this guide builds one skill: jenny-voice, the one assisting my article writing.

It's the guiding type, the hardest of the four, and it leans on every part still ahead: a body that executes, a stack of references, and constraints it has to hold the whole way through.

If the sequence holds here, it holds on anything smaller.

I spent months fixing and evolving this one. The build runs in order from here:

• how to build the body so your rules still fire deep into a task

• how to structure the references so Claude loads them on demand

• how to test it so you know whether a change helped or broke something

• how to maintain it so it holds up months later

Two resources at the end.

• The build sequence, a one-page checklist you can run on any skill.

• The voice skill template, this exact jenny-voice folder emptied to fill-in markers you complete from your own writing.

Watch it on jenny-voice. Then run it on yours.

How to Build a Claude Skill Body That Executes

The body is the instructions block inside SKILL.md. Everything Claude runs once the description triggers the skill.

A skill body that executes does three jobs:

Read more

Each one promised the thing I was missing. Scale faster. Write better. Build a real audience. I’d buy it, feel the hit of possibility, and wait for the transformation.

Then it would sit in a folder.

Not because it was bad. Some of them were genuinely packed with value. The problem was applying any of it required time I didn’t have, energy I’d already spent building, and the kind of sustained attention that doesn’t happen between shipping a product and answering emails.

So the course collected dust.

But one day I went back and actually read through one creator’s free newsletter. The one whose course I’d bought and barely touched. And I realized something uncomfortable: he was saying almost exactly the same things in his free posts. Not word for word. But the frameworks were there. The mental models I’d paid to unlock were all sitting in public, freely distributed, already searchable.

The course wasn’t a scam. The problem was different. I needed engagement in a loop. A mentor I could actually talk to. Someone who could look at my specific situation and tell me what was wrong.

Some carefully packaged courses are full of real value. But 90% of the most resonant insights already live in the low-cost to nearly free material: articles, YouTube videos, podcast clips, books. Already indexed. Already public.

The transformation you paid for is sitting outside the paywall.

So I started hiring them instead.

I built AI versions of the mentors I actually wanted access to, each one specialized in the area where they’re genuinely exceptional.

Hormozi on offers and revenue. Justin Welsh on solopreneur positioning. Dan Koe on identity and digital products. Tim Denning on volume and output.

These aren’t clean divisions. Hormozi writes content, Welsh has offers, Koe thinks about revenue, Denning has digital products too. The labels reflect what I needed from each of them. Your panel gets sliced differently. Built around what you value, not what they default for.

A panel. On demand. No Zoom call required.

So I started by researching each one properly. Not casually reading their posts. Mapping their business model, their core frameworks, the way they think about the exact problems I needed help with.

Then I fed their best content into a dedicated knowledge layer, ran a structured interview to extract what actually mattered, and compressed it into a working mentor I could consult directly in Claude.

The results were better than I expected. (Too harsh that I’m only comfortable sharing a small chunk of it)

The framework behind all of this: 3 prompts, 4 steps. Works on any creator with a content trail.

You could build it from scratch from what I just showed you. What’s below is the exact prompts, the interview structure, and how to set up the knowledge layer so each mentor stays clean.

What’s inside:

• The 3-prompt framework: research, interview, synthesis, plus the curation step between prompts 1 and 2 that determines mentor quality

• Step-by-step setup with exact prompts for each stage:

  • Step 1: Build their resume → structured research brief across 11 layers, one run

  • Step 2: Gather the portfolio → what to collect, how to load it, and where the knowledge layer lives

  • Step 3: Interview the mentor → 3 sequential passes, 7 extraction categories

  • Step 4: Synthesize → compact system prompt Claude holds as standing context

• Taking Mentors to Work:

  • Consulting sessions with video walk through

  • Exact files of each mentor with their detailed business models and mentor skills

• The one plot twist: who the most important voice in the panel actually is

🎁 Already know you want Hormozi, Welsh, and Koe? I’ve done the research for you — all three mentor packs are available as a bundle at store.buildtolaunch.ai/p/mentor-bundle for $35.

Paid members: these are included free in your resources. Details on accessing them below.

The 3-Prompt Framework

One prompt to build their resume. One to interview them. One to synthesize them into a working mentor.

Read more

“It’s smart, but I don’t really know what else to do with it.”

I hear this every day.

I’ve been traveling the past week, onboarding groups to Claude. Researchers. Scientists. Professionals with decades of expertise and accumulated knowledge nobody had ever fully written down.

Almost all of them used Claude the exact same way.

They opened the chat window, asked a question, got a strong answer, and stopped there.

The clearest version hit me while staying with an old friend for three nights.

She’s retired. With decades of fieldwork behind her. Site measurements, project reports, handwritten notebooks, contacts spread across old systems, half-finished ideas buried in directories nobody had opened in years.

She had Claude access.

I watched her use it. Ask a question, get an answer.

And then she shrugged.

“It just answers questions.”

And honestly, that reaction made complete sense.

Nobody had shown her what existed beyond the chat window.

The tabs. The skills. The MCP connectors. The scheduling layer. The persistent context. The workflows. The systems that turn AI from a chatbot into something far more useful.

I realized I was seeing the same pattern everywhere.

Some people had learned how to build entire workflows around AI tools. Most people were still using them like search boxes.

Few had built the bridge between the two.

This guide is meant to be one.

What’s inside:

• Where Claude lives — and what the tabs actually are

• How Claude skills stop you from re-explaining every session

• How MCP works — and why it can access your data

• What plugins are for (and when they actually matter)

• How to start a real project in Claude (in 10 minutes)

• How to make Claude do something your way, every time (in 5 minutes)

• How to schedule Claude to work without you (in 5 minutes, includes practicing)

• Why your Cowork or Code tab might be missing, and how to do about it

Where Claude Lives — and What the Tabs Actually Are

Most people find Claude through a browser. You may have typed claude.ai or claude.com. Both work. You get a chat window. You start asking questions.

What you don’t get, in the browser, is the full picture.

Download the desktop app and it opens three tabs.

Chat is where most people live. Fresh conversation every time, no memory between sessions.

Cowork is where actual project work happens. Claude knows your files. It knows what you’re working on. You don’t re-explain context every time you open it.

Code is for when you want Claude to do things on your computer: run automations, manage files, execute tasks.

Don’t let Code’s name put you off. You don’t need to know how to code to use it. Most of what it does, it handles on its own.

Start with Cowork. That’s the answer to “which one first” for almost every professional with ongoing work to manage.

Chat is where you feel the intelligence. The moment it clicks that this isn’t autocomplete, that there’s real thinking on the other side of the screen. Most people stop there because the conversation is good enough.

But once you’ve felt that intelligence, the next question arrives on its own:

How do I get Claude to do this my way, with my files, on my schedule, without re-explaining every time?

That’s what the next layer answers.

To make the most of Claude Cowork, you need to know these additional things: Skills, MCP connectors, Plugins, Agents.

Same Claude. More gears. The rest of this guide walks through each one.

How Claude Skills Stop You From Re-Explaining Every Session

Here’s the problem skills solve.

You find a way of working in Claude that you like.
A way of summarizing papers that actually captures what you care about.
A way of reviewing drafts that hits your specific criteria.
A way of sorting your inbox that matches your particular system.

And then the next day, you open a new conversation, and you start over.
Re-explain the context.
Re-describe how you want things done.
Get back to where you were yesterday.

Skills stop that loop.

A skill is an instruction set. A written-down version of how you want Claude to do something.

Once it exists, you invoke it by name and Claude follows the same approach every time, without you repeating a word.

Think of a colleague who has a way they always do things. You don’t re-explain the process each time you work with them because it’s already built into how they operate.

A skill is that: written down and given to Claude.

Skills can look very different because they do very different things:

Interactive: Claude asks you questions in a specific order, like a coaching session you can rerun.

Step-by-step guide: Claude walks you through a process one stage at a time. Good for multi-part workflows where sequence matters.

Decision tree: If X, go this direction; if Y, go that way. Useful when the task branches depending on the situation.

Distilled approach: Someone’s entire way of doing something, written down. A mentor’s playbook. Your own best method captured before you forget exactly how you did it. (This is where the “I distilled myself into a skill” posts come from, it’s a real thing, and it works.)

What a skill actually is, mechanically: a folder with a single markdown text file inside, called SKILL.md.

No code, no scripts, no special syntax. Claude reads it the way a colleague reads a one-page handbook, then applies the instructions when you invoke it by name.

You don’t need to know how to code to create one.

And the best way to build a skill isn’t to sit down and write it from scratch. It’s to do the task once, correctly, in Cowork, then let Claude write the skill for you. More on that in a few sections below.

Back to my friend, the retired professor.

Every few weeks she pulls down a batch of emails and sorts them: conferences, student events, papers being reviewed, project correspondence, raw data. Each category gets organized her particular way: dated first, tagged by project, filed under the right timeline.

She’s been doing this manually for years.

That’s a skill in disguise.

One Cowork session: she drops in a batch of emails, walks Claude through how she sorts them. They go end to end. The result is exactly what she’d have done by hand, in a fraction of the time. She captures that session as a skill.

Next month: new batch, same result. No re-explaining.

The first session was the investment. Every session after is the return.

Once that clicked, she started listing.

Summarizing papers the same way every time: hypothesis, what shifted in her field, what to follow up.
Reviewing student drafts with the same five questions she’d been asking for thirty years.
Drafting grant proposal backgrounds the way she always structured them.

Each one was a task she’d done hundreds of times without ever writing the process down.

Each one was a skill waiting to be captured.

“It’s like having a grad student who’s been watching me work for years,” she said, “and finally knows exactly how I like things done.”

That’s the moment it stopped being a chatbox.

→ To browse and install skills, go to Customize in Claude Desktop.

How MCP Works — and Why It Can Access Your Data

MCP is the piece that surprises people the most. And it usually triggers the same three questions, in the same order.

I’ll answer them that way. Each one only makes sense once you’ve heard the answer to the one before.

Question 1: How does Claude even have access to my data (email)?

Think of your data as scattered across separate places. Email on one server. Documents in cloud storage. Research notes in a folder on your desktop. Photos on your phone.

Normally, nothing connects to anything.

MCP is the universal connector, an open standard that Anthropic built and released publicly. Any tool or data source can implement it. When you install an MCP connector, you’re plugging a data source into Claude the same way you’d plug a USB drive into a computer.

That’s the what. Once the picture lands, the next question shows up on its own.

Question 2: But why does that work? What gives Claude permission to reach into another product?

Google has Drive, Gmail, and Calendar. Three separate products, three separate data stores. It doesn't feel weird when Gmail reads your calendar to capture a meeting time, or when a Drive file shows up in a Gmail attachment.

Because you understand: they're all in the same system.

MCP puts Claude into that same kind of shared system with whatever sources you choose to connect.

The “weirdness” disappears once you see what’s actually happening. It’s not Claude wandering into your email on its own. It’s a connector you installed and authorized. You opened the door.

It’s possible because of the open standard. It’s allowed because you said so.

That leaves the practical question.

Question 3: How does the data actually get into the conversation?

Each MCP connector has tools. These tools do the actual retrieval. They reach into the source and pull specific information into the conversation, on your behalf, when you're actively working.

Think of plugging in a USB drive. The connection is the install. The tools are the act of dragging a file across. This is the moment data actually moves into the conversation.

Claude isn’t in your email between conversations. It reads what you ask it to read, when you ask.

What this looks like in practice.

Back to my professor friend with contacts scattered across decades of email. Once she connects Gmail through an MCP connector, she can ask:

“Find every email from conservation organizations I worked with between 2010 and 2018, and group them by organization.”

Behind that one sentence, all three layers fire:

• The Gmail MCP server is reachable because it follows the open standard (access).

• She authorized the connector when she installed it (mechanism)

• Claude invokes the search tool, which queries Gmail on her behalf and pulls the matching emails into the conversation (runtime).

She can then keep going.
“Who introduced me to the Wetlands Trust?”
“Draft a reconnect email to the three most recent contacts”.

Each follow-up uses the same machinery. That whole sequence is what happens when an abstract “MCP setup” becomes a real workflow.

Once Gmail connected, she immediately thought of everything else sitting in silos.
Decades of field measurements.
Scanned notebooks living in a Drive folder nobody had touched in years.
Her literature library, organized by her own tagging system.
Files she’d always gone digging for manually.

With MCP, they become a live layer Claude can pull from while she’s actively working.

The first time Claude found something in five seconds that would have taken her twenty minutes of digging. She started wondering what else she’d been doing the hard way.

→ To browse and install connectors, go to Customize in Claude Desktop.

What Plugins Are For (and When They Actually Matter)

You’ve now seen two of the three layers. Skills tell Claude how to work. Connectors tell Claude what to read.

Plugins are what you build when you want to hand both of those to someone else.

A plugin is a packaged combination: a set of skills plus the connectors it needs, wrapped together and distributed as one thing.

Here’s a concrete example.

Say you want Claude to read your Gmail every morning, find your important meetings, rank them by priority, add them to your calendar, and flag the next steps for each one.

That workflow needs a skill (the logic) plus a Gmail connector, a Calendar connector, maybe a local files connector.

Package all of that together and you have a plugin. One install. Done.

The person you share it with doesn’t need to configure three things separately. Connectors are included in the plugin. They click install and the whole workflow is live.

When plugins matter — and when they don’t:

If you’re working solo and comfortable managing skills and connectors yourself in Cowork, you don’t need plugins. Skills plus connectors handle everything a plugin does, they’re just in separate pieces.

Plugins matter when you’re handing a complete workflow to someone else.

Plain framing: Skills are how Claude thinks. Connectors are what Claude reaches. Plugins are when you box both up to hand off.

→ To browse and install plugins, go to Customize in Claude Desktop.

Skills, connectors, plugins, all three live in one place: the Customize section in Claude Desktop.

That’s where you browse, install, and manage everything. If you’ve been looking around the interface trying to find where Claude’s best capabilities live, that’s it.

How Claude Agents Work (and When to Use Them)

An agent is a skill and a set of connectors running autonomously on a task.

You give Claude a goal and it works through the steps on its own: reads what it needs, makes decisions, checks results, keeps going until it’s done or needs your input.

You’re not in the loop for each step the way you are in a normal conversation. That’s the meaningful difference.

You're not installing an "agent" in Claude Cowork.

Instead, you can watch it happen.

The interface below shows Claude's internal steps as it works through them, and subagents triggered along the way.

How to Start a Real Project in Claude Cowork in 10 Minutes

By the end of this section, you’ll have a real Cowork project running. With Claude pointed at your actual files, knowing what you’re working on and why.

I used to overthink the setup. Don’t.

Open the Cowork tab and type /setup-cowork. Claude walks you through five steps. The whole thing is about ten minutes, and by the end it’s running against your real work, not a demo.

One thing to grab before you start:

A folder with files you’re already working with. It doesn’t need to be organized. It just needs to be real, a paper you’re reading, some meeting notes, a half-finished document, photos from a project, anything.

Claude is going to orient around what you’re actually doing, not create work from nothing.

Then: open the Cowork tab and type /setup-cowork.

That one command kicks off the whole process. Claude walks you through five steps, in order. The whole thing is about ten minutes.

Here’s what /setup-cowork walks you through:

1. Answer Claude’s questions about your context. Who you are, what kind of work this is, what you’re trying to do. This is how it tailors what comes next. Don’t skip it.

2. Review the plugin suggestions. Claude will suggest packaged workflows based on your context. Scan them. Install the ones that look relevant. Don’t stress about getting this perfect. You can add or remove plugins later.

3. Review the skill suggestions. Same idea: individual instruction sets for specific workflows. Take the ones that look useful.

4. Review the connector suggestions. These are the MCP connections to your data sources. Install the ones that match what you want Claude to read.

5. Finish with a working project. You’ll end up with a Cowork project pointed at your actual files, with context Claude carries into every conversation you open inside it.

The honest caveat:

The suggestions in steps 2–4 are educated guesses. Some will be a great fit. Some won’t apply to you at all. That’s fine. The point of setup isn’t to find the perfect stack on the first try. It’s to know what exists and start somewhere.

How to Make Claude Do Something Your Way, Every Time

Once you’ve run a task end-to-end in Cowork and liked how it went, you have everything you need to make it permanent.

Don’t start over next time.

Say you walked Claude through revising an article title, then adding structural sections, then expanding each section into full content. You came out the other end with something you were happy with. The result was good because the session was good.

That’s when you type /skill-creator.

Claude takes that session and builds a working skill from it. It creates the files, sets up the structure, defines the trigger phrase.

What comes back is a skill you can invoke by name in any future conversation. Same approach, same structure, same output format, without re-explaining a word.

The three-step process:

1. Do the task end-to-end in Cowork. The way you’d actually want it done. Don’t shortcut it. Work through it until you feel satisfied with the output.

2. Type /skill-creator at the end of the session. Not before. Not halfway through. At the end, when the result is already good.

3. Claude builds the skill file. It creates the folder, writes the instructions, sets the trigger. You end up with a reusable skill, built from a session that already worked.

You’re invoking a built-in skill (skill-creator) to build a new skill. Exactly as meta as it sounds, and exactly as practical.

The alternative is to write the skill manually from scratch. I’d skip that for your first one. Do the task first, get it right, then capture it. That’s the order that works.

How to Schedule Claude to Work Without You

Most people don’t know Claude can run workflows on a schedule.

It can.

The built-in skill is /schedule. Here’s the order that works.

1. Run the two defaults first.
   Open the schedule area and look for the daily brief and weekly brief already set up.
   Run them. Let them complete. Seeing what a scheduled workflow produces — what it includes, what it skips, how it reads — gives you something concrete to build from. Much easier to customize something you’ve seen than to design one from nothing.

   

2. Build your own with /schedule.

   Once you've seen the defaults, type /schedule in Cowork or Code. Claude walks you through setting up a custom workflow: a morning digest of important emails, a weekly summary of your research notes, an automated folder review every Friday. Anything that runs in those two tabs can be scheduled.

   

3. Know the machine constraint. Scheduled tasks run on your computer, not in the cloud. Your laptop must be awake and Claude Desktop must be open at the time the task fires. If your laptop is closed, Claude skips that run and picks it up the next time you open the app.

One important distinction: Scheduled tasks work in Cowork and Code, not in Chat. If you’re building something you want to run automatically, it needs to live in one of those two tabs.

Why Your Cowork or Code Tab Might Be Missing

If you open Claude on your work computer or your university login and don’t see Cowork or Code anywhere, you’re not missing something obvious.

Your organization almost certainly disabled those features.

This is common. Universities, hospitals, research institutions, and large organizations frequently restrict Cowork and Code for their team plans.

The reasons vary: data privacy policies, security reviews, IT governance requirements, etc. But the experience is the same. Features that exist for individual subscribers are grayed out or absent entirely for institutional accounts.

Last week I visited Dartmouth College. The number of features disabled for their institutional plan was striking:

• Code grayed out.

• Only a handful of pre-selected connectors, no option to add new ones.

• No Cowork tab.

• No skills options.

• No plugins options.

My retired professor friend was genuinely disappointed. That’s not unusual for universities and large institutions.

What you can do:

If you’re on a team or institution plan and don’t see Cowork or Code:

→ Ask your IT administrator or account admin whether those features can be enabled for your account.

They may be available but not switched on. Worth asking before assuming they're gone.

If the tabs are locked and IT can’t help, here’s the workaround.

Claude Projects are available on most plan types, including many institutional accounts where Cowork is disabled.

The setup takes about five minutes and gets you most of what Cowork offers.

1. Create a Project and upload your files. In Claude (web or desktop), create a new project for whatever you’re working on. Upload the files you want Claude to have access to — documents, notes, papers, anything. The project keeps those files in reach across every chat you open inside it. That’s your persistent context, the equivalent of pointing Cowork at a folder.

   

   

2. Build skills as uploaded files.
   In Cowork, skills get installed as instruction files Claude invokes automatically.
   In a Project, you do it manually: run a task in a Project chat the way you want it done, then ask Claude to write up the instructions as plain text.
   Copy that text into a file on your computer — something like summarize-papers.txt — and upload it to the Project alongside your other files.

   

3. Call each skill by name. In any chat inside the Project, just name it: "Use my paper-summarizing instructions on this." Claude reads the file and follows the process. Same result, more manual setup.

It’s not as seamless as Cowork’s built-in system. But the underlying capability is the same: context that persists, workflows that repeat, your files in reach.

If you’re on an individual plan and still don’t see them:
→ Check that you're using the desktop app, not the web browser. The browser version doesn't always surface all tabs.
→ Check your plan level. Cowork and Code availability varies by tier and location.

Next Steps

If you’ve never opened a tab other than Chat:
Start in Cowork. Point it at a folder you’re already working in. Type /setup-cowork and follow the five steps. Don’t worry about plugins or MCPs yet. The setup process will surface what’s relevant for your situation.

If you’ve tried Cowork but never set up a skill or MCP:
Pick one thing you do repeatedly in Claude. Run it once in Cowork, end to end, the way you want it done. Then type /skill-creator. You'll have a reusable skill in one session.

If you’ve set up skills and MCPs but still feel like you’re guessing:
Go to the complete AI builder resources hub. I’ve mapped the best MCPs and plugins by use case. Find the ones that match your work, not just the most popular ones.

Frequently Asked Questions

What’s the difference between Claude Chat, Cowork, and Code?
Chat is a fresh conversation each time, good for one-off questions and brainstorming. Cowork is a persistent project assistant that knows your files and context, good for ongoing work. Code has full admin access to your computer and can run commands, write files, and manage your system, good for technical tasks you’d want automated.

Is MCP safe? Why does it have access to my data?
MCP is a controlled access agreement. It doesn’t give Claude free access to your data. You install specific connectors for specific sources, and each connector has tools that retrieve information only when you’re in an active conversation. You authorize each connection.

What’s the difference between a skill and a plugin?
A skill is the workflow logic, how Claude does something. A plugin packages a skill plus any connectors it needs into one distributable unit. Plugins are most useful when you want to share a complete workflow with teammates or across an organization.

Do I need plugins to get started?
No. Most solo workflows run fine with skills and connectors open directly in Cowork. Plugins matter most when you’re sharing workflows with other people.

Why don’t I see Cowork or Code in my Claude interface?
You’re probably on an institutional or team plan where an admin has restricted those features. It’s common at universities and hospitals. Ask your IT administrator whether those tabs can be enabled for your account. If you’re on an individual plan, check that you’re using the desktop app and confirm your plan level.

What would change if Claude could do that one thing you keep using it for, consistently, every time?

— Jenny

Why Upgrade · Practical AI Builder Program · Claude Hub · Vibe Coding · AI Agents · Shipped Products · Substack Growth

They read the posts. Watch the videos. Buy the course. Maybe try to model them.

But following is passive. You see the output. You don’t see what’s underneath it.

The newsletter, the YouTube, the free book. You consume all of it. What you don’t see: the funnel those pieces feed into, the tech running the operation, the offers they actually make money from, the frameworks they teach versus the ones they quietly use to sell.

The result: you copy the surface layer. You start posting daily because they do. You add a lead magnet because they have one. You pick a pricing tier because theirs looks about right. None of it connects to the underlying logic, because you never saw the underlying logic.

That’s what I built for “Creator Scout”. One creator. One prompt. One brief covering every layer of their business, from domain age to offer stack to what’s actually worth stealing.

What’s inside:

• See what a complete scout brief looks like: Hormozi’s TL;DR and “What to Steal” section, free

• How to run Creator Scout: MCP trigger phrases, the full prompt to paste, and which depth level to pick

• How the prompt works: tools and techniques behind each of the 9 layers and 8 phases

• Access: the full Alex Hormozi scout brief

• Access: the full Justin Welsh scout brief

• How to read a brief and find what’s actually worth copying

• Three use cases: competitor research, mentor prep, collab vetting

• What Creator Scout can’t see: how to fill those gaps

What a Creator Scout Brief Looks Like

Before the how, here’s the what.

This is from the Alex Hormozi brief, generated from acquisition.com at standard depth:

Alex Hormozi runs a content-first empire where everything free — books, audiobooks, courses, podcasts — feeds one high-ticket backend: Acquisition.com partners with $1M–$10M EBITDA founders for equity. Content reaches 7.8M+ followers across platforms, ~700K email subscribers, and 25M+ podcast downloads. He co-founded Skool (owns equity), so his community platform is also his investment. The business gives away the information to sell the implementation.

The full brief runs through 11 structured sections: identity, offer stack, marketing engine, SEO posture, tech stack, IP and frameworks taught, social proof playbook, Wayback findings, what to steal, what to avoid, and open questions.

The “What to Steal” section is where most of the value sits. From the Hormozi brief:

1. Give the book away free as infrastructure, not a lead magnet. Permanently free audiobooks build authority faster than any paywall.

2. The Value Equation as a teaching framework. One visual formula that readers screenshot and share.

3. Consent-based phone capture on lead magnets. The Scaling Roadmap collects phone with explicit consent. Most creators only capture email.

4. Revenue-qualify at the top of the funnel. “$1M+/yr revenue minimum” on the public page filters serious buyers before any sales call.

5. Radical proof specificity. “$46.2M exit,” not “mid-8-figure exit.” Specificity signals honesty.

6. Named systems for everything. Grand Slam Offer, Value Equation, Mozi Media Content Method. Named systems are more memorable and more shareable than unnamed advice.

Six moves worth examining before you copy anyone’s strategy.

The sections below includes:

• the full Creator Scout prompt, what each part does and which depth to run

• full access to Hormozi and Justin Welsh scout output

• plus the complete how-to for running Creator Scout on any creator you want to study

How to Run Creator Scout

Read more