That can look thorough while leaving out an entire source of ideas: YouTube.

A web search may surface a YouTube link. For a research tool to analyze YouTube itself, it needs direct access to video and channel data, including views, likes, and comments. If you also want to know what was said inside a video, your tools need a transcript source too.

Without those connections, you can finish a research and still miss the video that should change your angle. That missing idea could become your next newsletter, blog post, X post, or the next video you decide to record.

That was the problem behind Episode 25 of One Shot Show.

GenAI Unplugged

Learn to build production-grade AI automation systems (setups, prompts, workflows, and templates) from someone who builds them at work by day and ships his own products by night.

By Dheeraj Sharma

built a YouTube research agent in Claude Code that could search YouTube data, inspect videos and channels, compare recent and older results, and rank possible topics based on his content niche. Then he added the part that made those rankings useful: files describing his channel, the subjects he avoids, the competitors he watches, and the criteria he uses to judge an idea.

The session was in-depth.

It walked through five layers behind the YouTube research agent. We started by explaining how you can integrate your agent with the YouTube Data API, then went through each layer, with each one answering a different question:

1. What can the agent see?

2. What should it remember?

3. What does it need to know about this YouTube channel?

4. How should it judge an idea?

5. How should it run and return a recommendation?

In this post, we’re giving you an agent folder that you can use and customize to match your content style. If you follow all the instructions below, you’ll be able to run research across YouTube and get detailed information on any video, including key metrics, channel details, and the full transcript.

Here is how the full system came together.

Let’s dive in.

Subscribe now

Layer 1: Give the Agent YouTube Data

Dheeraj began with the integration layer. This is where outside information from YouTube can enter the agent.

In earlier One Shot Show builds, that usually meant connecting an MCP server, a Claude connector, or a command-line tool such as Tavily CLI. This time he built a small local script that called the YouTube Data API directly.

To connect YouTube Data API, you need to start with accessing Google Cloud Console:

1. Create or select a Google Cloud project.

2. Enable YouTube Data API v3.

3. Create an API key.

4. Restrict that key to the APIs the project needs.

5. Store the key outside the source code.

Once you get the API key, you need to store it in .env.local in your local folder.

Then, you need to teach Claude how to interact with the YouTube API through a script. So he asked Claude to create a script with the functions the agent would need to interact with the YouTube API, including:

• Search for videos by topic.

• Retrieve video statistics.

• Look up channels by name.

• Compare a group of competitor channels.

• Separate Shorts from long-form videos.

• Retrieve thumbnail URLs for pattern analysis.

What this means is that your agent will be able to interact with any of YouTube’s features, so you can use it to run research.

Here’s the prompt you can copy and use so your agent can generate the same script for you:

Read more

This month, I’m also experimenting with compiling interesting AI workflows and news I find on the internet to share with you. It could be an agent template, a skill, a GitHub project, or an AI tool integration you should try in your daily workflow.

Each month, you can expect to learn something new based on what I’m seeing people on the internet do with AI.

I’m labeling this format as: What’s New in AI.

Before we run through each question and explore what’s new in AI, here are some related past posts you should read this month:

1. 10 ChatGPT Work Features That Made Me Use Claude Code Less: this is a must-watch if you are shifting to use ChatGPT Work more, like I did.

2. How I Use Claude Code Routines to Run Work While My Laptop Is Closed: if you want to automate your AI tasks without opening your laptop, you need to learn how to maximize Claude Code Routines.

3. How I Built Multi-Model Council Inside Claude Code With OpenRouter: learn how to use open-weight models to review your decisions.

4. I Rebuilt Alex Lieberman’s AI Content Machine for Solo Creators: let AI interview you so you can generate infinite content that matches your real voice.

5. SEO Research Agent to Turn Competitor Rankings Into a Content Plan: learn which keywords are ranking well on the internet and how they compare against your competitors before you write anything.

Most of the questions asked this month can be traced back to those articles, so you can read them later.

Subscribe now

Now let’s explore this month’s questions.

Four AI Maker Lab members sent questions:

1. Ron is already using Codex and ChatGPT for resumes, cover letters, and websites, but he is unsure whether he is using them well.

2. Shuba wants to automate research from LinkedIn and other sites that require a login.

3. Claire has too many paid newsletter subscriptions and needs a way to separate what matters to her life and writing from what she can ignore.

4. Des asked whether I use ChatGPT’s browser to publish on LinkedIn, which opened up a useful comparison between browser control and a direct publishing tool like Typefully.

There was a lot I had to unpack to answer all of them because each question requires different tools and approaches to solve.

So, in this post, I worked through all four.

During the live session, I built a resume comparison site in ChatGPT Sites, opened my signed-in Substack analytics in the browser, showed how Record & Replay turns a demonstrated process into a Skill, explained why I use Typefully for publishing my content to social platforms, and mapped Claire’s newsletter filter around one Gmail label and six judgment questions. That last answer builds on How I Use Newsletters As A Signal System, Not A Reading List.

For What’s New in AI: I shared one of my favorite AI workflows for running research on YouTube using Supadata, which returned 20 GrokBot videos and pulled their transcripts during the session. I also stumbled upon a new Skill from the Anthropic team called ELI5 (Explain Like I’m 5) and a Diagram Skill to help you visualize flows using diagrams. I also shared my current caution around Ollama’s Claude integration and why I’m skipping Perplexity’s Portable Computer for now.

Let’s dive in.

Ron: Am I using Codex and ChatGPT well for resumes, cover letters, and websites?

Ron is already using Codex and ChatGPT for resume generation, cover letters, and websites. His question was whether ChatGPT is actually useful for his job, and he wanted to explore some interesting use cases.

So, I showed him ChatGPT Sites.

Sites can create, preview, publish, and share an interactive website or lightweight app. During the session, I used a simple prompt:

Read more

One of the reasons I like writing about AI is that almost every day, I get a chance to test a new AI tool. And more and more, I see that as part of my job here. I get stuck in the setup, make the mistakes, and report back what I learned so you do not have to repeat all of the trial and error yourself.

You probably know by now that I also take SEO seriously when it comes to growing this newsletter. Even with all the attention going to GEO and AI search, Google still brings new readers to AI Maker.

According to my August 2026 numbers, search contributes around 15 to 20 percent of my new subscribers, but roughly 40 to 50 percent of my new subscription revenue. That is enough for me to keep paying attention to it.

That is why I previously built an SEO review agent for my Substack posts. It starts with a finished draft, uses Tavily to inspect the current search results and competing pages, then gives me the SEO work I usually leave until the end: a possible search angle, metadata, slug suggestions, internal links, image alt text, and a list of things I should leave alone.

I still use that process. But after building it, I realized there was an earlier question it could not answer very well:

What should I write in the first place?

Let’s say I wanted to write about Claude Skills. My review agent could read a finished post, check what was already ranking, and suggest a search phrase that seemed to fit.

But it could not accurately tell me how many people were searching for each phrase, how difficult those searches might be, or what my own Search Console and Google Analytics data suggested I should investigate before I committed to the topic.

What happened instead was that I invested so much time writing a piece of content before consulting my agent about what to write.

So I started looking for a research service that could give my agent real search data earlier in the process.

Of course, tools for this already exist. Ahrefs has a $29 Starter plan, but its MCP access begins with the $129-per-month Lite plan. Semrush’s SEO plan costs $139 per month, while its MCP-enabled plan costs $199 per month as of August 2026.

Both are serious SEO platforms. They also have far more capability than I need for this one research process. For a one-person newsletter, I could not justify paying for a large SEO suite when I knew I would use only a small part of it.

What I wanted was much narrower. I needed current keyword and competitor evidence. I wanted to connect Search Console and Google Analytics. And I needed direct access through MCP so my agent could retrieve the data instead of sending me into another dashboard every time.

That last part matters for how I work now.

Because my AI Maker agent already knows my publication goals, reader profile, content archive, conversion analysis, and SEO rules. I wanted it to bring all of that together with what people were actually searching for and which pages were already ranking.

That is when I found OpenSEO.

I know what some of you might be thinking. I found another new AI tool, and now I am writing about it.

Fair.

But hear me out, because I think OpenSEO offers a clear value here.

OpenSEO had a $10 hosted plan when I tested it. It has an MCP connection, so Claude Code, ChatGPT/Codex, and other compatible agents can call its research tools directly. It can also connect read-only Google Search Console and Google Analytics data, then combine that first-party data with keyword estimates, live search results, and competitor research.

Together, those sources gave me a way to do more than ask an AI which keywords that aligned with my business.

So, I knew I had to write this.

But, once I started looking around, I realized I could easily turn this into a much bigger post. OpenSEO also includes rank tracking, backlink research, site audits, and saved keywords, along with an AI Visibility feature that shows whether available ChatGPT and Google AI Overview results mention or cite your brand. That gives me another area I want to explore later: using those mentions, cited pages, and related prompts as evidence for improving what people usually call GEO.

The Google Analytics connection opens up another set of possibilities. The agent can pull organic performance, landing pages, traffic acquisition, engagement, key events, ecommerce outcomes, and other reports from the connected property. I can imagine using that to create a recurring organic-traffic brief or an automated report that tells me which pages are bringing meaningful results.

But I want to keep this post specific and focused on one job: start with real keyword data from your own website, research the competitors that matter for those keywords, and turn the findings into a content plan. I’ll come back to the GEO and Google Analytics workflows later on if you want to learn more about them.

So I decided to test one question:

Could I start with what my website already knows, use OpenSEO to investigate the sites competing for those searches, and finish with an actual content plan?

Start With What Your Website Already Knows

For AI Maker, the first place I looked was Google Search Console.

It showed me the queries already causing my posts to appear in Google, the pages connected to those searches, and where I might have room to improve. I focused on recent non-branded queries, especially the ones ranking somewhere around positions 5 to 20.

Those positions do not guarantee an easy win. But Google already associates my website with the subject, which makes them more useful starting points than a broad topic an AI agent generated for me.

I also looked at the words people added around each subject. Were they searching for a setup, a guide, a review, a comparison, or a way to connect two tools? Those modifiers helped me understand what the searcher was actually trying to do.

Then I compared the queries against my existing archive. My data/content-index.csv contains 186 indexed URLs, so the agent could see whether I already had a page serving the search, whether an older page could be improved, or whether several posts might compete for the same intent.

I added my publishing goals and directional conversion data too.

That gave the agent four useful inputs:

1. Search Console queries and their connected pages.

2. My existing content archive.

3. My reader and publishing goals.

4. Google Analytics or Substack outcomes when they changed the priority.

What if your website does not have enough search data?

For a newer site, you can also follow my process by asking your AI to analyze your website.

I would ask the agent to read the homepage, About page, product or service pages, and the most important existing content. It should identify who the website helps, what those people are trying to do, what the site can credibly help them with, and which audiences or topics would be a poor fit.

From there, the agent can generate five to ten specific query hypotheses to analyze later. I want to emphasize the term hypotheses here, because the agent still does not know whether people search for them or what kind of results Google rewards.

Check the queries with OpenSEO

This is where OpenSEO became useful.

For each candidate, I checked the estimated search volume, trend, keyword difficulty, likely intent, and the pages currently ranking. A query stayed in the research only when three things were true:

1. There was enough evidence of search demand to investigate it further.

2. The search intent matched the audience or offer.

3. I could credibly create or improve the kind of page already ranking.

OpenSEO’s volume, difficulty, and competitor numbers are estimates, so I used them to compare opportunities. Search Console remained the direct evidence of what had already happened on my website.

Here are example queries from the Claude Code cluster that my agent unpacked based on what’s shown on my Substack pages:

The goal was a small set of five to ten approved queries. That was enough to represent the search area and show OpenSEO which competitive landscape it should investigate.

Subscribe now

How the Competitor Rankings Became a Content Plan

Once I had the approved queries, I used OpenSEO to find the domains that kept ranking across them. Then I selected the competitors that matched my audience, inspected their ranking pages, and ran a second keyword pass on the gaps that looked useful.

The last check happened inside my own archive. For every opportunity, the agent had to decide whether I needed a new page, already had the right page, needed broader coverage, or should leave the topic alone.

That gave me four possible decisions:

• TEST: keep investigating before deciding whether to create or change a page.

• WRITE: create a distinct new page.

• UPDATE: retarget an existing page that should own the query.

• EXPAND: keep the page’s current target and add missing coverage.

• IGNORE: leave the opportunity outside the SEO plan.

Then came the interesting part.

One of the recurring competitors was Ruben Hassid’s Substack.

As of August 24, 2026, OpenSEO estimated his site at 30,394 organic traffic and 970 ranking keywords, compared with 19,418 traffic and 682 keywords for AI Maker.

We also have a large overlap in keywords targeting “Claude skills.” Here’s how the competitive landscape looks for the Claude-skill keyword cluster.

Ruben used exact-match slugs, published one page for each named topic, and built pages around specific problems such as Claude usage limits. At the same time, none of the pages appearing in his top 100 ranking keywords covered Claude Code hooks, subagents, MCP, plugins, or CLAUDE.md.

That gave the agent several gaps to investigate. OpenSEO checked those topics again for demand and difficulty, then the agent compared them against my Search Console data, archive, and directional subscriber outcomes.

Here is what survived that process.

UPDATE: Claude Code hooks

OpenSEO estimated “claude code hooks” at 3,600 monthly searches with a keyword difficulty of 16.

I already had a paid post about Claude Code hooks. It had received 906 search clicks, ranked around position 8.5, and had nine attributed paid subscribers. That works out to roughly 9.93 subscribers per 1,000 search clicks, which is one of the stronger conversion rates in this research set.

Ruben had no hooks page among his top 100 ranking keywords. But because I already had the right asset, creating another broad Claude Code post would have added overlap without solving the targeting problem.

The decision was UPDATE: make the existing page more clearly target “claude code hooks” and preserve the page that was already converting.

WRITE: Claude memory, pending one scope decision

“Claude memory” looked almost too good when OpenSEO returned it: an estimated 2,900 monthly searches with a keyword difficulty of 2. Ruben had no memory page in the ranking set I reviewed.

But my archive changed the recommendation.

I already had a guide about Claude Projects memory ranking around position 6 with 3,218 search clicks. A new page could easily compete with it if the angle stayed broad.

So the agent marked this as a possible WRITE, with medium cannibalization risk and one unresolved decision. The existing guide would need to keep Claude Projects memory, while the new page would focus specifically on Claude Code memory through CLAUDE.md and continuity across sessions.

I have not approved that page yet. I need to confirm that the two posts can answer genuinely different searches before I write anything.

This is part of what made the research useful to me. It found the opportunity and also showed me the decision I still had to make myself.

EXPAND: Claude Code usage and limits

My existing Claude Code usage-limits post was already ranking around position 6.8. The page had the right intent, but its query coverage was narrow.

Ruben’s equivalent page ranked for a broader family of 21 keywords and had an estimated traffic value of 2,742 across them. It also ranked around position 6 for “claude usage limits”, between two Anthropic pages.

That was enough evidence that an independent Substack page could compete in this search area. I also had no other page targeting the same topic.

The decision was EXPAND: keep the existing page and add the missing usage-limit questions instead of publishing a duplicate.

IGNORE: tool comparisons as an SEO revenue priority

This was probably the most useful decision in the plan because the keywords looked attractive.

OpenSEO estimated “claude code vs cursor” at 6,600 monthly searches with a keyword difficulty of 5. “perplexity vs claude” showed 2,900 searches with a difficulty of 0. Those numbers make the topics look easy to justify.

My own data told a different story.

Across six comparable AI Maker pages, tool-comparison posts had produced 17,428 search clicks and six attributed paid subscribers. That is approximately 0.34 subscribers per 1,000 search clicks, based on the August 18, 2026 archive analysis. The build and method posts in the same analysis averaged around 8.2 subscribers per 1,000 clicks.

The decision was IGNORE for SEO monetization. I may still write a comparison when it helps with timeliness, authority, or social reach. I just would not put it on the search-driven revenue calendar.

The final content plan

The four decisions gave me a comprehensive view of what to do for each keyword. Then I asked my agent to create a content plan I can follow to improve my SEO based on the report.

Here is the plan it produced:

That gave me the outcome I wanted from the research. I knew which page to work on first, which new posts still needed evidence, and which tempting keywords did not belong on the plan.

What We Are Building: SEO Research Agent

After the first experiment, I wanted to make the same research process repeatable.

So I turned it into an SEO research agent with one main job: run competitive keyword research and generate a content plan for my newsletter so I can expand my keyword territory.

The process involves deploying three sub-agents, each with its own assignment:

1. Find and validate the starting query territory.

2. Select relevant competitors, inspect the pages that matter, and propose gaps.

3. Validate those gaps, group the surviving queries, determine page ownership, and surface cannibalization risk.

I’m also providing the agent folder you can download and use right away, but you’ll still need to customize it and add some data and project context files that align with what you’re building.

What you will build in this guide

1. The local project foundation: record your site, audience, offers, goals, writing rules, OpenSEO connection, content inventory, and optional business outcomes in files the agent can inspect.

2. The OpenSEO data connection: give the agent access to Search Console plus current keyword, search-result, and competitor evidence through MCP. Google Analytics can be added when it changes how you prioritize the plan.

3. One delegated research skill: start a complete opportunity study with one request while three subagents handle the specialist stages.

4. A four-artifact evidence: preserve the queries, competitor findings, opportunity map, and final decisions in one dated run folder.

What you need before starting

• Claude Code, ChatGPT, Codex, or another coding agent that can read local files and run a project-level skill.

• An OpenSEO account. Its hosted plan was $10 per month. It’s so cheap for a starting point.

• Google Search Console for an established website, or enough website and offer information to complete the low-data path.

• Google Analytics, Substack data, or another business outcome when you want the agent to prioritize beyond traffic.

OpenSEO’s research tools use credits, so I recommend starting your research with small batches and checking the results after each stage, so you know what cost to expect. In my latest run, it cost me less than $1.

By the end, you will have an SEO research agent that starts with your website, investigates the competitors that matter for searches you can credibly serve, and leaves you with a few content decisions you can take action on.

Let’s build it.

Create Your OpenSEO Account

The first thing we need to do is sign up for OpenSEO. This is where all the data will come from, especially Google Search Console, where all organic queries, keyword rankings, and pages that show up on Google will be accessible.

Now, you need to complete any remaining information about your project. There are a few steps you must take to finish setting up your project data, including filling in the general information, providing the context, and connecting both Search Console and Google Analytics.

Here are some steps you need to do after you sign up:

Read more

One of my earlier AI Maker newsletter setups was built around a giant master prompt.

It told Claude who I was, who I wrote for, how my voice sounded, what I believed about AI, what kind of content I wanted to create, and how I judged whether an answer was useful.

Here’s the post if you want to see it:

It included my audience, content pillars, goals, operating modes, quality rules, and all the things I wanted the AI to challenge.

Basically, I tried to set up the entire relationship with the AI upfront. I even created multiple Claude projects tailored to specific use cases such as writing, product offerings, research, and more.

Looking back, those were the good old days. I learned a lot from that experience.

But these days, when I have a rough post idea or something I want to talk about, I rarely go to Claude Chat anymore. Since my agent knows everything about my business, I usually start with one question:

What do you think about this idea?

That is close to how this post began.

I had a half-formed thought that one sign your AI system is improving is that your prompts get shorter. I shared the idea, asked what the agent thought, and started talking through it.

There was no giant briefing attached.

The agent already knew my audience. It knew how I write. It knew the ideas I had covered before, the kind of reasoning I find useful, and the standards I use when deciding whether something belongs in AI Maker.

So the conversation could start from the idea itself.

That is when this became obvious to me: the better my AI system gets, the less I have to explain every time I use it.

Subscribe now

What Changes When Your AI Already Knows Your Work

For a long time, I thought getting better at AI meant getting better at preparing prompts.

You define the role. Add background. Explain the audience. Include examples. Set the format. List the constraints. Tell the AI what to avoid.

All of that can improve an answer.

But it also means you have to prepare everything before the real conversation happens.

This is still how AI works when you rely on standalone chats or projects that carry very little background. Every request begins with another briefing.

You can use AI every day and still carry the real system in your own head: the audience, the standards, the examples, the history, and the process.

The AI may help complete the task, but it cannot build on much from the task before it.

This got me thinking: If I keep doing the same work and need to provide the same background every time, the setup has not improved around that task yet.

A better system should gradually absorb some of that repeated explanation.

The way I work now feels different.

I can bring an idea to my agent and ask what it thinks. If I do not like the answer, I keep talking. I question the reasoning, clarify what I meant, reject an angle, or follow one part that feels more interesting.

After a few conversations, I usually have a better sense of the angle, the outline, or what I actually want to write.

It feels closer to a brainstorming session with someone who already knows my work.

Sometimes it feels a little like having my own Jarvis.

The prompt is still there. It just has a smaller job.

How the Context Funnel Makes Shorter Prompts Possible

So, you might be wondering how I went from writing long, detailed prompts with background, audience, style, and rules… to using short prompts instead.

Think of this as a context funnel. Your AI system may have access to a large body of project knowledge, but only a small part of it should enter the current conversation.

The system narrows that knowledge to what the task needs. Your prompt adds what changed today: the new idea, source material, constraint, or decision.

One name for the work behind this is context engineering.

I heard about it first time a year ago from Tobi Lutke, CEO of Shopify.

Context engineering means deciding what information an agent should have available, how it can find that information, and when it should bring it into the current task. Basically, you are surrounding the agent with the context it needs when making a decision.

That usually means keeping the active context selective, which leads to another term called progressive disclosure. This means the agent needs the right information at the right time for the current decision. Loading the entire archive at once can confuse the agent and lead to context rot.

Files are one way to make that possible. Instructions (CLAUDE.md or AGENTS.md), examples, tools, conversation history, and saved corrections can also shape what the agent knows at a particular moment.

Inside this AI Maker project, I have a foundational folder containing the information my agent needs before helping with my work.

Three parts make a big difference:

1. My audience profile explains who I write for, what they already understand about AI, what they are trying to do, and where they keep getting stuck.

2. My creator style explains how I want the writing to feel, what standards matter to me, what evidence I need, and which writing habits make the work sound generic.

3. My operator profile explains how I think, how I make decisions, when I want the agent to challenge me, and how I prefer to work through an uncertain idea.

Other project files hold my current priorities, past posts, product direction, monetization framework, and the rules for different kinds of writing: LinkedIn, Substack Notes, sales email, welcome email, about page, etc.

So when I ask, “What do you think about this idea?” the agent has something real to judge it against.

It can consider whether the idea fits my readers. It can notice whether I have already covered something similar. It can challenge an angle that feels too generic. It can help me reason through how the thought connects to the larger work I am doing.

A writing agent may need access to your past archive, sentence-level style patterns, stories you can draw from, an idea inbox, topics you return to, and examples of work you would or would not publish.

A marketing agent may need information about the company or team, its positioning, audience, current goals, important metrics, campaign history, and approved claims.

The system also needs to know where that information lives and how to retrieve the relevant pieces. Some of it can remain stable; you don’t need to update it regularly. However, current goals, metrics, and priorities need to be maintained as the work changes over time.

I still make the final decision. I still disagree with the answer and change direction.

But what I find most effective with my current workflow is that I can simply continue the conversation instead of re-explaining everything every time I prompt it.

What Your System Should Store and What Today’s Prompt Should Carry

When the agent already knows everything about your work, what does the real job of the prompt become?

This is the simplest way I have started thinking about it.

Some information stays relatively stable:

• Who you are helping

• What you are trying to achieve

• How you judge good work

• What your voice sounds like

• Which examples represent your standard

• How a repeated task usually works

Other information changes every time:

• The new idea

• The material you want to work on

• A decision you need to make

• A special constraint

• The output you need today

The stable information can live in your project files. The system can retrieve the relevant parts. Your prompt can focus on the second list.

For example, some of you may know, I’m currently building an AI course, Agentic Academy. Since this course is an expansion of my business, it’s still part of the AI Maker project.

When I started building the course, my existing AI Maker project knew nothing about it.

The agent did not know what we were trying to create. It did not know the goal. It did not know which priorities mattered or how this new project related to the rest of my work.

So I had to explain everything in detail.

Honestly, that was tiring. I had become used to having short conversations inside my newsletter project, and suddenly I was back to preparing long instructions again.

But, once I saved the course goals, priorities, and materials inside my project folder, I no longer had to explain everything from scratch.

Now, if I want to sharpen the offer idea for my course, I can simply talk through it.

Share

Audit the Context You Keep Repeating

You do not need to create a huge AI system before you can reach this point.

Start with something you already do repeatedly, such as writing an article, researching a topic, reviewing a document, or preparing a campaign.

Then run this small audit:

1. Collect three recent prompts for the same task. Use requests you actually sent to your AI, including any follow-up messages you needed before the answer became useful.

2. Mark anything you explained more than once. Look for repeated information about your audience, goals, quality standards, preferred process, useful examples, or corrections you keep making.

3. Give each repeated detail a reusable home. Put facts and goals in a project brief, rules in your instructions, strong examples in an examples folder, repeated steps in a checklist or workflow, and useful corrections in the lesson file.

4. Run the task again with a shorter request. Include the new material, today’s goal, any changed constraints, and the output you need. Let your saved context provide the background it needs to execute your request.

5. Check whether it worked. Did the agent understand the task without another briefing? Did the result still meet your standards? Did it require less correction? If quality declined, identify what was missing and add that information to the appropriate source before trying again.

By the end of the audit, you should have one piece of reusable context, one shorter test prompt, and a clear comparison with your previous result.

If you want more practical steps on how to do this, you might want to read my beginner-friendly series on agentic workflows here:

1. The Complete Guide to Building Your First Agentic System (That You Can Actually Trust)

2. From Blank Folder to Working System: How to Set Up Any Project in Claude Code

3. How an Agent Harness Made My Claude Code Setup 10x More Reliable

4. The Complete Guide to the Context Folder That Changed How I Work With AI Agents

5. The Complete Guide to Build Your Personal AI Operating System With Claude Code

This is roughly how my newsletter setup grew. The first version only needed to turn an idea into a post in my style. Later, I needed idea capture, social content, monetization thinking, and product direction. As those needs appeared, the information around the system evolved too.

Subscribe now

So, here’s what you need to do after the audit: run the task, have a conversation, notice what the agent still doesn’t understand, and add what’s missing once the need becomes clear.

Do not overcomplicate it.

Start small and let the system evolve as your work evolves.

Eventually, you may notice that your own requests are changing. You stop preparing a complete instruction before every interaction. You start speaking more naturally, challenging the answer, and developing the work through conversation.

Your prompts get shorter because the system finally has more of the truth.

That is one of the clearest signs your AI system is actually getting better.

You can turn a spreadsheet into a dashboard, build a calculator to help you make better decisions, convert files between formats, create flashcards for something you are learning, or make a small landing page that other people can access without building a separate website first.

I have mostly used Artifacts when I wanted to turn an explanation or a set of data into something visual. This is how I built my weekly Google Analytics dashboard.

But what most people don’t know is that Anthropic recently released an addition to MCP (Model Context Protocol) and its connectors that makes Artifacts even more useful.

Now it can call an approved connector when the page loads, pull current information from an app, and refresh the view without rebuilding the whole page. Anthropic’s current documentation describes connector-backed Artifacts that load live data through each viewer’s own connected account.

That was the reason we revisited the feature in Episode 24 of One Shot Show.

built three versions of the same basic idea. The first was a dashboard made from a CSV file. The second pulled current data from his Substack account through a connector. The third took things further using Claude Code, where a comment on the dashboard could ask Claude to change the design.

By the end, the dashboard had become something you could refresh, question, and revise with other people.

I will walk through the same progression, beginning with the version almost anyone can try: a CSV you already understand.

GenAI Unplugged

Learn to build production-grade AI automation systems (setups, prompts, workflows, and templates) from someone who builds them at work by day and ships his own products by night.

By Dheeraj Sharma

Start With a CSV You Already Understand

Dheeraj started with the smallest useful version.

He had a six-row CSV showing where a newsletter’s subscribers came from during the previous 90 days. The columns included the channel, subscriber count, and percentage share.

He uploaded the file in a regular Claude chat and used a prompt along these lines:

Using the attached CSV of newsletter traffic sources, build a single-page dashboard Artifact. Show each channel, its subscriber count, and its percentage share. Make the page self-contained, with no external scripts or images.

Claude created a visual dashboard from the file. Once Dheeraj published it, he opened the link in a private Safari window where he was not signed in to Claude. The dashboard loaded and he could interact with the page.

That gives you a simple first build to copy:

1. Export a small dataset you already know.

2. Upload it to a new Claude chat.

3. Ask for a self-contained, single-page Artifact.

4. Check the numbers against the source file.

5. Publish it only after you have inspected the page and the conversation behind it.

If you want to replicate this, I’d suggest starting with data you’re already familiar with so you can look at the visualized dashboard and quickly judge whether it’s showing the right information and whether it’s actually useful for you.

But there’s one particular issue with this simple artifact.

Even though it looked complete, its data was frozen at the moment Dheeraj uploaded the CSV.

If the subscriber numbers changed tomorrow, the Artifact would still show the old file. Someone would need to upload a new CSV and tell Claude to update the page.

That is fine for a report you only need to read once. But it becomes limiting when the value of the report depends on current information.

That’s why we need to connect Artifact to external connectors so it can stay in sync with the latest data and information.

Build the Live Artifact Version in Cowork

For the second build, Dheeraj moved into Claude Cowork and connected a custom remote MCP server called Subflow AI. It gave Claude read access to his Substack data, including publication statistics, scheduled Notes, subscriber sources, top articles, and subscriptions.

His prompt was essentially:

Build me a live dashboard of my Substack publication using the Subflow AI connector. Show my publication statistics, scheduled Notes, subscriber sources, top articles, and subscriptions. Include a refresh control and show when the data was last updated.

Cowork loaded its Artifact capabilities, called the approved Substack tools, and built the dashboard. When Dheeraj opened it, the page showed current data from GenAI Unplugged. He could access the data live without having to ask Claude to refresh the page or update the data manually.

Anthropic describes Cowork live Artifacts as persistent HTML dashboards that can refresh from connected apps and local files.

This enables us to have live data that will be updated regularly.

Choose the Right Place to Build Your Artifact

At first, I thought Artifact was just a simple feature I could use across all Claude products—Chat, Cowork, and Code. But it turns out there are some limitations you need to understand, depending on which product you’re using to build your Artifact.

1. Claude Chat

Use it first for a report, calculator, visual, or dashboard built from an uploaded file. The result is usually a snapshot, and it can’t connect to external apps. Free, Pro, and Max users can publish public links, while Team and Enterprise accounts can share within their organization.

2. Claude Cowork

Use it for a personal dashboard that refreshes from connected apps or local files. Pro and Max live Artifacts stay private. Team and Enterprise can share them inside the organization.

3. Claude Code

Use it for a live page connected to an active dashboard that needs code-level revision and team feedback. Remember that artifact pages using live connectors cannot be shared via public link. Internal comments and collaborative editing require a Team or Enterprise plan.

Subscribe now

How Sharing Claude Artifacts Actually Works

One of the coolest parts of Claude Artifacts is that you can send someone a link to a dashboard, calculator, visual report, or small app and let them interact with what you built.

We saw the simplest version during the first demo. Dheeraj published the static CSV dashboard, copied its link, and opened it in a private Safari window where he was not signed in to Claude. The page still loaded and worked.

Once an Artifact uses Claude or a connector, the sharing rules change. Here are the details I would check before sending the link for other people to access.

A Published Chat Artifact Can Be Public

On Claude Free, Pro, and Max plans, you can publish a Chat Artifact and give anyone the public link. Anthropic’s publishing guide says people can view and use its basic functions without creating a Claude account.

If the Artifact uses Claude for an AI-powered feature, the viewer needs to sign in. The clearest example of this is Dheeraj’s compliment bot, where the Artifact is an AI bot that connects to Claude as the underlying model. If you share this type of Artifact with other people, it will consume their tokens instead of the tokens of the person who built it.

Team and Enterprise accounts use internal sharing instead. Viewers need to sign in through the same organization before they can open the Artifact.

Live Data Comes With Tighter Sharing Rules

Cowork live Artifacts stay private on Pro and Max. Team and Enterprise users can share them inside their organization, while external public links are unavailable.

Claude Code Artifacts can also be shared, but a page that calls a connector cannot be published to the open internet. On Team and Enterprise, you can share that connector-backed page with people inside your organization. A regular Claude Code Artifact without a connector can support a public link, as long as it isn’t attached to a connector.

This is what happened when Dheeraj tried to share his live Substack dashboard. The public-link option was disabled because the page called his Substack connector.

Each Viewer Brings Their Own Connector and Data

When someone opens a shared connector-backed Artifact, Claude calls that person’s connector and respects their permissions. The creator’s login and data do not travel with the page.

If Dheeraj and I opened the same Substack dashboard, he could see GenAI Unplugged while I could see AI Maker, assuming we had each connected the same tool. We would share the dashboard’s interface and logic while the data inside it would come from our individual accounts.

A viewer who has not connected the required service will see an empty or failed live section.

Turn Comments Into Dashboard Revisions

The final demonstration was the part I did not expect.

Dheeraj opened the Claude Code version of the dashboard and added a comment requesting a visual change. The comment reached the Claude Code session that had published the Artifact. Claude updated the chart, replied to the thread, and marked the request as resolved.

I could immediately see the team use case. Someone reviewing a report can point to the exact visual, ask a question, or request a change without explaining which chart they mean in a separate message.

The current implementation has several conditions:

• Comments are available on Artifacts shared inside a Team or Enterprise organization.

• Reading comment threads requires Claude Code 2.1.221 or later.

• Automatic replies and edits require Claude Code 2.1.228 or later.

• The publishing Claude Code session must still be running to react immediately.

• Your permission mode decides whether Claude proceeds, asks for approval, or waits until you leave plan mode.

The Smallest Dashboard I Would Build First

If you want to build artifact, start with one decision you already make from a recurring file.

Maybe you export newsletter traffic each week, download a project-status CSV, or receive a simple sales report. Choose a file you already inspect manually and build a static dashboard from it.

Your first version only needs to answer three questions:

• What changed?

• What needs attention?

• Which source row or category explains it?

Use that static version for awhile. Correct the labels, remove any chart you ignore, and make sure the dashboard helps you make the real decision faster.

Then connect live data if you want the artifact to reflect real data that you can monitor regularly.

Show Details

Show: One Shot Show

Episode: 24

Topic: Building static, live, and collaborative dashboards with Claude Artifacts

Hosts: Wyndo and Dheeraj Sharma

Live schedule: Wednesdays at 10:00 AM ET on Substack

Timestamps

• 00:00: Episode 24 introduction and the promise of live Claude Artifacts

• 00:04: What an Artifact is and why sharing a visual beats sending raw data

• 00:09: Wyndo on the shift from Markdown output to interactive visual pages

• 00:11: Artifact examples, from file converters to learning tools

• 00:13: AI-powered Artifacts and live connectors

• 00:15: The differences between Chat, Cowork, and Claude Code Artifacts

• 00:19: Enabling code execution and connector capabilities

• 00:20: When to use an Artifact instead of hosting an HTML page

• 00:25: Who pays for AI usage when an Artifact is shared

• 00:27: Sharing and embedding an AI-powered chatbot Artifact

• 00:31: The privacy risk when files from the original conversation are shared

• 00:32: Building the first dashboard from a static CSV

• 00:35: Connecting Cowork to Dheeraj’s Substack MCP

• 00:37: Why the first prompt returned an HTML page

• 00:39: Publishing and testing the static dashboard in a private browser

• 00:43: Rebuilding the live dashboard through Claude Code

• 00:46: Exploring the live Substack dashboard

• 00:49: Why connector-backed dashboards use each viewer’s account

• 00:50: Adding comments to an Artifact

• 00:55: Anup asks how automatic comment replies work

• 00:56: Dheeraj explains what he had not fully tested

• 00:58: Claude changes the dashboard from a comment and resolves the thread

• 01:02: When Dheeraj still uses n8n for deterministic automation

• 01:03: Wyndo connects the discussion to Claude Routines and external automation tools

• 01:05: Next episode schedule

Resources Mentioned

• Claude Artifacts: Shareable documents, code, visuals, and interactive single-page tools created inside Claude. The session covered static, AI-powered, live, and Claude Code versions. Pricing was not discussed.

• Claude Cowork live Artifacts: Desktop-only dashboards that can refresh from connected apps and local files. Dheeraj used Cowork for the live Substack build. Available on paid Claude plans.

• Claude Code Artifacts: Interactive pages published from a Claude Code session. The demonstration used one for connector-backed data and comment-driven revisions.

• Claude Chat, Claude Desktop, and Claude Mobile: The regular Claude surfaces discussed when comparing where Artifacts can be created and opened. Live Cowork Artifacts remain desktop-only.

• Artifact capabilities and Artifact design Skills: Built-in Claude Skills loaded during the Cowork and Claude Code demonstrations to create the dashboards.

• MCP and Claude connectors: Connections that let Claude retrieve data or take actions in other services. The live dashboards depended on approved connector tools.

• Subflow AI and the custom Substack MCP: Dheeraj’s remote connector for reading publication statistics, Notes, articles, subscribers, and subscriptions from Substack. Pricing was not discussed.

• CSV traffic-source file: The six-row sample used to build the first static dashboard. It contained channel, subscriber count, and percentage-share data.

• HTML, CSS, and inline JavaScript: The web technologies behind a self-contained interactive Artifact.

• Markdown, SVG, YAML, JSON, and XML: File and data formats mentioned while discussing documents, diagrams, and conversion tools people can build as Artifacts.

• Five Whys analysis: The root-cause exercise Dheeraj used as an example of an AI-powered Artifact that interviews the user.

• Compliment bot: The simple AI-powered Artifact used to demonstrate that a shared page can call Claude and charge usage to the signed-in viewer’s limits.

• iFrame embed code: The method shown for embedding a published, compatible Artifact inside another website. Dheeraj recommended static, self-contained tools for the cleanest embedded experience.

• Visual Studio Code: The editor Dheeraj opened while inspecting the CSV and starting the Claude Code build.

If you have been following AI Maker for awhile, you know that most of my content is about building AI agents in Claude Code. And if you have applied them, you probably already have a project folder that knows how you work.

Maybe you have a CLAUDE.md, an AGENTS.md, a context folder, a few skills, and connectors to the apps you use every day. Claude can read your source material, follow your rules, research a topic, update Notion, read your meeting transcription on Granola/Fathom, and prepare drafts in your voice.

That setup can do a lot.

Mine can help me plan newsletter posts, research ideas, repurpose my published articles, review form responses on my consulting website, build LinkedIn carousels, and work across the tools that run my business. I also have another project folder that essentially works as my Chief of Staff and knows my priorities, plus a second brain that stores any interesting information I consume across the internet and in real life.

But every one of those workflows still had the same starting point: me.

I had to sit in front of my laptop, open Claude Code, enter the project, and tell it what to do. Even when the instructions and tools were already there, the work waited until I showed up.

That is fine when I am actively writing or making a decision with Claude. But the limitation shows up when I need my AI to act on its own—to automatically start a task at a specific time, or to kick off a workflow after something happens in another app. And I want all of that to happen while I’m away from my laptop.

For example:

• A new consulting inquiry shouldn’t sit untouched until I remember to check my Google Sheets form.

• A daily AI news update from the newsletters I subscribe to shouldn’t have to wait until I open my laptop before it arrives in my inbox.

• A content research task on my Notion calendar shouldn’t wait for me to tell my agent to research it; I should have a process to deploy agents to complete my tasks automatically.

And sometimes I am on my phone, walking somewhere, with no intention of opening my laptop just to start a task Claude already knows how to complete.

This is the part Claude Code Routines opens up.

Your existing Claude project can now run in the cloud

I think Claude Code Routines is an underrated feature that not many people are talking about, given the huge possibilities it unlocks.

We all think of it as a way to schedule tasks, but trust me, it’s much bigger than that.

Anthropic describes a Routine as a saved Claude Code configuration made from a prompt, one or more repositories, and a set of connectors. It runs through cloud infrastructure, so it can keep working while your laptop is closed.

So, of course, the obvious benefit is that the task no longer depends on my computer remaining available. The more important benefit for me is that I do not have to rebuild the workflow on other agent platform.

The research methods, writing instructions, examples, skills, source files, and tools I use already live inside my Claude Code projects. Routines give me a way to run selected parts of those projects in the cloud.

That is also part of a broader shift I have been watching in the developer community.

Boris Cherny, who works on Claude Code at Anthropic, recently recommended running Claude Code in the cloud for autonomous tasks that may take hours or days, specifically so you can close your laptop. Vincent van der Meulen, who says he now works almost entirely with cloud agents, argues that more engineers should start there because it changes how they can delegate work. He also admits that adoption remains limited and setting up cloud environments is still difficult.

Lately, if you’ve been using Claude Code a lot, you may have noticed it increasingly nudges you to run your projects in a cloud environment.

For most people reading this, you are not developers—and neither am I. But there are a lot of similarities between what developers do and what we do in our typical knowledge work: research, writing, planning, meeting preparation, and content production. But, the issue is all of that work ends up waiting when the agent only runs after you open your computer.

So the practical starting point is this: how do we make Claude Code project also work in the cloud, so our work isn’t bounded by waiting to open the laptop?

That’s where Routines comes in.

How Claude Routines can help automate your work

So far, most conversations about Routines seem to stop at scheduling. You create a task that runs every morning, every weekday, or once a week. That alone is useful.

For example, you could ask Claude to check your calendar and recent email every weekday morning, compare them with your current project priorities, and send you a short briefing before you sit down to work.

That solves the first limitation: you no longer have to prompt it by hand to get this task done.

But there’s still a catch: you still need to open your computer, because the agents are running locally.

By running Routines in the cloud, you remove this problem because the agent can keep doing tasks without your computer always needing to be on.

These are the kinds of things the scheduling feature unlocks for us.

But some tasks should begin because something happened, rather than at 9:00 every morning.

A topic moved into research. A new post was published. Someone submitted a form. You sent a request from your phone.

That is what the API trigger adds.

Scheduling tells Claude to start working at a planned time. The API trigger lets an outside event tell Claude to start working now.

Every API-enabled Routine gets an HTTP endpoint. An authenticated request to that endpoint starts a fresh Claude Code session on demand. That request can come from another app, an automation platform, or a Shortcut on your phone.

There is an important limitation, though. The endpoint does not watch Notion, an RSS feed, or a form for you. Something else still has to notice the event and send the request in the format Claude expects.

Sometimes the source app can make that request directly. Other times you need Make, Zapier, or n8n to receive the event, reshape the information, and relay it into the Routine.

Change one label on Notion, start a full research workflow

Here is one of the clearest examples from my own setup.

I manage my content calendar in Notion. Each potential post has a topic, an angle, a status, and whatever source material I have collected so far.

When I decide a topic deserves more investigation, I change its status to Research.

That one change can start the rest of the workflow:

1. Notion sends the selected topic fields to Make.

2. Make reshapes that information and calls my Claude Routine.

3. Claude reads the incoming request and the instructions already inside my project.

4. It uses Tavily to research the topic and gather current sources.

5. It organizes the findings into a research brief.

6. It updates the correct item in my Notion content calendar.

7. It emails me a summary with the result.

Notion status change
        ↓
Make routes the topic
        ↓
Routine API trigger
        ↓
Claude project + Tavily research
        ↓
Notion update + email summary

By having this automation, I no longer need to open Claude Code and prompt it manually.

All of this is done simply by changing the status label in Notion.

Now you might be wondering why Make is still sitting in the middle of this workflow.

Let me explain.

Subscribe now

Make still has a job in this setup

I used to build much more of my automation inside Make.

At the time, it gave me what I needed. Make could watch another app, start a workflow when something happened, move information between tools, and keep running without my laptop being open. Claude was one step inside that chain, so it made sense for Make to own most of the process.

But that workflow started to become irrelevant when I began using Claude Code more and more.

Moving the same job into a separate automation means passing all of that material into another AI step, which complicates my workflow because I now have two workflows to maintain between Claude Code and AI automation platforms such as Make.com.

This is why I’ve been using Make, or similar apps such as Zapier and n8n, less. Routines let me keep the research, interpretation, and production inside the Claude project that already understands how I work.

The Routine can also use selected connectors to read and write across apps such as Notion, Gmail, Google Calendar, and Google Docs. Once the run begins, Claude can coordinate those tools using the instructions in my project.

But there’s one particular limitation in Routines in how it can be triggered to run.

The current Routine API is a narrow entry point. It starts a session after receiving the correct authenticated request. It does not monitor a Substack RSS feed, detect a Notion change, filter an event, or reshape an arbitrary webhook payload.

That is where Make still helps me. It can watch for the event, filter it, reshape the information, log what happened, and pass a clean request into Claude.

Make catches and delivers the event. Claude uses the project to complete the work through Routines.

If what I just said is confusing, don’t worry—we’ll get into it later in the post. It will all make sense once you’ve seen the full tutorial.

How to think about building a useful Routine

Before turning a workflow into a Routine, we need to think about how to create a useful Routine that can help you automate your work:

1. Trigger: When should the work begin?

Choose one deliberate event or one predictable time.

In my case, whenever I change a content status to Research in Notion, it triggers the entire research workflow.

Or you can also create a trigger whenever there’s a new RSS feed you want to monitor, which then starts the workflow.

2. Input: What starts the request?

The input is the new information Claude receives when the Routine begins. It could be a topic, URL, form response on your website, database ID on Notion, meeting transcript on Granola/Fathom, or note from your phone.

Send only what the Routine needs to identify and complete the job. A form submission may include the person’s name, company, stated problem, and response ID. A content request may only need the Notion database ID because Claude can retrieve the remaining fields from the database.

3. Context: Where should Claude look for the rest?

The input tells Claude what just happened. The context helps Claude understand what to do about it.

Some of that context may already live in the selected repository: your instructions, source files, examples, research rules, or Skills. The Routine prompt should tell Claude which files to inspect and which Skill to run.

Other context may live in a connected app. If the input is a Notion database ID, tell Claude which content calendar to open and which fields matter. If the task begins from a Granola or Fathom transcript, tell Claude where to retrieve the relevant transcript and what information to extract from it.

4. Process: What should Claude complete?

Define the actual sequence, not only the outcome.

For a research Routine, Claude might read the content-calendar record, inspect the research instructions in the project, run the relevant Skill, use Tavily to gather current sources, separate verified findings from open questions, and compile the result.

The task should have a visible finish line that you can see and assess.

5. Output: Where should the result go?

Choose one destination you already check: Notion, email, Google Docs, Google Slides, or a file in the project.

Be specific about the write target: “Update the Research Summary field on this Notion page and email me the link” is one way to do it.

The output should be easy to inspect. If you cannot quickly tell whether the task worked, the Routine will create more mental overhead than it removes.

6. Human review: What decision still belongs to you?

Claude can prepare research, summarize information, draft a reply, organize survey findings, or create a presentation.

For example, a consulting form can trigger a Routine that researches the person and company, compares the inquiry with the services you offer, and prepares a briefing with a draft reply. The Routine can do the preparation while you are away from your laptop.

You still decide whether the lead is a fit, what you can offer, and whether the reply should be sent. Publishing a post, contacting a lead, approving a proposal, or acting on a sensitive recommendation should still come back to you.

The goal is to remove the repeated preparation while keeping human judgment where it matters.

Five Claude Code Routines workflows I want to show you

Here are five Routines workflows we’re going to cover today that work across any type of job you have, whether you’re a creator, knowledge worker, consultant, or entrepreneur:

1. Scheduled morning briefing: Claude reads your calendar, recent email, and active project priorities, then sends you a plan for the day.

2. Notion research trigger: Change a content-calendar status and receive a sourced research brief, a Notion update, and an email summary.

3. Automatic post repurposing: Publish on Substack, let Make detect the RSS item, and have Claude prepare platform-specific drafts for review.

4. Consulting inquiry research: Use a form submission to prepare a briefing on the person and company, along with a draft reply you can approve.

5. An iPhone Shortcut for on-demand work: Send a link, note, or voice transcription from your phone and start one of your defined workflows while you are away from the laptop.

Use these as reference points. Your version will depend on where your files live, which apps you use, what should trigger the work, and which decisions still need your review.

The rest of this guide shows how these workflows operate, where Make sits in the middle, and the configurations I use to pass events into Claude. Use the details to understand the pattern and decide what fits your own setup.

🚨 Before you try this

You should already have a Claude Code project you use for real work. If you are still setting that up, start with reading some of my posts here:

1. From Blank Folder to Working System: How to Set Up Any Project in Claude Code

2. How an Agent Harness Made My Claude Code Setup 10x More Reliable

3. The Complete Guide to the Context Folder That Changed How I Work With AI Agents

For the project-based workflows in this guide, your Claude Code project also needs to be in a GitHub repository that Claude can access. Each Cloud Routine clones the selected repository when a run starts, beginning from its default branch. It cannot see files or changes that still exist only on your laptop.

Before creating the Routine, commit and push the instructions, Skills, and source files it needs. Keep API keys, credentials, and sensitive local-only files out of the repository. You will also need to connect the repository to Claude Code on the web through the Claude GitHub App. I will show you the short connection and verification process before we configure the first workflow.

Some outside triggers have their own requirements. That’s why you’ll need a Make, Zapier, or n8n subscription to run all these workflows. In this guide, I’m only going to show you how to do it with Make.

By the end, you will understand how my Claude Code projects start selected work while I am away from my laptop, respond to deliberate events in other apps, and return something useful for me to review. You can then decide which parts make sense for your own work.

Let me show you how these workflows work.

Move your Claude Code project into the cloud

Every workflow in this guide begins with the Claude Code project you already use on your laptop.

That project may contain your CLAUDE.md, Skills, source material, examples, and the instructions Claude follows when it helps with your work. We do not need to rebuild any of that. We need to make the same project available to Claude Code in the cloud.

GitHub is the bridge.

Each Cloud Routine clones a GitHub repository when a run begins. It starts from the repository’s default branch, which means the Routine can only see files that have been committed and pushed. Anything that still exists only inside the folder on your laptop remains unavailable to the cloud run.

We will set this up once. Afterward, the same cloud project can support the Notion research workflow, scheduled briefings, post repurposing, consulting inquiry research, survey analysis, and requests from your phone.

Step 1: Push your local project to GitHub

Before Claude can open the project in the cloud, the project needs to exist in a GitHub repository.

If the project is already connected to GitHub, push the latest version. If it only exists on your laptop, create a private GitHub repository and connect the local folder to it.

You can ask Claude Code to help:

Help me push this local Claude Code project to GitHub.

Before you push anything:
- make sure the project instructions, Skills, and source folders are included
- check that .env files, API keys, credentials, tokens, and private files are excluded
- show me the files you plan to commit

Wait for my approval before committing or pushing.

If this is your first time, there are plenty of tutorials out there on YouTube that can help you create a GitHub account and push your project folder to GitHub.

Step 2: Connect GitHub to Claude Code

Next, follow Anthropic’s GitHub connection quickstart.

The process is short:

1. Visit Claude Code on the web.

2. Choose the option to connect GitHub.

3. Install the Claude GitHub App.

4. Give Claude access to the repository you just pushed.

5. Confirm the default cloud environment.

You only need to do this once for the GitHub account. If you add another project later, you can update the GitHub App’s repository access.

Step 3: Start the project in the cloud

Open Claude Code Desktop and start a new session.

In the new-session screen, open the Claude menu and choose the cloud option. Claude will show the GitHub repositories available to your account. Select the project you just pushed, choose its default branch, and start the session.

Ask Claude one simple question:

Read this project and tell me which instructions, Skills, and main source folders you can see.

If the expected files appear, the local project is now available to Claude in the cloud. If the repository does not appear in the selector, check that the Claude GitHub App has access to it.

That is enough to move forward. We have the same project, available locally when we want to work closely with Claude and available in the cloud when a Routine needs to run without the laptop.

Step 4: Understand the five parts of a Cloud Routine

With the project available in the cloud, we can turn it into a Routine.

Read more

The short answer was yes. I still use Claude Code, and a lot of my existing systems are already set up there. I also use Fable a lot for my most complex work.

But over the last few weeks, I have found myself opening ChatGPT Work more often.

Part of that came down to the output. In my own newsletter files and project setup, ChatGPT has sometimes understood the work and returned a more accurate analysis than Claude Code. But this is just my personal experience; it might be different for most of you.

ChatGPT’s UI/UX on desktop also contributed just as much. Their app is simpler to use compared to the Claude desktop app. OpenAI has added so many features to the ChatGPT desktop app that it now handles work I used to spread across Claude Code, a browser, connected apps, design tools, and several separate chats.

That became the focus of this episode. Instead of using slides, I opened my actual ChatGPT setup and walked through 10 features that have changed how I use it for growing AI Maker and Agentic Academy.

Here are 10 of the most important features in ChatGPT Work that you should use to 10x your productivity:

1. Plugins Put Apps, Skills, and Tools in One Place

The first feature was also the most confusing to explain.

In ChatGPT, a plugin can be a connection to an app such as Gmail or Google Drive. It can also be a larger package containing Skills, connectors, and MCP tools for a particular kind of work such as Product Design, Sales, Data Analytics, Investment Banking, etc.

Dheeraj noticed the confusion immediately. A Gmail plugin looked similar to a connector in Claude, while the Data Analytics plugin looked more like a complete package for an analyst. It included the connected services (Slack, Google Drive, BigQuery, Mixpanel, Amplitude, etc.) and the skills needed for several related data tasks such as building dashboards, creating reports, generating data context, and much more.

OpenAI’s current plugin documentation confirms that plugins can bundle Skills, connectors, MCP servers, browser capabilities, hooks, and scheduled task templates. Plugins in OpenAI might look confusing, but as you use them more, you’ll start to notice the main differences between them and connectors and skills.

I showed two examples from my account:

• Data Analytics packages several analysis capabilities together.

• Creative Production includes Skills for intake and production, along with the tools those Skills need.

I also showed my AI News Intel Skill. It opens the AI label in Gmail, reads the newsletters I subscribe to, and turns the useful updates into Markdown files. This skill has been helpful for keeping me updated on what’s happening in AI every week.

I also shared advice to ensure you only connect apps that you use on a daily basis. Otherwise, you’ll consume more tokens as you connect more apps in your ChatGPT chat session.

2. I Can Import My Claude Code Setup Instead of Rebuilding It

This feature removed the biggest practical reason to stay inside one agent app, for example: Claude Code.

Previously, in my monthly Q&A, I also talked about how you can import Claude Code settings into the ChatGPT desktop app so your workflow becomes model-agnostic.

Here’s how to do it:

Under Settings > Import, ChatGPT can now import supported material from Claude Code, Claude Cowork, and Cursor. OpenAI’s import guide says that can include instruction files, settings, Skills, plugins, project folders, recent chats, MCP configuration, hooks, slash commands, memories, and subagents.

That means I can bring an existing project into ChatGPT without manually recreating every command, skills, and connection.

There is also an automatic update option. When I change any files and materials in the original Claude Code setup, ChatGPT can pull the updated version into the imported project.

So, how does this easy importing process impact how I work across Claude Code and ChatGPT?

Well, it changes the migration decision.

The imported project keeps the same settings and can run in the same folder, so I can move between Claude Code and ChatGPT without rebuilding my workflow. Claude Code can generate an output that I review in ChatGPT, and ChatGPT can produce work that I continue or review in Claude Code. Now that the project folder works with both systems, I can compare them on the same work without sacrificing the workflow I already have.

In fact, using the same concept, I took it a step further and built a multi‑model AI agent workflow, which you can read more about below:

3. The Built-In Browser Can Run a Real Signed-In Workflow

I bet these features still feel underrated, and not many people know how to use them well.

The ChatGPT desktop app has a built-in browser that both you and the agent can see. It uses its own browser profile, separate from your normal browser. Once you sign in inside that profile, the session can remain available for later tasks.

I used my Substack account as the example.

I have a Skill that opens my profile, finds my latest five Substack Notes, enters each Note’s analytics, collects the performance numbers, and records them in Google Sheets.

During the live run, ChatGPT opened my profile, moved through several Notes, opened their analytics, and reached the Google Sheet. It moved quickly enough that I could not follow every click.

I built the Skill using Record & Replay. R&R is a feature in ChatGPT that activates your computer’s screen recording, and once you stop the recording, ChatGPT watches it and turns whatever process you demo into a Skill that you can trigger to execute repetitive tasks.

I recorded myself completing the job manually: open Substack, select a Note, copy the analytics, and paste the result into the sheet. ChatGPT inspected the recording and created a reusable Skill from the demonstrated process.

Dheeraj added the caveat I would keep in the post: the generated Skill may give you a 70 to 80 percent starting point. You still need to inspect its instructions, add missing preferences, and test whether it finish the work as you expect.

One thing to keep in mind is that Browser work can also use a lot of credits, because the agent is repeatedly reading screens, opening pages, and deciding what to do next.

I would encourage you to use the R&R Skill for repetitive tasks that don’t require complex work or navigating multiple tabs in the browser. Start with simpler things such as scheduling posts on social media, doing competitive research, or any other tasks you currently do manually.

Then use the Automation feature to schedule them to run every day or week, depending on your needs.

Subscribe now

4. Sites Can Build and Host a Working Landing Page

Next, I asked @Sites to build a lead-magnet page for AI Maker.

I’d be honest, my prompt was vague. I asked for a page that captured an email address in exchange for five methods to audit an AI agent system. I gave ChatGPT very little design direction.

The first version was better than I expected. It produced a complete landing page and used the official Substack signup form, so an email entered there could go into my publication’s subscriber system.

ChatGPT Sites can create, host, refine, and share websites and lightweight web apps. You can return to the Site, edit it through the chat, and manage who can visit it.

The live discussion exposed how quickly this feature is changing. I said the page would stay on a chatgpt.site address and that a custom domain would require moving it to Vercel. OpenAI’s current documentation now says custom domains can be connected where the feature is available. Availability still depends on the plan, region, and account settings.

I also opened the page locally in ChatGPT’s browser and used its annotation controls. You can select an element, request a copy change, or adjust properties such as color, spacing, and font before asking the agent to update the underlying page.

If you want to build websites live and let other people access them as well, then Sites is a feature you should explore further.

If you want to see the Claude Code Desktop version of this, check out this video.

5. Parallel Chats Let Me Split One Large Request Into Smaller Jobs (Threadmaxxing)

I think of the fifth feature as thread maxing.

I gave ChatGPT one request: find the latest AI news from three different places. I asked one chat to search my email, another to search the web, and another to check Reddit.

ChatGPT opened separate chats in the sidebar and started the three lines of work at the same time.

This is useful when the jobs are genuinely independent. Researching three sources, reviewing several files, or asking different chats to produce separate parts of a deliverable can save a lot of waiting.

I would be more careful when several chats can edit the same file or connected source. OpenAI’s long-running work guidance recommends keeping each chat independent and avoiding concurrent access to the same files unless the work has been isolated.

For those of you who love deploying 5–10 agents at once, you’re going to love this feature. You no longer need to prompt them one at a time; you can do it all inside a single chat that deploys multiple agents at once.

I think this feature particularly attracts people who care a lot about the number of productive outputs they generate.

6. Ask for More Details Opens a Focused Side Investigation

While reviewing an analysis of my subscriber retention and pricing, I highlighted one recommendation and selected Ask for more details.

ChatGPT opened a separate conversation around that selection and explained the reasoning behind the recommendation. I could question the assumption without burying the original analysis under a long detour.

Once I was satisfied, I could bring the result back into the main task.

This is a small interface feature, but it matches how I actually think through a decision. I often want to challenge one number, test one assumption, or understand one sentence before I continue with the main work.

Previously, I would ask every follow-up in the original conversation and eventually make the chat harder to navigate. This feature helps by adding a focused side investigation that allows me to explore multiple directions while keeping the main conversation in place and unaffected.

7. Earlier Chats Can Become Source Material for the Next Task

ChatGPT also lets me bring an earlier conversation into a new one.

During the episode, I searched for a previous chat, dragged it into the current task, and used it as additional context.

This becomes useful when you want to continue a conversation after hitting the context window limit.

I might analyze a set of welcome emails in one chat, decide what should change in another, and then bring both into a third chat that writes the revised version. The new task can use the earlier work without requiring me to copy the past chat manually.

This feature completely removes my anxiety about hitting a context window where I have to explain the previous chat all over again, which can be time-consuming. With this, I can simply use my past chats as additional context in my current AI conversation.

8. I Can Preview and Annotate Presentations and Data Files

ChatGPT Work desktop app can preview presentations, documents, spreadsheets, PDFs, and supported HTML files beside the chat. OpenAI’s file guidance also describes annotations for focused revisions.

I opened a PowerPoint file during the session and showed how I could inspect the slides without leaving ChatGPT. If a label, layout, or chart needed work, I could point to that exact part of the preview and ask the agent to change it.

I also showed an analysis of my subscriber value at different prices. ChatGPT had turned the data into an interactive visual where I could change the chart type, group the data, or select different axes.

The valuable part for me is the review loop. Generating a file is easy. Being able to see the output, identify one weak area, and request a narrow revision makes the generated file much more usable.

9. Voice Can Direct Work While I Watch It Happen

I have been using ChatGPT Voice more often because it can coordinate actual tasks inside ChatGPT Work and Codex.

To be honest, ChatGPT Voice is the closer thing for having Jarvis in real life. I stand by this!

ChatGPT Voice can start work, check active chats, and redirect a task while you continue talking. On macOS, it can also use screen context when you allow it.

For the live demonstration, I connected ChatGPT to Paper, a design tool built on an HTML and CSS canvas. Paper’s MCP server allows an agent to read and write design files.

I asked ChatGPT by voice to create three to five hero-section variations for a lead-magnet page. As I talked, the agent worked inside Paper and the variations began appearing on the canvas.

This is also how I developed the new AI Maker logo and some of my LinkedIn carousel designs. I can look at the output, say which direction I prefer, and ask for another variation without translating every reaction into a formal written prompt.

10. Computer Use Can Operate Apps Without a Better Connection

The last demonstration was intentionally simple.

I enabled the Computer Use plugin, allowed ChatGPT to access the relevant app on my Mac, and asked it to open Spotify and play a running playlist. ChatGPT opened the app, inspected the interface, and started navigating toward the requested playlist.

Computer Use allows ChatGPT Work or Codex to see and operate approved graphical apps on macOS and Windows. It is meant for tasks that depend on a visual interface in your computer.

One of audiences asked which computer-use agent was best without making this workflow too expensive. Dheeraj raised an even more useful question: which general-purpose jobs are actually worth giving to computer use?

I am still figuring that out.

For Spotify, a direct integration would usually be cleaner if one were available. Computer Use becomes more interesting when I need to change a setting, test an interface, inspect a desktop-only source, or complete a short process across several apps.

Share

Why These Features Changed My Default App

In the video, you can feel my energy and how excited I was explaining and showing you how I use ChatGPT Work.

But none of this means I’ve abandoned Claude Code.

My Claude Code setup already works. I still use its Max plan, and I can route some of that work to other models when needed.

Over time, I find myself using ChatGPT more and more compared to Claude Code. And the reason is simple: I love ChatGPT’s output quality and how it will execute the tasks I demand from start to finish. ChatGPT has been giving me better results on some of my project analysis and brainstorming. Then the desktop app adds the browser, imports, plugins, parallel chats, file previews, voice, Sites, and computer control around that work.

Overall, the ChatGPT app is also easier to use and much more intuitive compared to Claude Code. The Claude Code app is too cluttered with too many features inside. I like how ChatGPT makes things way simpler to use.

If you already have a mature Claude Code setup, I would not move everything at once. Import one project and run the same real task through both systems. Compare the result, the corrections required, the credits used, and which app makes the review easier.

That is how I ended up using ChatGPT more. I tested it against work I already understood, and more of those tasks gradually stayed there.

Well, that’s it for today.

I hope you enjoy this post :)

Show Details

Show: One Shot Show

Episode: 23

Topic: 10 ChatGPT Work Features You Must Use

Hosts: Wyndo and Dheeraj Sharma

Live schedule: Wednesdays at 10:00 AM ET on Substack

Timestamps

• 00:01: Episode 23 introduction and why the show turned to ChatGPT Work

• 00:05: Preview of the ten features

• 00:10: Inside the ChatGPT desktop app

• 00:11: Plugins, connected apps, and Skills

• 00:16: Why Wyndo recommends connecting only the apps you use

• 00:18: Importing Claude Code, Claude Cowork, and Cursor setups

• 00:21: Dheeraj asks whether import synchronization works both ways

• 00:23: Opening the built-in browser

• 00:24: Logging Substack Notes analytics into Google Sheets

• 00:28: Turning a screen recording into a reusable Skill

• 00:30: Des asks about browser credit usage

• 00:31: Building a lead-magnet page with Sites

• 00:33: Hosting, domains, and the comparison with artifacts

• 00:34: Editing a local page through browser annotations

• 00:36: Reviewing subscriber-value analysis and interactive charts

• 00:38: Running three research chats in parallel

• 00:40: Asking for more detail in a separate conversation

• 00:42: Bringing an earlier chat into a new task

• 00:45: Previewing and annotating a presentation

• 00:46: Introducing ChatGPT Voice and Paper

• 00:49: Creating landing-page variations by voice

• 00:51: Paper pricing and the open-source question

• 00:53: Setting up Computer Use and opening Spotify

• 00:55: Hari and Dheeraj question the best computer-use cases

• 00:56: Does Wyndo still use Claude Code?

• 00:58: The personal tipping point toward ChatGPT Work

• 00:59: Wyndo’s early take on Grok Bot

• 01:02: ChatGPT and Claude subscription choices

Resources Mentioned

• ChatGPT Work: OpenAI’s agent mode for longer tasks and finished deliverables. Wyndo used it throughout the episode for project work, browsing, analysis, file creation, and connected apps.

• ChatGPT desktop app: The combined desktop application containing Chat, Work, and Codex. The browser, local projects, previews, voice, and Computer Use demonstrations took place there.

• Codex: OpenAI’s agent experience for local projects and software work. Wyndo and Dheeraj compared it with Claude Code and referenced a previous backup-harness episode.

• Claude Code: Anthropic’s agent interface and the source of Wyndo’s existing projects. Wyndo still uses it, while shifting more day-to-day work into ChatGPT.

• Claude Cowork: One of the agent environments ChatGPT can import from. No pricing was discussed.

• Claude Desktop: Mentioned when comparing Anthropic’s desktop features and connected tools with ChatGPT. No pricing was discussed.

• Claude in Chrome: Anthropic’s browser integration, mentioned during the discussion about browser credit use and visual web tasks.

• Claude Opus 5: The Claude model Wyndo discussed when explaining why some users were testing alternatives. His comments were personal observations, rather than a general performance comparison.

• Cursor: One of the supported import sources in the ChatGPT desktop app. It also appeared later in the Grok Bot discussion.

• Plugins: Packages that can contain Skills, connectors, MCP servers, browser capabilities, hooks, and scheduled task templates.

• Skills: Reusable instructions for a specific workflow. Wyndo demonstrated AI News Intel and his Substack Notes analytics logger.

• MCP: A protocol used to connect agents with external tools and data. It appeared in the plugin explanation, the Claude import flow, and the Paper demonstration.

• AGENTS.md: The project instruction file ChatGPT reads after importing or opening a compatible local project.

• CLAUDE.md: Claude Code’s project instruction file, discussed while Dheeraj and Wyndo compared how the two systems read project guidance.

• AI News Intel: Wyndo’s Skill for reading AI newsletters from a Gmail label and saving useful summaries as Markdown.

• Log Substack Note Stats: Wyndo’s recorded Skill for collecting recent Note analytics and writing them to Google Sheets.

• Data Analytics plugin: An OpenAI plugin package containing several connected analysis capabilities and Skills.

• Creative Production plugin: A plugin bundle Wyndo opened to show how one installation can include production Skills and an MCP service.

• Presentation plugin: The plugin used to open and review a PowerPoint file inside the desktop app.

• Computer Use plugin: The capability used to open Spotify and navigate its graphical interface.

• Browser: The built-in browser with its own profile, history, permissions, annotations, and Computer Use support.

• Record & Replay: A macOS feature that turns a demonstrated process into a draft Skill for later reuse.

• Scheduled tasks: ChatGPT’s background scheduling feature. Wyndo suggested using it to repeat a tested browser Skill on a set cadence.

• ChatGPT Sites: OpenAI’s managed service for creating, hosting, refining, and sharing sites and lightweight apps.

• Atlas: OpenAI’s earlier browser product, mentioned while explaining how browser features were moving into ChatGPT. OpenAI retired Atlas on August 9, 2026.

• Claude Artifacts: Dheeraj used Artifacts as the comparison point for Sites and hosted interactive outputs.

• Vercel: A hosting and deployment service discussed as an option for moving a generated web project to a custom deployment. Current ChatGPT Sites documentation also supports custom domains where available.

• Paper: The HTML and CSS design canvas used for the voice-directed design demonstration. Paper currently offers a free plan and lists Pro at $20 per editor per month or $16 with annual billing.

• Spotify: The desktop app used for the final Computer Use demonstration.

• OpenClaw: Mentioned while comparing multi-agent products and Grok Bot. No pricing was discussed.

• Grok Bot: Cursor’s beta product for creating agents that can use plugins, a cloud computer, and routines.

• Cursor Ultra: One of the plans that currently includes Grok Bot beta access. Cursor lists Ultra at $200 per month.

• OpenRouter: Wyndo’s existing route for using multiple model providers from an agent setup. A related guide was mentioned near the end of the session.

• DeepSeek: The lower-cost model provider demonstrated in Episode 22 as an alternative model behind Claude Code.

A few months ago, I built an AI board of advisors inside Claude Code.

The board had a CEO, CFO, CTO, operator, and critic. Each advisor received the same business question, but each one had a different job.

The CEO looked at direction. The CFO looked at money and risk. The CTO looked at feasibility. The operator looked at what I could realistically execute. The critic came in last and tried to find the assumption everyone else had missed.

When I asked the board how I could grow revenue without making the business heavier, it helped me see why running a cohort program fit better than several other options I was considering. The idea was already in my head, and I still made the final decision, but the board forced me to look at the same choice from several directions before I committed.

At the time, I thought the different advisor roles were the most important part of the setup.

Then I noticed something I had missed.

Every advisor was still running on Claude.

I had created five different job descriptions, but all five advisors inherited the judgment of one underlying model. The CEO and critic could disagree because I gave them different instructions. But, they still came from the same model family, with many of the same tendencies and blind spots.

If Claude overlooked an assumption, there was a chance the entire board would overlook it too.

The Board Was Useful, but It Had One Missing Layer

I still believe the original board got two things right.

First, it forced me to examine the same decision through multiple perspectives.

Second, every advisor needs the same real evidence. A CFO cannot judge a business with no numbers. An operator cannot recommend a sequence without knowing your capacity. A critic with no source material can only produce generic warnings.

Roles and evidence made the board useful.

But after running them for a while, I realized that one thing the board couldn’t give me was a genuinely different model perspective. Five advisors could inspect five parts of the decision and still repeat the same blind spot because the same underlying model powered all of them.

So, the obvious next step was to bring in models from other AI labs. But that would only help if those models were capable enough to handle the same difficult work that demands a huge amount of reasoning.

Until recently, I was not convinced they were.

Why This Became Worth Building Now

I would not have gone through this setup just to collect more AI opinions.

For a long time, the practical choice was simple. Use the strongest frontier model for work that required deeper reasoning and judgment. Once the direction was clear, hand the repetitive and easier-to-verify execution to a faster, cheaper model.

As a heavy Claude user, that usually meant splitting the work between Opus and Sonnet. I used Opus for brainstorming, difficult decisions, and planning. Then I handed the execution work to Sonnet once the plan was defined.

That combination worked because the difference between the two jobs was easy to see. One model helped me decide what to do. The other helped me carry it out.

Recently, that split has become less obvious.

The gap between the models I trusted to think and the models I trusted to execute has started to narrow.

That is why recent releases such as Kimi K3 and DeepSeek V4 caught my attention. Both model families now support long-context, agent-style work that I previously would have reserved for a stronger frontier model.

Moonshot describes Kimi K3 as a 2.8-trillion-parameter open-weight model with native vision and a one-million-token context window. DeepSeek V4 Pro and V4 Flash also support a one-million-token context window, thinking modes, tool calls, and an Anthropic-compatible API.

So these recent advancements in open-weight models are really hard to ignore.

In Artificial Analysis’s July 17 evaluation, Kimi K3 scored 57 on its Intelligence Index, 13 points above Kimi K2.6. In its July 31 evaluation, DeepSeek V4 Flash 0731 scored 10 points above the previous V4 Flash.

To be clear, these scores do not prove that either model will suit your work style. But it’s important to acknowledge why these models are now worth testing on work that used to belong almost entirely to the largest proprietary models such as Anthropic and OpenAI.

Ultimately, these benchmarks just give us more reasons to test them in the first place.

But, the real result I care the most is whether Kimi catches a gap Claude missed, whether DeepSeek challenges an assumption GPT accepts, or whether one model handles a tool call that another model quietly fumbles.

That requires running them on the same real task.

Subscribe now

From Switching Models to Running Them Together

In my previous post, I showed how to use DeepSeek as the model behind Claude Code.

kept the same Claude Code project, research agent, commands, files, and MCP setup. He changed the model handling the requests. The experiment showed that you could keep the system you had already built and route the work you do to another model.

Near the end of that session, we talked about taking the idea further through OpenRouter.

That led me to Claude Code’s four model aliases: Fable, Opus, Sonnet, and Haiku.

Those names normally point to Anthropic models. But things get more interesting when Claude Code connects through OpenRouter, because each alias can point to a different model ID from a different provider.

So Opus could point to GPT. Sonnet could point to Grok. Haiku could point to Kimi. Fable could point to DeepSeek.

Then a Claude Code subagent assigned to each alias runs on the model behind that alias.

That is the discovery behind this post.

You can run several models at the same time inside one Claude Code project, give each one a separate responsibility, and bring their reviews back into one decision process.

You no longer have to open four websites, paste the same background into four chats, collect four answers, and manually remember which model said what. The decision brief, source material, reviewer jobs, and saved output can stay together.

What We Are Building: Multi-Model AI Council

I think of this build as a Model Council—three council members and one judge.

Here’s how it works: the three council members review your decision brief at the same time. Every model receives the same facts, constraints, unknowns, and success criteria. They also receive the same review task and return their findings in the same format.

Each council member reviews the full decision. It looks for weak assumptions, checks the evidence, considers the customer or reader’s perspective, identifies possible failure modes, and recommends what should happen next.

The complete build has six parts:

1. A secure OpenRouter connection that keeps the API key outside the project files.

2. A routing template that maps four Claude Code aliases to council members as well as the judge.

3. One shared review prompt and output format for every council member.

4. A decision brief that prevents each model from inventing its own version of the situation.

5. A /model-council skill that runs the reviews, saves each result, and sends them to the judge.

6. A verification process for confirming which model ran, what evidence it used, and how much the council cost.

We will run the finished council on one real decision and answer three questions:

• Where did the models agree, and where did their reasoning split?

• Did another model surface something that could change or sharpen the decision?

• Was the additional time, cost, and complexity justified by what it found?

By the end, you will have the routing setup, the /model-council skill, the shared decision brief and review format, the judge instructions, and the checks needed to see whether every model did the work it claimed to do.

We will begin with the routing layer, verify every model, and only then give the council a decision to review.

Let’s dive in.

Connect OpenRouter and Choose Your Four Models

OpenRouter gives you one place to access more than 400 AI models from different providers. OpenRouter charges based on usage rather than a subscription, so your model cost depends entirely on the tasks you ask it to perform.

In this section, I will connect OpenRouter to the Claude Code harness and point Claude Code’s four model slots to four models we choose. You could use DeepSeek, Grok, Kimi, Qwen, GLM, or another compatible model available through OpenRouter.

Three models will review the same decision. The fourth will judge their findings and bring the results back into one decision memo.

But first, let’s get your OpenRouter API key.

Create the OpenRouter API Key

Create a dedicated key from the OpenRouter API Keys page. I use a separate key for the council so I can recognize its requests and place a spending limit on it.

Start with a low limit ($20). Three council members and a judge can send several long requests during one run. I would raise the cap only after measuring the cost of the first complete council.

Go to Credits page to start adding a small amount of money. I added $10 of credit before testing the reasoning models. You can start with as low as $5.

You can start with the free plan too, but the number of tokens you can use for each request is very low. As a result, you can’t really test anything substantial if you want to ask the model to do harder tasks.

Make the API Key Available in ~/.zshrc

Read more

Those models are still where I would go for difficult planning, unclear problems, heavy-coding task, visual work, and tasks that need the strongest thinking mode and huge computing power.

But open models are getting capable enough to take on more of the repetitive work. They are also much cheaper to use through the API. That creates a practical question: why keep using a frontier model for every extraction, transcript‑processing job, scheduled summary, or recurring research task when you can easily switch to open models?

For Episode 22, Dheeraj showed me how he was answering that question. He connected DeepSeek to Claude Code, ran an existing research agent through it, and kept the Claude Code interface, project files, commands, subagent, and local MCP tools in place.

He had already moved two agents that run on his computer at 4:00 AM. Those agents kept their existing commands and project setup while DeepSeek handled the model requests, not Claude.

In one of his comparison tasks, Claude Opus cost about 32 cents, Kimi cost about 24 cents, and DeepSeek cost roughly half a cent. But, those results come from his setup, so your costs will depend on the task, token usage, caching, and tools. And, this huge cost gap makes the case worth exploring.

That’s why, in this post, I walk you through the implementation we showed live: creating the DeepSeek key, configuring a single Claude Code project, verifying the connection, running the agent, and switching back when you need Claude again.

One thing you need to understand before we start: this setup accesses DeepSeek through its hosted API. Normally, running a model locally would require a tool such as Ollama or OpenRouter, or hardware powerful enough to support the model you choose.

But this setup is easier to build, so you can start without much integration work upfront.

Why Move Some Claude Code Tasks to Open Models

As of August 9, 2026, DeepSeek lists V4 Flash at $0.14 per million uncached input tokens and $0.28 per million output tokens. V4 Pro is listed at $0.435 per million uncached input tokens and $0.87 per million output tokens.

Claude Opus 5 is listed at $5 per million input tokens and $25 per million output tokens. Claude Sonnet 5 has introductory pricing of $2 per million input tokens and $10 per million output tokens through August 31, 2026, followed by $3 and $15.

As open models get better, it makes sense to stop using a pricier frontier model for every task, especially repeated work that no longer needs the strongest reasoning.

Dheeraj’s examples included processing YouTube transcripts, turning One Shot Show recordings into structured material, generating Substack Notes, and running research jobs with a fixed output. He had already figured out the process. DeepSeek only needed to repeat it at a much lower cost.

Here’s how to set it up:

Subscribe now

Step 1: Create a DeepSeek API Key

Open DeepSeek Platform, create an account, and generate a new API key from the API Keys page.

Before you can run, you need to buy the API token as low as $2.

Copy the key when it is created. You will use it to authenticate Claude Code with DeepSeek’s API.

But, this billing is separate from a Claude Pro or Max subscription. Once Claude Code points to DeepSeek, the model requests use your DeepSeek API balance.

Step 2: Configure DeepSeek for One Claude Code Project

Claude Code supports gateway configuration through environment variables such as ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN. DeepSeek now documents its own Claude Code integration using the same route.

Dheeraj placed the override in .claude/settings.local.json. Claude Code’s settings documentation describes this as the personal project-level settings file, while its environment variable guide says it applies only to you inside that project.

To keep it simple, inside the project folder you want to run with DeepSeek, create this file:

.claude/settings.local.json

Then add the following configuration:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "<YOUR_DEEPSEEK_API_KEY>",
    "ANTHROPIC_MODEL": "deepseek-v4-pro[1m]",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro[1m]",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-pro[1m]",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-v4-flash",
    "CLAUDE_CODE_SUBAGENT_MODEL": "deepseek-v4-flash"
  }
}

Replace <YOUR_DEEPSEEK_API_KEY> with your key.

The model names and endpoint above match DeepSeek’s current integration guide as of August 9, 2026. Dheeraj used V4 Flash as the main model during the live demonstration, while the current official configuration recommends V4 Pro for the main model. Check the official guide before configuring a live project because these values can change.

Keep the file out of Git. Claude Code normally treats .claude/settings.local.json as a personal file, and the official docs say to add it to .gitignore when you create it by hand.

The configuration maps the main Claude model slots to DeepSeek V4 Pro and the smaller Haiku and subagent slots to DeepSeek V4 Flash. This allows the project and any spawned subagents to stay on DeepSeek.

Step 3: Restart Claude Code and Confirm DeepSeek Is Active

Exit the current Claude Code session after saving the settings file. Start Claude Code again inside the same project, then run:

/status

Before the change, Dheeraj’s status screen showed a Claude model and the standard Anthropic connection. After restarting, the base URL pointed to DeepSeek and the active model showed DeepSeek V4 Flash, which was the main model in his settings.

Check both values before running the agent. If /status still shows the original Claude configuration, confirm that the file is named exactly .claude/settings.local.json, the JSON is valid, and Claude Code was restarted after the change.

Step 4: Check the Project’s MCP Connections

Dheeraj’s Scout agent used Tavily through a project-level MCP server. Its configuration lived in .mcp.json, while the Tavily API key was stored outside that file.

Run the following command inside Claude Code:

/mcp

You should see the MCP servers configured for the project or your local user account. In Dheeraj’s first check, Tavily reported a missing environment variable. He exported the Tavily key into the terminal session, restarted Claude Code, and ran the check again.

The second check showed Tavily as connected.

Step 5: Run the Same Agent Through DeepSeek

For the live test, Dheeraj used a small project called Scout. It has a command that allows the agent to run when a new research topic comes in. It launches a researcher sub-agent, searches with Tavily, and writes a source brief into a briefs folder.

Here’s what he ran:

/scout AI agents pricing for 2026

Since DeepSeek was implemented, it has been handling model requests within the same project that the Claude model already has access to. As a result, DeepSeek can now access the same project that Claude can access.

This is the test that decides whether the integration is useful. Give the Claude version and the DeepSeek version the same input, then compare:

• The final output

• Time to completion

• Model cost

• Tool calls and tool cost

• Corrections needed afterward

Dheeraj’s comparison slide showed about 32 cents for the Opus run, 24 cents for Kimi, and half a cent for DeepSeek. The exact numbers will change depending on the task load.

Step 6: Switch the Project Back to Claude

Because the model override lives inside one project, returning to Claude is simple. Rename or remove .claude/settings.local.json, restart Claude Code, and run /status again.

With no local model override, Claude Code falls back to your normal Claude configuration.

One of audiences asked whether there was a simple way to switch models depending on the project. Dheeraj suggested keeping several named templates, such as:

settings.local.json.deepseek
settings.local.json.kimi
settings.local.json.claude

Before starting Claude Code, rename the configuration you want to .claude/settings.local.json. A small script could handle the rename if you switch often.

You can also configure providers globally or route several models through OpenRouter. Dheeraj preferred the project-level method because it limits the change to one known job while you test it. I would start there too.

There’s also another way to do it by running your AI models inside Buzz, which we’ll explore in more depth in an upcoming session.

Share

Which Tasks Should You Outsource to an Open Model?

Now that you understand how to integrate DeepSeek, you can apply the same project-level approach to other open models, including Kimi and GLM. Each provider requires its own endpoint, API key, and model mapping, so you cannot reuse the DeepSeek settings without updating it.

Before going there, it helps to understand which types of work should be outsourced to an open model. Here is how I would think about it:

1. Repetitive text processing: Transcript cleanup, extraction, tagging, classification, formatting, and summaries.

2. Structured research with clear limits: Source briefs, recurring scans, and research tasks with fixed search and extraction budgets.

3. Execution after the difficult thinking is finished: Following an approved plan, producing repeatable variations, or completing work that has already been designed by a stronger model.

4. Low-risk work that is easy to verify: Tasks where mistakes are visible and the result can be checked before it goes anywhere important.

Keep difficult planning, ambiguous decisions, visual debugging, and high-stakes work on a frontier model. Those tasks still benefit from stronger reasoning and broader tool support.

Use Claude or another frontier model to figure out the process, then move the repeated execution after you trust it.

Dheeraj ended the session by saying two of his 4:00 AM agents were already running this way.

That is the version I would want too. Keep Claude Code as the system you work inside, use frontier models where their judgment earns the higher cost, and let cheaper open models handle the work they can now do well.

Show Details

Show: One Shot Show

Episode: 22

Topic: Using Claude Code with DeepSeek and other lower-cost models

Hosts: Wyndo and Dheeraj Sharma

Live schedule: Wednesdays at 10:00 AM ET on Substack

Timestamps

• 00:01: Episode 22 introduction and why lower-cost models are becoming relevant

• 00:04: Dheeraj’s two-week DeepSeek and Kimi experiment

• 00:05: The “32 cents to half a cent” result and which jobs may be worth moving

• 00:08: Is DeepSeek free, and what Dheeraj found when opening a new account

• 00:10: Comparing model prices and discussing third-party Claude Code routing

• 00:13: The project-level configuration begins

• 00:16: Wyndo asks how the project returns to Claude

• 00:17: Creating a DeepSeek API key and adding credit

• 00:19: Inside the Scout research agent demonstration

• 00:21: Why the Tavily search and extract limits must be explicit

• 00:23: Creating .claude/settings.local.json

• 00:24: Checking the original Claude model with /status

• 00:28: Restarting Claude Code and confirming DeepSeek V4 Flash

• 00:30: Loading the Tavily credential and checking MCP health

• 00:31: Which MCP servers remain available after changing the base URL

• 00:35: Comparing a Claude project with the DeepSeek-routed project

• 00:36: Running Scout and launching the researcher subagent

• 00:37: Choosing between migration, hybrid use, and keeping a project on Claude

• 00:40: Why project-level model assignments are easier to manage

• 00:42: Des Kennedy asks how to switch models by project

• 00:47: Wyndo explains the OpenRouter route for multiple models

• 00:49: DeepSeek image limitations and model-specific compatibility failures

• 00:51: Comparing time, cost, capabilities, and cited sources

• 00:52: The missing tool declaration that Claude improvised around

• 00:54: Sixty Tavily calls and the hidden tool-cost problem

• 00:55: How a credential became visible to the model provider

• 00:56: Dheeraj’s model selection rules by type of job

• 00:58: Wyndo previews a future Buzz session

• 01:00: Project-level routing as Dheeraj’s recommended method

• 01:02: Two recurring 4:00 AM agents already moved to DeepSeek

Resources Mentioned

• Claude Code: The terminal-based agent interface used for the demonstration. Wyndo and Dheeraj discussed keeping its commands, subagents, project files, and MCP connections while changing the model provider.

• DeepSeek Platform and API: The provider used for the live rerouting test. Dheeraj created an API key at platform.deepseek.com and reported adding a $2 balance for his test account. Current model billing is usage-based.

• DeepSeek V4 Flash: The lower-cost model used for the Scout demonstration and subagent. DeepSeek’s August 9, 2026 list price is $0.14 per million uncached input tokens and $0.28 per million output tokens.

• DeepSeek V4 Pro: The model mapped to demanding Claude model slots in the demonstrated configuration. DeepSeek’s August 9, 2026 list price is $0.435 per million uncached input tokens and $0.87 per million output tokens.

• Claude Opus 5: Dheeraj’s higher-cost comparison model. His sample run cost about 32 cents. The current API list price discussed in the post is $5 per million input tokens and $25 per million output tokens.

• Claude Sonnet 5: Discussed as another price comparison. Anthropic’s introductory rate is $2 per million input tokens and $10 per million output tokens through August 31, 2026, followed by $3 and $15.

• Claude Haiku: Mentioned in the model mapping and as a smaller Claude model.

• Kimi K3: Dheeraj tested it as another model behind agent tasks. His comparison slide showed an average run cost of about 24 cents for that test. Current general pricing was not established in the session.

• Qwen: Mentioned by Dheeraj as another open model that could use a similar integration pattern.

• Ollama: Mentioned as a way to run a supported model locally when the computer has enough resources.

• OpenRouter: Wyndo suggested it as a gateway for mapping Claude Code model slots to several providers.

• Buzz: Wyndo described it as a chat interface for connecting several agents and models in one conversation. A future One Shot Show session was being considered.

• Tavily: The search and extraction service used by the Scout research agent through MCP. Dheeraj discussed a monthly credit quota but did not state the plan price.

• MCP: The connection method used to give the project access to Tavily and other services.

• .mcp.json: The project file that held the Tavily MCP configuration.

• .claude/settings.local.json: The personal project-level file used to point Claude Code at DeepSeek.

• .env: The local environment file used to hold the Tavily credential during the demonstration.

• Scout command and researcher subagent: The demonstration agent that researched a topic and wrote a source brief into a briefs folder.

• /status: The Claude Code command used to confirm the base URL and active model.

• /mcp: The Claude Code command used to inspect available MCP servers.

• /context and /usage: Commands Wyndo referenced for finding which sessions or agents consume usage.

• Git and GitHub: Mentioned in the warning about accidentally committing API keys or local configuration files.

One of my favorite ways to learn AI is to watch how other people use it in their actual work.

You can learn the features of a new AI tool from a tutorial. But when someone walks through a process they use every week, you see the decisions behind how they use the tool—where they bring AI in, what they still do themselves, and which parts needed more system before the output became useful and closer to the quality bar we want.

I recently stumbled upon Alex Lieberman’s episode of How I AI with Claire Vo. Alex co-founded Morning Brew, and in the episode he demonstrated the content system he now uses at Tenex.

He calls it his Content Machine.

The system finds potential ideas in Alex’s company activity and recent posts from a handpicked list of X accounts, LinkedIn creators, and websites. Once he chooses one, an Interview Panel questions him to pull out stories, examples, opinions, and objections. Its six personas are modeled after Tim Ferriss, Joe Rogan, Barbara Walters, Howard Stern, Michael Barbaro, and Larry King.

The transcript becomes the raw material for a draft written with his voice files. A Writer’s Council then reviews it through personas modeled after Morgan Housel, Tim Urban, Greg Isenberg, David Perell, and Shaan Puri, plus an AI slop detector.

Alex makes the final edit, and the system proposes lessons he can choose to save for future drafts. And, there is even another step that adapts the finished piece for different platforms (X, LinkedIn, Threads, etc).

I already had versions of some of these ideas in my own writing process. I have my own voice guide. I sometimes ask AI to interview me, or I just brain-dump everything to AI and let it help me pick one idea that’s worthy of becoming the main argument. I also have separate editorial agents that review my drafts.

What I had never done was connect them into one clear sequence.

That was the part I kept thinking about after the episode. Alex had taken several things I was doing separately and turned them into a process where the output from one stage becomes the input for the next.

So I built a more compact version for myself that you can adapt as well.

Why Alex’s workflow caught my attention

A common AI writing process begins with rough notes, or by prompting the AI to write something for you.

If the output feels generic, we usually respond by changing the prompt. We add more style rules, provide another example of our writings, or ask the model to rewrite the vague sections to make it clearer.

Those fixes help when the problem is presentation, because they improve a draft you’ve already thought through. They matter much less when you still don’t know what to write in detail. You have a rough idea, but it’s still hard to pull the actual thoughts out of your head and onto the page.

A voice guide can tell AI that I prefer plain words, normal paragraphs, and a conversational tone. It cannot recover a story I never shared. It cannot explain why I believe something if I have not worked through the reason myself. When the source is missing, the model has to bridge the gap with a plausible guess. That’s what we call hallucination.

Alex’s workflow deals with that problem before drafting. The interview keeps asking questions until there is enough material to work with.

This interview process works especially well with voice-to-text. Alex uses Wispr Flow, and I can see why. When I answer out loud, I can brain-dump the story, correct myself halfway through a sentence, and keep talking until the point becomes clearer. The transcript captures much more than I would normally put into a polished prompt.

It’s like having a ghostwriter who is curious about your experiences and wants to sharpen your argument.

By the end of the interview, the model has a transcript filled with the writer’s answers. It has stories, examples, objections, and opinions to work for.

Then the review process brings in five separate subagents. One looks at the structure, another looks at the hook and retention, another focuses on the writing itself, another checks for generic AI patterns, and the final reviewer looks at the piece from the reader’s perspective.

After I make the final edit, the last process compares the first draft with the version I approved. It looks for the corrections I keep making and proposes the ones worth carrying into future drafts.

Once I looked at the process this way, I could see four different jobs:

1. Extraction: Help the writer retrieve the stories, specifics, and opinions behind an idea.

2. Drafting: Shape that material into a piece without quietly adding new reasoning.

3. Review: Find problems with the hook, structure, argument, voice, and reader value.

4. Learning: Save the corrections the writer wants the system to remember next time.

Now you notice that this is actually a looping workflow that improves over time, because every correction becomes a lesson the agent will apply in future runs.

Subscribe now

What I changed for a solo creator (or anyone who writes)

Alex built his Content Machine for a company. It connects to internal sources such as Slack, Notion, meeting notes, Linear, Git, and Gmail. It also helps Tenex employees create content alongside their full-time jobs.

On the other hand, I wasn’t writing for a company; I was writing for myself and the small audience I currently have. So I wanted a version that a single person could copy into their own content operating system and then publish on Substack or any other social platform.

So, I removed the idea-finding stage because I already have a separate research process thathelps me find topics to talk about. I also assume you already have your own way of finding ideas on the internet. Rebuilding Alex’s system would only duplicate work I already do, because you, Alex, and I all approach this differently.

I also reduced the six interviewer personas to three clear jobs because I don’t want the interview process to become overwhelming, where I have to answer to too many personalities just to get an argument out of my brain. We don’t need that level of complexity in the beginning.

Then I kept the independent editorial review with five sub-agents running in parallel, each of them having different jobs to review my draft. I then capped the revision loop at two passes.

That was the smallest version I could run without losing what made Alex’s process useful.

That left me with four skills:

1. An interview panel.

2. A transcript-grounded drafting skill with an invention check.

3. An editorial council with five independent reviewers.

4. A lesson extractor that compares the first draft with my final edit.

The system also keeps my voice files separate from the whole process. This enables me to modify skills later without overwriting the style rules, writing samples, and corrections that belong to me.

What happened when I tested it

For the first run, I chose an essay I had opinions about but had never managed to finish.

Let me tell you what happened.

The interview lasted ten questions. The three roles of interviewer moved in and out depending on what I had just said. One would ask for a real moment. Another would notice a vague claim and push for a number or example. The contrarian role would take a likely reader objection to something I’d said and make me answer it before it generated the draft.

I started with a rough topic in my head. Ten questions later, it had become a detailed transcript filled with stories, examples, and objections I had not thought about before the interview.

The drafting stage then used that transcript as its source. After producing the first version, it ran a separate check to make sure every sentence could be traced back to something I had said.

Then five reviewers read the first draft.

They found the usual writing problems, including an opening that explained too much and sections that needed tightening. They also identified gaps in the draft that they couldn’t fix, because it needed a concrete example I had never provided.

After I read the review, I did the final edit myself. I added the missing example, tightened the sections the reviewers had flagged, and saved the result as the final version while keeping the first draft untouched.

Then I ran the extract-lessons skill. It compared the first draft with my final version, identified the patterns in the changes I had made, and updated the content lessons file with the candidates I approved.

That completed the full loop for one article. We’re going to dive into this entire loop in this post.

What you are getting in this guide: Content Machine Agent

The rest of this guide gives you the complete system and shows you how to adapt it to your own writing:

1. The four skills that run the process. You will get the interview panel, transcript-grounded drafting skill, editorial council, and lesson extractor, along with the sequence for moving one piece through them.

2. The full folder system you can copy and run. The skills, voice files, draft folders, supporting instructions, and README come arranged so you can place the system inside a real writing project and start with one idea.

3. A setup for turning it into your own content agent. You will create a style guide, generate a voice guide from your published work, and build a lessons file from the corrections you make over time. These files teach the agent who you write for, how your writing sounds, and which mistakes you do not want repeated.

4. A check before and after the draft. Before the agent starts writing, it looks at what you have actually given it. If something important is still missing, the agent sends you back to the interview instead of covering the hole with polished prose. After it writes the draft, it checks the claims against your answers and points out any place where it may have added an idea of its own.

5. Five independent subagents that review the draft. Each reviewer gets one job: structure, hook and retention, craft, machine-shaped writing patterns, or reader value. Their separate scores and objections are collected in one council report.

6. A process for extracting lessons from your writing. After you finish the human edit, the final skill compares your version with the first draft, identifies recurring corrections, and proposes the lessons worth applying to future pieces.

By the end, you should have a content machine you can copy into your own project, adapt to your writing, and diagnose when the result falls short.

You can run this using Claude Code, Cowork, and ChatGPT/Codex.

Now let me show you how the pieces fit together.

How the Content Machine Is Organized

Before we get into the four skills, I want to show you how the folder is arranged.

There are three core parts of the system here you need to understand:

1. Skills. This is the operator of the system that runs the interview, drafting, review, and lesson extraction.

2. Voice. This contains information about who you are, who your target audience is, what you write about and don’t write about, and how you write.

3. Draft. This contains all drafts, including transcriptions from the interview process, the draft that the reviewer improves, and the final finished piece you refine yourself.

Since the Skill is the operator of the system and voice is what the AI understands about you, you can modify Skills however you want without affecting your voice, style, or anything else the AI learns about you.

Here is the complete structure:

Read more

Dheeraj drove this one. He has been running his version since May, so we were looking at something with three months of experimentation behind it. A lot of small mistakes, corrections, and lessons had already made their way into the files.

I went in expecting the interesting part to be the scan process. Which sources should it check? Which connectors should it use? How do you get Reddit results that are actually useful?

All of that was there, but it took only about ten minutes because the scanning is pretty straightforward now. The rest of the hour went into one file called the brand rubric, where you write down what a good idea is actually worth to you.

That file is where the agent begins to feel like yours. Without it, the agent can find plenty of ideas and still hand you the wrong ones.

Subscribe now

The Problem With How Most of Us Pick What to Write

Dheeraj opened with a question for the audience: how do you decide what to publish next? Gut feel every week? A backlog you are already behind on? A keyword tool? An actual system?

I answered honestly, because my version has three ways of doing it. I brain-dump any interesting ideas that catch my attention into Obsidian. I have a system that pulls summaries from the newsletters I subscribe to, which I run weekly and read manually. I have another one for X. Every week, all of that arrives, I look through it, and I pick whatever resonates most.

It works. But I still need to decide them myself, every time, from scratch.

And as the pile of ideas grows, it’s easy to feel overwhelmed. So many ideas, but no clear sense of which one to pursue. Dheeraj captured the real issue well: we do not lack ideas. We lack the signal that tells us which idea is the right one to write.

That gap is what the content radar is for—not generating more ideas, but ranking the ones the internet is already handing you.

What You Will Build: Content Radar Agent

The rest of this post turns those decisions into a working content radar.

You will get the starter folder Dheeraj used, then work through the files that control what the radar scans, what it ignores, how it scores an idea, how it checks your existing calendar, and how it learns from your corrections.

By the end, you will have a version you can run manually in Claude Cowork or Claude Code or ChatGPT/Codex. Once the recommendations start feeling useful, you can schedule it and have the brief arrive even when you are away from your laptop.

The goal is simple: find a better list of content ideas that suits your brand and is relevant to you.

You might want to check Dheeraj’s Substack to explore more of what he writes about.

GenAI Unplugged

Learn to build production-grade AI automation systems (setups, prompts, workflows, and templates) from someone who builds them at work by day and ships his own products by night.

By Dheeraj Sharma

Let’s dive in.

Start With the Five Layers of Content Radar

To build your first content radar agent, there are five layers you need to know:

Read more

Trust comes from reliability. Reliability comes from a proper system built inside the agent.

That’s why I wrote two posts about it this week:

1. The Complete Guide to Building Your First Agentic System (That You Can Actually Trust)

2. Why Your AI Harness Matters as Much as the Model

The first question came from Atit, and it was the clearest version of it.

He wanted McKinsey-style research and decks, at a real quality bar, and he was trying to work out which tool would get him there. But the tool was never going to be the answer. Without a defined source, a report standard, reference decks, and an output format the agent can see, every deck starts from nothing and lands somewhere different.

That is where the babysitting begins. You give the agent a task. It gives you something that looks mostly right. Then you notice the weak research, the generic email, the missing task, or the visual that has nothing to do with the post. You explain the problem, ask it to try again, and keep watching because you do not fully trust what happens next.

Six AI Maker Lab members sent questions this month, and all six were a version of the same frustration:

1. Atit wanted reliable McKinsey-style research and presentation decks, plus a clearer way to decide between local models and hosted ones.

2. Mei wanted an agent that could follow a real workflow with less hand-holding.

3. Karen wanted to avoid getting trapped inside a single AI tool and asked how she could work her project across Claude Code, Codex, and Hermes.

4. Thomas stuck between Cursor, Claude Code, and Things.

5. Julia was overwhelmed with so many saved posts she had not touched and consumed at all

6. Lee spent two hours to create his newsletter banner.

All of them is different jobs, but the real problem underneath them them is identical.

So, in this post, I tackled all of them.

In this video, I also showed the working versions behind the folder structure for a research agent, my Obsidian–Todoist planning loop, the AI News Intel Skill that read 27 newsletter emails, the X bookmark workflow that has been collecting everything I’ve consumed over the past week, how to import your Claude setup into ChatGPT/Codex, the Glif process that generates thumbnails and infographics for my newsletter, and how to create a design system for generating banners with Claude Design.

Let’s dive in.

Subscribe now

Atit: How do I build reliable McKinsey-style research and decks?

Atit wanted to create deep research and presentation decks with a specific quality bar. He was considering Claude Code, Codex, NotebookLM, and Gemini. He also asked how I would think about the build-versus-buy decision for an AI agent.

For research work, I keep coming back to a file-based agent like Claude Code or Codex, because I want control over the process and the final format.

NotebookLM is useful when the main job is working through a large pile of sources. But, where it stops working for me is customization. You cannot really shape the workflow, the agent, or the output beyond what NotebookLM already gives you. For a job where I need to define the research sequence, enforce my own report standard, and produce several exact deliverables, I can’t have that ceiling in my workflow.

So, the tool you choose matters here, but having more control over how you work and what you can generate is more important.

If you want to build a research agent, here is the rough structure I’d build in my project folder:

Read more

Over the last four months, I have been running Q&A sessions with paid members of AI Maker.

Here are some type of questions that I’ve received so far:

1. How do I create a master prompt that understands my writing?

2. Can I turn client call transcripts into LinkedIn ideas?

3. Where should my research live?

4. Should I use Claude Code, Cowork, Codex, or another agent?

5. How do I build reports and decks that are reliable enough to use with clients?

But the more I think about it, the more I realize these questions are just two versions of the same problem.

First, some people create a new AI project for every kind of work.

One Claude Project for writing, another for research, another for a client, another for a new business idea. Then a few custom GPTs, saved prompts, half-finished skills, and too many MCP tools connected because they looked cool but aren’t actually useful.

This can help for a while. But every project will evolve and develop its own instructions, files, prompts, and corrections. Soon, the person has to remember which project contains the latest rule, where the best reference file lives, and which version of the process produced the result that meets their standards.

Second, other people have not defined a strong process yet.

They know how to do the job through experience, but the steps, required input, and quality bar still live mostly in their head. When they ask an agent to help, they give it the task without explaining how to do it properly.

In one case, the process is scattered across too many places. In the other, the process has never been written down clearly enough for an agent to follow.

Both lead to the same problem: bad outputs that you can’t really trust.

That is why I keep returning to one question:

“How do I turn the way I work into a process an agent can repeat and I can trust?”

At a high level, that process needs six parts:

1. One repeated job with a clear starting point

2. The real input the agent needs

3. A process the agent can follow

4. A reviewable output

5. A written standard the output must pass

Whatever that goes into the job can be completely different.

What do I mean by that is a creator may start with a rough idea and end with a newsletter draft. A consultant may start with a client call and end with a proposal. A manager may start with weekly updates and end with a team brief. A researcher may start with a question and end with a report.

The input, process, output, and standard will change, but the basic shape stays the same.

Whether you use Claude Code, Cowork, Codex, or another agent, you still need to make those decisions before the agent can repeat the work reliably.

How do you make an AI agent workflow more reliable?

Reliable output requires more than a good prompt or a capable model.

Every run will be different. The research changes. Client information changes. The process gets adjusted. The output changes depending on the situation. Even your quality bar should get sharper as you learn more about your work.

Reliability comes from making those moving parts clear enough to inspect. Before each run, the agent should know:

• What information it needs before starting

• Which process and decision rules currently apply

• What it is responsible for producing

• Which standards the result needs to pass

• Where your corrections should be saved for the next run

REQUIRED INPUT
        |
        v
CURRENT PROCESS AND DECISION RULES
        |
        v
REVIEWABLE OUTPUT
        |
        v
CURRENT QUALITY CHECK

Once those pieces are clear, you can compare one run with the next. If the result changes, you can see whether the source material changed, the process was updated, the output requirement shifted, or the quality standard became clearer.

Your work keeps evolving, but the changes become deliberate and traceable. That is what makes the system more reliable over time.

Subscribe now

Start with one repeated task for your AI agent

To turn one repeated job into a process an agent can follow, I would begin with four questions:

1. Work

What repeated job do you want the agent to handle?

Keep this simple and don’t overthink. “Help me run my business” is difficult to define. But, a job that starts with a recognizable input and ends with a reviewable deliverable is small enough to build.

For example, creating a newsletter post from a brain dump of ideas, building a high‑quality report deck from research data, or turning a client transcription into a proposal deck.

2. Input

What does the agent need before it can begin?

This might include research, notes, transcripts, client documents, datasets, meeting updates, or brief.

3. Output

What should exist when the work is finished?

A newsletter draft. A client session plan. A weekly team brief. A research report. The output needs a clear format and a place where the agent should save it.

4. Key standard

What must be true before you would accept the result?

For writing, the standard might be preserving your argument, voice and verifying current claims. For consulting, every recommendation may need to trace back to the client’s information. For research, facts, inferences, and recommendations may need to remain clearly separated.

Write those four answers down in one place:

WORK
The repeated job I want the agent to perform.

INPUT
The files or information that begin the job.

OUTPUT
The deliverable that should exist when the job is complete.

KEY STANDARD
The most important requirement the output must pass.

And let’s look at this from a broader perspective based on the job type:

Notice that the details change across each kind of work, while the shape stays the same. Every job begins with specific input, produces a defined output, and has one standard the agent can use to judge the result.

What should an AI agent folder include?

Once the job is clear, you can give each part a place in a local computer folder that your agent can find and use again.

Here is the basic folder:

your-agent-job/
├── CLAUDE.md   --> the project direction for Claude
├── AGENTS.md   --> the project direction for ChatGPT/Codex
├── input/      --> real sources material
├── output/     --> the finished deliverable
├── standards/  --> quality requirement to generate outputs
└── .claude/
    └── skills/ --> specific task level instruction for Claude
└── .agents/
    └── skills/ --> specific task level instruction for Claude

Allow me to explain for each of them:

The main folders

The main folders, input/, output/, and standards/, give your work a place to live.

• The input/ folder contains the real source material the agent needs before it starts.

• The output/ folder gives the finished deliverable a clear place to go.

• The standards/ folder contains the quality requirements the agent should use to review that output.

The instruction file

Without the instruction file, the main folders are still just a collection of folders and files. The agent needs something that explains how those pieces fit together and what it should do when a request comes in.

That is the job of CLAUDE.md or AGENTS.md.

The instruction file tells the agent what this project is for, where the inputs and standards live, where it should save the outputs, and which Skill to use when a certain request comes in. This is what ties the folders together so the agent does not have to guess what to read or what to do next.

Skills for specific tasks

Skills sit one level below that.

Skill is important because sometimes a simple prompt isn’t enough to generate reliable output. Some tasks require a more specific process the agent needs to follow. It can be time-consuming if you have to write everything by hand every time you want the agent to do repeatable tasks.

That’s why we need Skill. A Skill is like a saved instruction that the agent needs in order to generate reliable results repeatedly by following a specific process.

For example, you might ask the agent to turn one newsletter into a LinkedIn post, a Substack Note, and an X thread. The instruction file tells the agent where to find the source newsletter and the standards for each channel. A content repurposing Skill gives it the exact steps for turning that source into three different outputs.

If you are a researcher, the instruction file might tell the agent where the research questions, source rules, and report templates live. A research Skill can then tell it how to search the internet for a topic, review the sources, separate evidence from inference, and generate the final report in the format you already defined (html, ppt, docs, etc).

Use this Skill when you want a task executed properly with a minimal margin of error.

External access through MCP or CLI

If the job needs information outside the local folder, MCP or command-line tool can give the agent access to it.

For example, MCP might let the agent read a document from Google Drive. Or you could ask the agent to read all of your Gmail inbox, X bookmarks, create tables in Notion, and build you a banner for your marketing campaign.

Without MCP or CLI connections, the agent can’t reach out to the outside world to interact with the apps you use on a daily basis. This keeps all your work trapped on your local computer and still requires you to copy and paste everything manually.

I know you don’t want that.

With MCP or CLI, the agent can do all of this for you and execute on your behalf.

Build the first working version

In the rest of this post, you will start with a blank job system and fill it with your own Work, Input, Output, and Key Standard.

At each step, I will show how this works across multiple job types—creators, consultants and coaches, managers, researchers, and business owners—including templates that use those five folder shapes.

By the end, your folder will be able to take one real input, follow a defined process, create a reviewable output, and check it against a written standard.

The goal is a small system you can run again every day.

In the end, you’ll end up in the place where you spend less time babysitting the agent so you can deploy 5-10 agents to do more work and eventually become more productive than you ever be.

Choose the folder shape that matches how your work repeats

You may already have Claude Projects, saved prompts, and partial systems scattered across different places. I’ll assume that you have now defined one job, the input it begins with, the output it should create, and the standard it needs to pass.

What we need to do now is giving those pieces a folder structure the agent can follow.

Choose the example closest to how you work, then rename or remove anything you don’t need.

I am showing the Claude Code version below to keep the trees readable. If you use ChatGPT/Codex, replace CLAUDE.md with AGENTS.md and .claude/skills/ with .agents/skills/.

For creators

Read more

Every time a new AI model comes out, the same race starts again.

People compare benchmarks, post one-shot demos, switch subscriptions, and tell you the model they were praising last month is already old news.

I’m sure you’ve seen plenty of people write over-the-top headlines like these: “OpenAI just killed 1,000+ startups,” “Anthropic is DONE,” or “Local models are the future.”

And if you use AI every day, it’s hard not to feel like you should keep up. Otherwise, you might feel like you’re going to get left behind.

This makes us feel guilty for not keeping up, so we switch models every once in a while. But switching models just because the new one is better does not fix the problem on your AI setup around your work.

The new model still needs to understand your AI setup. It still requires the right files, instructions, tools, permissions, and checks. If any of those pieces aren’t properly built, you’ll end up re-explaining the same task to a more intelligent model. But what you do is still the same—like a caveman who keeps repeating the same prompt just to re-explain your context.

I recently heard Matt Pocock compare the model to the engine in a Formula 1 car.

Matt is one of the AI creators I respect because he shares something real, his opinions are grounded, and he avoids the hype, focusing instead on what actually matters: building the right system for the agent.

But that doesn’t mean he ignores how important it is to have a better engine for the model. After all, the engine matters and makes a big difference. Because when you replace it with a stronger one, the whole car gets faster. But what most people tend to ignore is that the chassis, aerodynamics, controls, and feedback from the track still determine whether that power actually helps the driver win the race.

AI works in a similar way.

But what’s happening is that most people treat the model as 90% of the result, when in reality the model and the harness are closer to 50/50.

The model gives the agent its ability to reason, write, and make decisions. The harness gives it the right instructions, information, tools, boundaries, and feedback for the work in front of it.

While the model is the half you can’t control, the harness is the half you can control.

And this completely changes how I use AI.

The reason is because I’ve seen this in my own newsletter setup.

I move between Claude Code, Codex, and local models. Even though the models change, what makes my system work carries across: the files that explain my publication, the rules that protect my voice, the skills that run repeated workflows, and the checks that catch low quality AI outputs before it reaches me.

That difference shows up in what I no longer have to explain every time. When I ask the agent to help with a newsletter, it already knows who I am writing for, how my free and paid posts differ, which sources to read, and which claims may need more evidence.

That does not mean the agent writes exactly like me or makes the final editorial decisions. It gives me a much better starting point. I spend less time rebuilding the brief and more time deciding what the post should argue, which examples feel honest, and whether the writing is ready for readers.

So, the point I’m trying to make here is while it’s true that model choice still matters, what most people ignore is whether they’ve built the right setup for their agent.

That right setup is the harness.

Subscribe now

What an agent harness actually is

The word harness makes this sound more complicated than it needs to be.

Claire Vo gave the simplest explanation I have heard: a harness is code around an AI agent that makes it better at a specific job.

But, I would expand that slightly:

An agent harness is the system around the model that helps it perform useful and reliable work consistently.

While the model supplies the intelligence to reason through a problem, decide what to do next, and generate a response, the harness supplies the conditions that let it apply that intelligence to your actual work.

In practice, harness has five parts:

1. Instructions

These define the job. They tell the agent what it is trying to accomplish, how it should approach the work, and which rules it should always follow.

A general instruction might say, “Write a client update.” A harness can already know what belongs in the update, how detailed it should be, and which claims need evidence.

If you have been using Claude Code, Codex, or any other agents, the “instruction” we refer to here is actually the ‎⁠CLAUDE.md⁠ and ‎⁠AGENTS.md⁠ files.

I spoke about this a lot in my agent guide. This system instruction file is essentially the brain of the system. It tells the agent what to do whenever you work inside your project folder.

2. Context and source material

This is the information the agent needs before it begins. It might include the client’s background, context about who you are and what you do, your previous decisions when running a project, examples of high‑quality work, current project files, or the data behind the task you are working on right now.

Without that context, even a strong model has to guess. Or you have to brief it again.

In my ultimate guide to building a context folder, I strongly emphasize taking your time to fill it out, because context makes the agent’s answers more personalized to you and better suited to your current situation.

With the right context, you’ll be far less likely to get generic output from the agent.

I like what Thariq from the Anthropic team said about this:

This resonates the most with how I’ve been using AI agent.

The right context for your agent can help you move mountains by equipping it with the right data to execute any kind of task more effectively.

3. Skills and tools

Instructions tell the agent what to do. Skills and tools give it ways to do the work.

That could mean searching the web, reading a spreadsheet, checking a database, updating a document, running code, or following a specialist review process. The harness decides which capabilities are available and when the agent should use them.

This explains why I’ve been going hard on how to combine tools and skills, as you can see from some of my previous posts:

1. How I Turned X Into a Research Engine Inside Claude Code

2. How I Run My Entire Notion From Claude Code (Without Clicking Around)

3. I Rebuilt My LinkedIn Carousel System, It Now Looks Like A Designer Made It

Once you’ve connected your agent to tools and can execute them through skills, you no longer need to use those tools separately or jump between them. With these two combined, the agent becomes more reliable at generating outputs that live up to your standards.

4. Permissions and guardrails

An agent also needs boundaries: Which files can it change? Can it send the email, or should it only draft one? Can it publish the result? Which actions require approval?

These rules become more important as the agent not only generates text, but also performs work inside your tools and modifies your files.

Without these, things can quickly turn into a disaster, with the agent deleting forbidden files, including scripts, emails, and any working documents. Permissions and guardrails ensure that you are always the one steering the agent—not the other way around.

5. Checks and feedback

The first output of the agent should not automatically become the final output.

A harness can check whether the result follows the required format, uses the right evidence, passes a test, or needs another review. That feedback goes back into the process so the agent can fix predictable problems before they reach you.

Put those five parts together and the difference becomes easier to see.

In case you want to take a deeper look on how to improve your agent harness, I already covered it in my previous post.

Now that you understand what the harness is, you’ll start noticing that you already interact with harnesses every day through tools like Claude Code, Codex, or Cursor.

The harness is already shaping your results

When you use an AI coding agent, you’re rarely interacting with the model alone, because the model has been improved by the harness:

1. Anthropic describes Claude Code as “the agentic harness around Claude.” It gives the model tools, manages the information entering the conversation, and provides the environment where it can read files, edit code, and run commands.

2. Cursor defines its harness as the combination of instructions, tools, and the chosen model. Its team adjusts those instructions and tools for the different models Cursor supports.

3. OpenAI documents a similar surrounding layer for Codex. You can use AGENTS.md, skills, memory, and connections to other tools to shape how Codex works inside a project.

This helps explain why the same model can feel different depending on where you use it. One tool might give it better access to your files. Another might load your instructions more reliably, handle permissions more clearly, or provide better ways to check the result.

The companies building these tools give us the starting harness. Then we add the layer that makes it specific to our work.

And those improvements built on top of our agent can continue working effectively even when the model changes.

Share

Why an AI agent harness compounds across models

Matt said he tries to keep his harness as model-agnostic as possible. So do I.

That means he avoids building an entire way of working around the quirks of one model. He focuses on the parts that should remain on his control: clear instructions, good source material, a codebase the agent can understand, sensible guardrails, and feedback that shows whether the work succeeded.

But carrying the harness forward does not mean you don’t need to tweak them. Ryan Lopopolo recommends testing the surrounding setup again whenever the model or coding agent changes. Your sources, rules, and quality standards may remain useful, while some instructions or checks need adjustment. A stronger model may even let you remove parts you previously needed.

This is where a harness starts to compound.

1. The next model should start ahead

Imagine you spend a month working with an agent and correcting the same problems. You explain how you want reports structured. You clarify which actions need approval. You catch a mistake in the review process and add a check so it gets caught earlier next time.

If those lessons stay locked inside a single agent, most of that work disappears when you switch to another agent that just released a better model.

But if you turn those lessons into instructions, skills, source files, and checks, the next task starts from what you’ve already learned—and so does the next model.

Again, I’ve seen this in my own setup. Claude Code and Codex follow different instruction files and handle parts of the work differently, but the underlying foundation is the same. They can read the same audience research, publication principles, past post archives, and task-specific skills. They can work against the same quality standards even when the model or tool changes.

So when a better model arrives, I do not have to rebuild the publication around it. I can place that model inside a system that already understands how I work.

A concern note by expressed this clearly:

Since I’m currently in a model‑agnostic mode and my AI projects live locally and on GitHub (Cloud), I’m not afraid if frontier labs suddenly increase their costs, because I can just switch to another model or go local completely without sacrificing much in terms of the quality of my work.

For me, I don’t worry too much about the specific model and instead focus on the harness. If a model breaks (whether from cost or system issues), I can easily switch it out. But if a new, better model comes along, it becomes a multiplier on top of the same harness.

2. A better harness can make cheaper models useful

This can also change the economics. Matt argues that a clearer codebase and stronger guardrails can sometimes help a cheaper model complete work that would otherwise require a more capable one. The agent spends fewer tokens searching through a mess, misunderstanding the task, or repeatedly correcting avoidable mistakes.

The same principle applies outside coding. If an agent gets the right client files, a clear process, a limited set of tools, and an expected output format, it has less room to wander. More of its intelligence goes toward the judgment the task actually requires.

And the harness can keep improving after the work begins.

3. Review the system, not just the output

When I review an output, I’m also learning something about the system that produced it. Every time I find a bad output from my agent, my first assumption is that it might reveal an issue: a vague instruction, a missing source, a skill that loaded at the wrong time, or a check that doesn’t have clear criteria for what to validate.

This is why it’s important for us to have a process to review not only the final output, but also the system underneath them. That visibility helps you improve the harness over time and decide where the agent can safely do more without you.

This is the part I find more valuable than chasing every model release.

Every correction can become a clearer rule. Every repeated process can become a reusable skill. Every failure can produce a better check. Each improvement becomes part of the starting point for whatever model comes next.

That is how the system compounds.

And you might be wondering what the final goal is with all of this.

For me, the goal is to remove myself from the day-to-day work of handholding and steering the agent. I want to give it a simple prompt, have it know what to do, and receive work that already meets my quality bar.

I am not there yet. I still make the final editorial decisions and review what goes out. But I want the agent to arrive much closer to that standard without me guiding every step.

How one newsletter moves through my harness

The easiest way to understand my harness is to follow my newsletter through the system.

Plan and research

My content calendar lives in Notion. It keeps track of the ideas I am considering, the posts I have decided to write, and where each piece stands.

When I choose a topic, I can use X as a research source. The agent searches recent conversations and posts from people I trust, then pulls useful examples, recurring questions, objections, and source links into a research brief.

That research still needs judgment. A popular post is not automatically good evidence, and a repeated opinion is not automatically true. But the harness gives the agent a defined research process instead of sending it into X to collect whatever looks interesting.

I also have a skill that deploys multiple sub-agents to read all the newsletters I subscribe to and generates summaries for me: what happened this week in AI, which new tools I need to try and why, what the current meta-trends are, what people are saying about these new AI tools, and new ideas I can write about based on what’s happening right now.

It helps me stay up to date with everything happening in AI without feeling overwhelmed by trying to keep up with major news every single hour.

Draft and review

When the agent begins writing, it already has the files explaining my audience, publication, voice, and content rules. It knows where to find previous posts, which sources support the argument, and which claims need to be checked.

After the first draft, I can send it through a review panel made up of sub-agents with different jobs. One reads as a skeptic and challenges weak claims. Another looks for structural and pacing problems. Others respond as a first-time visitor, paying subscriber, content creator, knowledge worker, or entrepreneur.

A moderator agent then compares their reviews, finds the problems several readers noticed, and makes a judgment when the reviewers disagree.

I still decide which feedback is right. The panel gives me more useful material to make that decision without asking me to catch every problem alone.

Package and repurpose

Once the newsletter is approved, it becomes the source for the rest of the promotion.

One process can create the promotional email. Other specialist agents can extract one strong LinkedIn angle, several standalone Substack Notes, and an X thread. Each format follows its own rules, so they do not become shorter copies of the same article.

The visuals have their own processes too. The infographic generator reads the finished post and turns its main ideas into a visual explanation. The thumbnail generator looks for the central transformation or metaphor and creates several symbolic directions for the cover.

All of those outputs begin with the same argument and evidence, but each one has a different job.

Approve and distribute

The agent can prepare the promotional material, but I still approve what gets published.

Once the social posts are ready, I can send the approved X and LinkedIn drafts to Typefully, attach the right visual, and schedule them. I can then update the content calendar in Notion so I know what has been created, reviewed, scheduled, or published.

The value comes from the whole sequence. I am not opening each tool, pasting the newsletter again, restating the audience, and explaining the standards from the beginning.

If I change models tomorrow, this process can remain. The next model can use the same content calendar, research method, publication files, review panel, visual skills, platform rules, and approval points.

That is what makes the harness more valuable over time. Each new model enters a publishing system that already knows how the work moves.

Build the part you control

Another model will arrive soon.

It will score higher on a benchmark, complete a task the previous model struggled with, and make something that took an hour feel strangely easy.

I will probably test it. You might too.

Better models are useful. I just do not want each release to send me back to the beginning.

The model company decides how intelligent the next model becomes. I decide what that intelligence finds when it enters my work.

Does it find a blank chat box and wait for another long explanation?

Or does it find clear instructions, trusted sources, useful skills, sensible boundaries, and a review process shaped by all the mistakes I have already made?

That is the part worth building.

Start with one job you repeat

You do not need to build every layer at once.

Pick one job you already use AI for every week. It could be a client update, research brief, newsletter, meeting summary, or weekly report.

Then give the agent a small system around that job:

1. Write one sentence explaining what the output should accomplish.

2. Add one trusted source the agent should always use.

3. Include one example of a good result.

4. Save the instructions you find yourself repeating.

5. Decide which actions still require your approval.

6. Define one check the result must pass before you accept it.

Run the task once. When the agent misses something, save the correction with the rest of the instructions instead of leaving it inside that conversation.

The next attempt will begin with one more lesson about how you work. That is enough to start the compounding loop.

Your first harness can be one document attached to one repeated job. You can add more sources, skills, tools, and checks when the work proves that you need them.

If you want to turn that starting point into a working Claude Code harness, I have documented the version I use.

In How an Agent Harness Made My Claude Code Setup 10x More Reliable, I walk through the four layers behind it:

1. Memory that carries repeated corrections across sessions.

2. Hooks that run quality checks automatically.

3. Agent orchestration that gives different jobs their own focused process.

4. Evaluation loops that review and repair work before it reaches you.

The model will keep changing. Give the next one a better system to enter.

This session was a little different from any other show we’ve done, because we didn’t talk about new AI features you need to test. Instead, we focused on the process you can follow to work with AI to get a better result.

Hodman is a data scientist and the founder of Asaura AI, an orchestrated AI system that helps high performers manage focus and information intake when execution friction gets in the way.

Between Thinking and Doing

Where neuroscience meets execution. BTD helps high performers and teams get traction on complex work through structured AI systems. Subscribe to get your free Friction Audit.

By Hodman | How To Build With AI

On Substack, Hodman writes Between Thinking and Doing about structured AI systems for people with ADHD-style friction and initiation problems, and The Data Letter, where she helps managers, operators, and technical builders build with AI.

Hodman came with a feature idea that seemed to fit that goal: add a short breathing exercise before users started a task.

The reasoning sounded solid because she had read a study about meditation and ADHD in children. Meditation had also helped her manage ADHD, anxiety, and stress in her own life.

But if the idea was wrong, she could lose a month building it and frustrate the same beta testers she wanted to help.

So, Hodman asked Claude a harder question: assume six months had passed, the decision had failed, and then explain why.

That was the pre-mortem.

She ran it inside Decision Studio, a Claude Project she had built to challenge product decisions before she committed to them. Its first instruction was blunt: “Don’t cheerlead.”

But, before the analysis was executed, Hodman filled in five fields on her prompt:

Decision: Add a breathing exercise before any task in the Asaura beta

Why now: A study on meditation for children with ADHD, plus her own positive experience

Evidence for: The study and her personal use

Evidence against: None that she was weighing at the time

Cost of being wrong: A month of build time and disappointed beta testers

Then Claude produced three things: a ranked pre-mortem, a red-team memo arguing against the feature, and a one-page decision memo with a recommendation and stopping rules.

For the demonstration, Hodman reused a real decision from an earlier Asaura beta so she could compare Claude’s analysis with what had actually happened.

Let’s dive in.

The Pre-Mortem Found Three Problems

The first problem was immediate drop-off.

Asaura’s users opened the product because they were already struggling to start their work. Since a breathing exercise was placed as another step between them and their task, it predicted that some people would close the app at the overlay screen.

Hodman’s feedback supported that risk. One beta tester had told her:

Every time you put something between me and my task, I close the app.

Another said:

Please skip the wellness stuff.

The second problem was what Hodman’s anti-patterns file called the “works for me” fallacy. The breathing exercise helped her personally, but Claude warned that she might remain the only person in the beta who valued it. As builders, we often overestimate the impact of what we want to create while overlooking the potential issues it might cause for others. This leads to building features that are useful to us but not to anyone else.

The third problem was the evidence itself. The study involved children practicing meditation in a supervised setting. Asaura served adults using a self-serve productivity product. The research supported meditation as an intervention, but it did not show that people wanted a breathing exercise placed before every task.

All these insights make her realize that the priority for building her next features is to help people begin their work as soon as possible, not to add more friction that might prevent them from doing the work.

Subscribe now

Claude Turned the Idea Into a Smaller Test

Then, Claude recommended her against shipping the breathing exercise as proposed. But it did not end with “no.”

It suggested three steps Hodman could take first:

1. Interview five heavy users about what they need immediately before starting a task.

2. Read three studies about adult, self-serve mindfulness tools and task initiation.

3. Prototype a version that appears after the user has already taken the first step.

Out of these three suggestions, the prototype is the one that might be easiest to build.

If Hodman still wanted to test it, Claude recommended a two-week opt-in experiment using task-start rate as the main measure. It also gave her three reasons to stop it so she doesn’t have to dwell on this for long period of time:

• The task-start rate dropped by more than 5% over 14 days

• More than three people complained about added friction without being prompted

• Hodman’s own use remained the only positive signal

This is what makes a pre-mortem so helpful: you get a clearer view of how your idea might fail and how to avoid wasting your time chasing it.

Four Files Made the Analysis Specific

Before you can run the pre-mortem analysis, you need to set up the project instructions. In the demo, we used Claude Cowork.

Hodman’s project instructions begin with a clear role:

You are my decision partner. When I bring you a decision, don’t cheerlead. Surface failure modes I haven’t seen and make the case for positions I have dismissed.

That instruction tells it what kind of help she wants. It allows the interaction to spark a disagreement.

Then she gives it four files:

1. Job To Be Done: What users hire the product for, what alternatives they have tried, how they measure success, and what they do not want.

2. User feedback: Exact quotes from interviews, support tickets, and messages, recorded with a date, source, and consistent tag.

3. Decision log: The decision, original verdict, kill criteria, reasoning, 30-day outcome, and lesson worth remembering.

4. Product anti-patterns: Rules created from earlier mistakes, including the incident or evidence behind each one.

The instruction asks Claude to disagree. The files give it a reason.

Without those files, Claude could still produce a generic list of risks. It might mention adoption, technical problems, or user confusion. Those answers can sound sensible while missing the specific decision in front of you.

Hodman built her own version so it could connect the feature to the user’s real goal, surface the feedback that challenged it, flag the “works for me” bias, and question whether the research matched the product.

If you want to get the same quality of results as hers, you might want to fill in the files that align with what you do and the kind of product or business you’re running. We’ll get to that tutorial later in this post.

But, Pre-Mortem Can Make Everything Look Scary

There’s one thing I want to highlight about the side effect of running a pre-mortem with AI.

When Dheeraj first used a pre-mortem skill, almost every idea came back looking dangerous. The analysis made him want to stop launching anything. I also have a similar experience on this.

He eventually changed how he used it. Instead of treating the output as a final go-or-stop decision, he used it to identify risks, mitigations, and things he should watch during a real test.

Hodman agreed. She has continued testing ideas even when Decision Studio advised against them. But what makes it different is that she understands all the risks that might happen and builds a plan to mitigate them.

After all, a pre-mortem is supposed to make you feel more prepared by understanding the bad things that could happen, rather than preventing you from making that decision.

How to Build Your First Pre-Mortem Agent

Building a full-fledged pre-mortem agent can be time-consuming and requires a lot of files about your product or business to give you a complete 360° analysis of your decision.

So, I wouldn’t go that far if this is your first time building it. Instead, start with these:

1. Evidence: Give Claude the user need and the feedback you already have.

2. Decision: Write down what you are considering, why now, and what being wrong would cost.

3. Challenge: Run the pre-mortem, red-team review, and decision memo.

4. Follow-up: Check what happened and save the lesson for the next decision.

That is the whole system.

Start by creating a Claude Project called Decision Studio. Open the Project’s custom instructions field and paste Hodman’s instruction:

Replace the two bracketed fields with your own details, then save the instruction. It will guide Claude in every new decision chat you open inside the Project.

During the Q&A, someone in the audience asked why this belongs in a Claude Project instead of a one-off chat. The answer was simple: because you want to keep repeating this process for any decisions you make in the future. If you don’t build context on the project, you’ll have to re-explain everything every time you want it to run a pre-mortem analysis. And that is time-consuming.

For the smallest version, start with the two files Hodman recommended:

• A Jobs To Be Done file explaining who you serve, when they use the product, and what success looks like

• A feedback log containing dated evidence from interviews, support requests, surveys, or user behavior

Your decision history can begin as an empty file. It becomes useful as you save decisions and return later to record what happened.

Before running the review, describe the decision in five fields in your prompt:

Decision:
Why now:
Evidence for:
Evidence against:
What happens if I'm wrong:

Hodman shared the complete Decision Studio template she demonstrated during the show. The download contains five files:

• A setup guide with the project instructions, five-field decision input, master prompt, and 30-day check-in

• A Job To Be Done template

• A user feedback log

• A decision log

• A product anti-patterns template

These are Hodman’s blank, reusable templates. Now, let’s explore on how to customize it for you.

Customize the Templates With Claude Cowork

You can fill in the four knowledge files manually. If you are unsure what belongs in them, Cowork can turn the setup into a guided interview.

Download and unzip the templates into a dedicated folder. Open Cowork in the latest Claude Desktop app, connect only that folder, and paste the prompt below:

This gives you a customized starting point while keeping the evidence honest. Once the four files look right, follow README.md to create the Claude Project and run your first decision.

Run the Pre-Mortem, Red Team, and Decision Memo

Once your files are customized and uploaded to the Claude Project or Cowork, open a new chat inside Decision Studio.

The prompt below uses a dummy product decision. Replace the example in the first five fields with your own information, then send the whole prompt:

The three parts serve different purposes:

1. The pre-mortem finds plausible failure modes.

2. The red-team memo makes the strongest case against your current thinking.

3. The decision memo turns both into a recommendation, a test, and conditions for stopping.

Treat the result as a way to support your decision‑making process. Review the output and make sure everything is grounded in real data from your business before you act on it.

How to Improve the Pre-Mortem Analysis Over Time

Your first pre-mortem will only be as useful as the evidence currently inside the four knowledge files.

The analysis becomes more specific as you maintain the decision log. After every review, save the decision memo in decisions.md, add the date, and upload the updated file back to the Claude Project.

After 30 days, reopen that entry and compare the kill criteria with what actually happened. Record the result, choose whether to continue, kill, or pivot, and write down what you learned. Then upload the updated decision log again so the next review can use it.

Over time, decisions.md becomes a record of:

• What you decided

• Why you believed it would work

• Which risks Claude identified

• What you chose to test

• Where you set the kill criteria

• What actually happened

• What the result taught you

When you bring Claude a new decision, it can compare the idea with choices you have made before. It can identify assumptions that keep returning, surface warnings you previously ignored, and point to tests or stopping rules that proved useful.

Every time you add a new completed decision, it gives the next pre-mortem more evidence to work with. The system improves because the history becomes richer and more honest.

Share

The Part I Would Keep

I asked Hodman whether the whole process needed such a structured prompt every time, because writing it in such a detailed way can be hard and time-consuming.

She said no.

The structure is useful while you are learning the method. Once the project has clear instructions and useful files, you can begin with a normal message:

I am thinking about adding this feature. Here is why. What am I missing?

Claude can still run the deeper review because the method and evidence are already there.

I’d also suggest turning this prompt into a skill so you can easily run it by triggering a custom slash command. That way, you don’t have to remember anything once the skill is built and running the way you intended.

That is the version I would want. I do not want another long prompt I need to find before making every decision. I want a small set of files that remembers what users said, what I tried, and which lesson I am in danger of forgetting.

The value of Hodman’s Decision Studio came from that record. Instead of giving generic advice, the AI knows more details about what you do and your business, so it can offer more grounded and helpful critique that’s relevant not only to your business, but also to your specific situation.

And honestly, that is a much better use of AI than asking it to confidently argue with you using whatever comes to mind.

Show Details

Show: One Shot Show

Episode: 20

Topic: Building a Claude Decision Studio for pre-mortems, red-team reviews, and decision memos

Hosts: Wyndo and Dheeraj Sharma

Guest: Hodman Murad, founder of Asaura AI

Live schedule: Wednesdays at 10:00 AM ET on Substack

Timestamps

• 00:03: Episode 20 introduction and Hodman joins the show

• 00:04: Hodman’s work, newsletters, and Asaura AI

• 00:06: The breathing-overlay feature and what beta testers said

• 00:08: Creating Decision Studio in Claude Projects

• 00:09: The “don’t cheerlead” project instruction

• 00:10: The four supporting files

• 00:14: Why the files make the pre-mortem specific

• 00:15: How beginners can start with repeated instructions

• 00:18: The two files Hodman recommends building first

• 00:23: The five-part decision input

• 00:25: Pre-mortem, red team, and decision memo prompt

• 00:29: Failure modes and a smaller test

• 00:31: Claude uses Hodman’s feedback and rules against the idea

• 00:34: The question Hodman now uses as a decision rule

• 00:35: Kill criteria and the final memo

• 00:37: The 30-day check-in

• 00:39: When pre-mortems create decision paralysis

• 00:42: Structured prompts versus normal conversation

• 00:46: Why Claude Projects make the process repeatable

Resources Mentioned

• Claude and Claude Projects: The main tool Hodman used to create Decision Studio. Projects support project instructions, uploaded knowledge, and separate chats.

• Decision Studio: Hodman’s reusable system for pre-mortems, red-team reviews, and decision memos.

• Decision Studio templates: Hodman’s five-file pack containing the setup guide, Job To Be Done template, feedback log, decision log, and product anti-patterns.

• Jobs To Be Done: The framework Hodman used to describe why someone uses Asaura and what result they are trying to achieve.

• Markdown files: The format used for product context, feedback, decisions, and anti-patterns.

• ChatGPT Projects: Mentioned as another project-based way to keep instructions and supporting material together.

• Claude Skills: Hodman and Dheeraj discussed using skills for reusable behavior across projects.

• GitHub: Dheeraj mentioned starting from a pre-mortem skill he found in a GitHub repository and adapting it.

• LinkedIn: Hodman showed a separate project containing brand, tone, hook, and image guidance for her LinkedIn activity.

• Feedback database: Hodman mentioned pulling product evidence from interviews or a feedback tool. The automatic transcript renders the product name unclearly, so verify it before listing a specific service.

• A/B testing: Recommended as a way to test the feature with a smaller group before a broader release.

• ADHD meditation study: Hodman referenced a study from India about yoga and meditation interventions for children with ADHD. The exact paper was not named during the session.

My post about taking Andrej Karpathy’s LLM Wiki idea and turning it into an AI Second Brain inside Obsidian has become one of the most popular posts I have published for paid subscribers.

A lot of you found that framework useful. You downloaded the starter kit, copied the structure, changed the categories, and started building LLM wikis around the things you care about. I loved seeing that because the original setup solved a problem I had struggled with for years. It gave all those articles, notes, and ideas somewhere to go, then let Claude build the connections I rarely had the patience to maintain myself.

I have been using my own version for a while now. The more I use it, the more I notice where the first version starts to break down. Here are three problems that kept appearing:

Problem 1: My Inputs Were Scattered Before They Reached the Wiki

The first limitation appears before anything reaches my wiki pages.

Every time I find something interesting on the internet, it never arrives through one neat input; it’s all scattered:

1. I find things on X and save them to my bookmarks.

2. I have articles and videos sitting in Readwise.

3. I watch long podcast conversations that contain five ideas I want to remember, plus a guest I will probably come across again.

4. Then I have my own scattered thoughts. Some are developed enough to save. Others need a conversation before I even understand what I am trying to say.

The original system could ingest a URL and generate connected wiki pages. But, it needed better ways to handle all these other inputs without forcing me to process each one manually.

So I started adding new paths into the Second Brain.

1. Podcasts now have their own flow. I can save a transcript through Obsidian, run one command, and let Claude identify the show, host, guest, and durable ideas before adding them to the wiki.

2. X bookmarks and Readwise saves go through a filter first. The system reads what I saved, compares it with what the wiki already knows, and helps me decide whether I should read it, think about it, ingest it, or let it go. If you’ve been using X and Readwise to save insightful content, you’re going to like this new workflow.

3. On the other hand, my own thoughts have a different path. I can use a Reflect command that asks me questions one at a time. It waits until I have worked through the thought before turning it into a page. The reason I do this because a personal reflection should sound like something I actually believe, not a polished lesson Claude invented from one unfinished sentence.

Then I ran into a second limitation as the wiki grew.

Problem 2: The Wiki Became Harder to Search as It Grew

I had given Claude a folder full of pages, but whenever I asked it questions about my second brain, it still depended on whether it could retrieve the right context at the right moment.

In the first version, Claude started with index.md, guessed which page titles looked relevant, and used tools like Grep to search for matching words. Grep is a command-line tool used to search for specific text patterns within files. It can tell the agent which files contain a given string, but it does not tell the agent which five passages matter most to the question.

That difference becomes expensive once the wiki reaches 100 pages or more. Claude can open a large pile of files and spend more tokens reading them, or it can make an argument from the smaller set it happened to find. A page can also use completely different words from my question, leaving Grep with nothing useful to match.

Artem Zhutov's QMD breakdown helped me put this problem into clearer words. In his demonstration, Claude's normal file search took around three minutes and returned 300 files. QMD returned a much smaller, more relevant set almost immediately.

I learned about QMD through Tobi Lütke, the CEO of Shopify. He built QMD, a local search engine for notes, documents, transcripts, and knowledge bases, using Qwen3 with LoRA.

QMD ranks exact keyword matches, finds ideas expressed in different words, and reranks the candidates before Claude opens the files. The search models run locally on my computer. Claude can search the wiki, the original sources, and full podcast transcripts, see a short list of promising passages, then read only what it needs.

This is how the architecture looks:

This gives Claude a more practical form of memory. It spends fewer tokens opening weak matches and has a better chance of finding the page I forgot existed. The underlying notes and local index can also keep working if I use another agent later.

But the goal I want in this battle of Grep vs QMD is to give the agent a much better starting point than simply guessing from an ever‑growing index.

Problem 3: What Was I Going to Make From All of This?

Once I had captured all this material, filtered it, connected it, and made it searchable, what was I going to do with it?

I didn’t want the Second Brain to become another place where all my lessons and insights from the information I’ve consumed waste away. I wanted it to bring old ideas back, help me work through tensions in my own thinking, and eventually give me something I could use.

That led to the final pieces of the upgrade:

• A Weekly Review command resurfaces older connections I did not remember to search for.

• A Draft command searches what the wiki already knows, gathers the evidence and counterarguments, shows me what is missing, and helps me turn the material into a writing brief. It only writes the draft after I approve the direction.

The full system now follows this path:

In this post, I am going to show you how each stage works, how to set up QMD and Readwise, how the podcast, X bookmark, reflection, and drafting commands fit together, and how to add the whole upgrade to the LLM Wiki you already built.

By the end of this post, you’ll have a complete second-brain folder that you can either use as-is or modify for your topic of interest. It contains all the custom commands I use and cover in this post.

Whether you run this on Claude Code, Cowork, or ChatGPT Work, it will work.

I’m convinced this might be the most comprehensive post on building your AI second brain at an advanced level, and I’m sharing it all right here in this post.

So buckle up—this is going to be a long one! 🔥

Saved Material Starts Where My Attention Already Goes

As I mentioned earlier, my old AI second brain workflow was limited to capturing only URLs from information I found on the internet, usually online articles, because Claude could fetch them easily.

But the way I consume information is scattered.

I hear something during a podcast. I bookmark a post while scrolling through X. I send a long article to Readwise because I want to read it later. Then a thought comes to me while I am walking, having dinner, or talking with someone.

Each one contains a different kind of material. They also need different treatment before they belong in the Second Brain.

These are the four entry points I use now.

1. Podcasts Through Obsidian Web Clipper

Podcasts have become one of my biggest sources of ideas. A good two-hour conversation can introduce me to a new person, challenge something I already believe, and give me several threads I want to explore later.

Saving the episode link is rarely enough. By the time I return to it, I have forgotten which part actually important. A title like “14 Patterns Behind the World’s Greatest Minds” tells me almost nothing about the specific idea I wanted to keep or where it appeared in the conversation.

Obsidian Web Clipper gives me a better starting point. When a podcast has a transcript available, I can save the full transcript into the Clippings/ folder in my Second Brain. That folder now works as a visible queue. Anything sitting at the root is waiting to be processed. Once an episode has been handled successfully, it moves into Clippings/ingested/.

I can open the folder and immediately see whether I have a podcast waiting. I do not need another tracker to remember what I have processed.

The transcript also preserves the original conversation. Later, when Claude creates a condensed source note or a wiki page, I can still trace an idea back to the timestamp where the guest said it.

But you don’t need to use Obsidian Web Clipper if you don’t want to, you can also use Readwise Reader, which supports videos, to access the podcast, as we’ll get into soon.

2. The Things I Bookmark on X

X is where I come across many of the new tools, arguments, experiments, and workflows I want to look at again.

Bookmarking takes less than a second. I save it and keep moving.

The problem usually appears later. My bookmarks contain everything together: long X Articles, thoughtful threads, product launches, short opinions, AI tutorials, and posts full of hype that promise nothing tangible.

All these become wasted if I don’t have a way to process them together.

This is where the new upgrade comes in. It gives those bookmarks a path into the Second Brain without requiring me to copy every link into Obsidian or Claude manually.

Claude can pull a recent batch, read the complete post or article, and compare its actual claim with the pages already in my wiki.

I will show you that command in the next section. The important part here is that X remains where I discover and save things. The Second Brain handles what happens after the save.

3. Articles, Videos, and Newsletters in Readwise

Readwise is a slightly different input because it already contains more information about how I consume information on the internet.

It knows what I saved, whether I opened it, how far I read, and which passages I highlighted. In fact, Readwise tracks my reading progress and provides clues about what I found useful. And the best thing about Readwise is that it handles multiple content formats—whether it’s articles, videos, podcasts, tweets, PDFs, emails, etc.

I might have a long article sitting unopened in my Reader inbox. That does not mean Claude should immediately summarize and ingest it for me. Sometimes the best next step is for me to read it first. If I have already read most of it and highlighted three sections, the system can pay attention to those passages when deciding how the document relates to the wiki.

The new Readwise connection lets Claude read the inbox and the full documents without moving or deleting anything. Readwise stays as my reading and saving tool. The Second Brain helps me decide which documents deserve more attention and what they might add to the ideas I already have.

Later in this post, I’m going to show you how you can connect your agent to the Readwise CLI.

4. My Own Scattered Thoughts

The final input does not come from the internet at all.

Sometimes I have a developed thought I can write down clearly. Sometimes I only have one sentence or short aphorism, like “hard work is overrated” or “AI is a reflection of its human.”

I know something is there, but I have not worked out the argument yet.

I can drop the thought into inbox/ folder without choosing a category, adding tags, or formatting it. The folder is designed for quick capture. Claude can help classify and process those notes later.

For thoughts that feel more personal or unfinished, I can start /reflect instead. Claude asks me one question at a time and follows what I actually say. Nothing becomes a wiki page until I tell it that the insight is ready to save.

To do this, you’ll need to use Obsidian Sync for $5/month so you can start capturing your fleeting thoughts on mobile and have them sync instantly to your local computer. Then, once you’re in front of your computer and ready to think deeper, you can start the ingesting process.

You can watch my recent One Shot Show session, where I demonstrated how ‎⁠/reflect⁠ works.

That gives my own thinking a proper place beside articles and podcasts. The wiki can contain what other people taught me, alongside the beliefs, questions, and experiences I am still working through myself.

The four paths now look like this:

Podcast transcript -> Clippings/
X post             -> Bookmarks
Article or video   -> Readwise Reader
Personal thought   -> inbox/ or /reflect

I built all these paths systematically before ingesting them into wiki pages. But all these processes come from the natural way I consume information, so it doesn’t really add more work for me. I can just live my life normally, and every once in a while during the week, I only need to process the new information in my Obsidian into something worth saving—something that gives me more insight into any information I consume.

A saved item is a signal that something caught my attention. The next stage helps me decide what kind of attention it deserves.

Subscribe now

Filter What Each Save Deserves

In the first version of my Second Brain, I made the important decision before I ran the command.

I chose an article because I had already read enough to know it belonged in the wiki. Then I copied the URL and asked Claude to ingest it.

X bookmarks and Readwise changed that.

Saving something in either tool is fast. Sometimes I save because the idea is genuinely important. Sometimes the title catches my attention and I want to investigate it later. Sometimes I am simply curious for five seconds.

Those are all valid reasons to save something. They are not equally good reasons to turn it into permanent knowledge.

I needed a decision layer between saving and ingesting.

The filter asks one question about every item:

“Does this contradict, complicate, or add meaningful evidence to something already in my Second Brain?”

That question creates four possible outcomes:

1. Drop: The item adds nothing useful. It might repeat an idea I already captured, announce a tool with no deeper argument, or point to something too thin to preserve.

2. Read: The material looks substantial, but I have not read it yet. The honest next step is for me to read it before Claude turns someone else’s argument into part of my knowledge base.

3. Think: The item touches something I am already working through. It might challenge one of my pages or open a personal question that deserves reflection.

4. Ingest: The source contains a developed argument with enough substance to add to the wiki.

The filter process only recommends the next step; it doesn’t automatically create a reflection page or generate a new wiki page. I still decide what I want to do with it.

That boundary is important to me because I want the Second Brain to help me make better choices without quietly making those choices for me.

To put it simply, I want to make sure that I’m still sitting in the driver’s seat, not my AI. I want to make the whole decision so it sharpens my thinking instead of dulling it over time.

Filter My X Bookmarks With /triage-bookmarks

Let’s dive into how my X bookmarks and ingest process, which is called /triage-bookmarks actually work.

Once X is connected, I can run:

/triage-bookmarks 20

The number is optional. It tells Claude how many recent bookmarks to review. I used 20 for my first live test. You can also say something like “last week” or “the last 7 days.”

The command starts by checking a small ledger of bookmarks it has already judged. Every X post has its own ID, so Claude can skip anything from an earlier run instead of spending time debating the same bookmark again.

It then pulls the new bookmarks and reads the actual content.

For every bookmark it can read, Claude turns the post into a plain-language claim and searches my Second Brain with QMD. It looks for the pages most likely to relate to that claim, then checks the relationship.

Does the post repeat something I already know? Does it sharpen an existing page with a more useful mechanism? Does it pull against one of my beliefs? Does it introduce a substantial new argument? Or did I bookmark a product announcement that will probably mean nothing to me in two weeks?

This is where the command became more useful than a normal bookmark summary.

A summary would organize all 20 posts and make the pile bigger. /triage-bookmarks is allowed to say that most of the pile does not deserve another step.

Here is what happened when I ran the triage bookmark on my latest 20 bookmarked posts on X:

20 bookmarks reviewed
17 dropped
2 marked Think
1 recommended for Ingest

Eighteen of the 20 bookmarks were about AI tooling. Model releases. New skills. Product demonstrations. Claude commands. ChatGPT Work. Grok 4.5. GPT-5.6. Motion graphics. Design tools.

My bookmarks showed a week of trying to keep up with what was changing. My wiki showed something different. Almost none of those tool updates had contributed to the ideas I was actually developing.

That gap became the real finding. The things that catch my attention while scrolling and the things that deepen my thinking overlap much less than I expected.

Only one of the 18 AI-related bookmarks survived, and it survived because it contained a real argument rather than another announcement.

The Two Posts That Made Me Think

The first Think result came from Amanda Orson. Her post asked a simple question: what will remain true over the next ten years?

That collided directly with my About Me page. A lot of my thinking is built around agency, taking an idea from your head and making it real. Amanda’s post added another question: where should that agency be directed?

Her advice to build around things that do not change also connects with my page about Light Mode and Heavy Mode. Heavy work is usually slow and deliberate, such as writing books or building companies. Light work is fast and iterative, such as tweets, short-form content, or hot takes. Here’s the Light vs Heavy Mode that my page referred to:

Working Theorys

Make Something Heavy.

We instinctively tie weight to value…

Read more

a year ago · 2583 likes · 259 comments · Anu

The second Think result was an old Tim Ferriss post about dreamlining.

This one found a genuine hole in my wiki.

I already had a page called “You Can’t A/B Test Your Life.” The central idea is that life cannot be run in parallel. Once you make a decision, the useful move is to commit instead of constantly comparing it with the paths you left behind.

Ferriss starts one step earlier. What happens when you cannot clearly articulate what you want in the first place?

His method is mechanical. Write down five things you want across a six or twelve-month timeline. Turn vague states like “being confident” into something you can do. Then take one small step now.

My wiki had a lot to say about commitment after making a decision. It said very little about how we form the desire before that decision.

That’s why the command suggests that I think about this if I want to add it as part of my wiki pages, so it can complement or add tension to my existing pages.

The One Ingest Candidate

The only Ingest recommendation was George Sivulka’s “You Just Hired a Million Bad Employees”.

The post framed large-scale agent deployment as a management problem. That put it in direct conversation with my existing page about the Orchestration Tax, where I argue that human attention becomes the serial bottleneck when too many agents need review.

The command did not treat the shared topic as enough. It recommended reading the full piece before committing it to the wiki. If the article contained a developed argument about defining work, evaluating agents, and managing the system, it could materially extend the existing page.

Ingest is a recommendation to inspect the source more closely. It is not automatic approval.

What Got Dropped

The 17 drops fell into a few clear groups.

1. Model and product announcements: ChatGPT Work, Grok 4.5, GPT-5.6, Claude /checkup, HeyGen motion graphics, and Open Design. Useful updates, but mostly changelogs.

2. Skill releases: Apple design, animation-improvement skills, and another skills tutorial. These might be useful to install or test. They gave me little to think about.

3. Lists for someone else’s situation: executive AI questions, build lists, and generic resources without a developed argument.

4. Pointers and reactions: quick demonstrations, reactions to product news, and posts pointing toward someone else’s work.

The filter also surfaced one decision that was harder to make.

I had saved a David Senra post about Breville’s “A Bit More” button. The design principle was genuinely useful: observe what people repeatedly do, then design around that behavior instead of relying only on what they say.

David already had a page in my wiki, but the idea collided with nothing else. I had no active product-design or customer-research thread for it to sharpen. Creating a link through the author would have made the wiki look more connected without adding more value to the topic I care about.

The command dropped it and flagged it as the arguable call. I could loosen the rule later and allow a strong new idea to start its own thread. For this run, I kept the bar where it was.

After reporting the results, the command records every verdict in inbox/x-bookmarks-processed.md:

Date | Post ID | Author | Verdict | Why

That file is working state. QMD does not index it, and Claude does not treat the verdicts as knowledge. It exists so the next run knows what has already been reviewed and, over time, I can see which bookmarks actually became reflections or wiki pages.

Filter My Readwise Inbox With /triage-readwise

Readwise needs a slightly different filter because it knows more about what I did after saving something.

When I run:

/triage-readwise yesterday

Claude pulls unjudged documents from my Reader inbox. With CLI connection, it can see the document type, reading time, how far I progressed, and any highlights I created. The command then reads the full source before deciding what deserves another step.

The extra signal here is my reading behavior, because Claude can see how far I’ve progressed on specific content formats. Since Claude can read the entire piece, it can compare my progress against completion. In the end, it can suggest that I either read it to the end or drop it entirely if I already have a sharper page in my Wiki instead.

My first live run found only three saves, all from July 21, 2026:

3 documents reviewed
2 dropped
1 recommended for Read
0 completed

The one survivor was the only piece I had not opened.

Read: “Dreams of Stability” by Anu.

Working Theorys

Dreams of Stability

Everyone says they hate the question: What do you do? It’s cliché and reductive. But nobody stops asking, and nobody stops answering. Because the answer is never just about what you do. It’s about what people think you’re worth, and what you want people to think you’re worth…

Read more

7 months ago · 357 likes · 39 comments · Anu

The essay argues that stability has become a status symbol in tech. As AI makes skills easier to replace, the fallback options that once made risk feel survivable may be disappearing.

That challenges my existing page on Uncertainty Tolerance.

But I was still at 0 percent on the essay. The right next step was to read it, then use /reflect to decide whether it changes my view. Ingesting it first would have left me with a neat summary of an argument I had never formed an opinion about.

The two drops were quicker calls:

1. “How to think” by Craig Perry: I was 30 percent through it. Its argument about judgment and context was already covered more sharply in my Independent-Mindedness page through Paul Graham’s work.

2. Matt Pocock’s Agentic Engineering Workflow: I was 70 percent through the video. Its main claim, that AI handles more tactical programming while human skill sets the ceiling, already appeared across AI as a Mirror for Thinking, Use Agents or Be Left Behind, and Learn to Ship.

Two of the three saves were about AI and tech, and both were dropped. That does not mean the filter penalizes AI. It means my Reader inbox was drifting toward the same topic, while my wiki already held stronger versions of those ideas.

This tiny first run showed why the Read verdict matters.

The command records every verdict in inbox/readwise-processed.md so it does not review the same documents next time. It also leaves Reader untouched. Nothing is archived, moved, tagged, deleted, or marked as seen.

Now that you’ve seen how many filters I had to put on my saved materials before they deserve their own place as wiki pages in my second brain, you can see why I’m so selective. I don’t want to include anything I don’t fully understand, so these filters are a required part of the whole system.

Every saved material needs to go through a review, but only the useful ones continue. Some deserve a dedicated wiki page. Others deserve my attention first.

Now, let’s dive into how to install Readwise CLI and connect it to your agent.

How to Set Up Readwise

Readwise is the only new source in this workflow that needs its own connection. I use the official Readwise CLI mainly for two reasons:

1. It is more token-friendly. Claude can request a short list of documents first, then open the full text only when it needs to judge a specific item.

2. It connects directly to the Readwise API. Once I log in, Claude can retrieve my Reader documents, reading progress, and highlights through specific commands. That connection also remains useful when I want the agent to do something outside the main second-brain workflow in this post.

Install the Readwise CLI

Open your terminal and run:

Read more

Last month, I shared the AI tools I actually use to build and grow AI Maker. Writing that post forced me to admit something: choosing the tools was harder than finding them.

There is always another AI tool that looks promising. I have tested plenty that seemed useful for a day, then quietly disappeared from how I work. I have also paid for tools I barely used, then switched when something else fit the job better. The difficult part is deciding which ones deserve a real place in your work.

That is why I invited back. His previous guest post, The Future of Writing Is Perspective, explored how writers can use AI without losing what makes their work worth reading.

Market Smarter with AI

Practical AI tools for time-poor marketers. Subscribe and get my free 20-prompt starter pack.

By Nick Woodford

Over at Market Smarter with AI, he puts that thinking into practice by showing how he uses Claude as an editor, why he asks a chatbot to write his design briefs, and how he turns long talks into useful infographics. He starts with the work, then decides how AI should help.

In today’s guest post, Nick shares seven questions he uses to evaluate a new AI tool. He shows what passed, what did not, and how he chose between Claude, ChatGPT, and Gemini. I like this framework because it gives you permission to move on when a tool no longer earns its place.

If your AI setup keeps growing but your work is not getting easier, this is a useful filter.

Here’s Nick.

Hello 👋🏻

Back in November 2022, I opened ChatGPT for the first time and genuinely didn’t know what to do with it.

Within weeks it had become one of the first tabs I opened each morning. I couldn’t imagine working without it.

I can’t remember the last time I logged in.

That isn’t a criticism of ChatGPT. It’s just what happens when you treat AI tool adoption as a process rather than a commitment. Your needs shift. Better fits emerge. You move on.

The problem most marketers face isn’t finding AI tools. There are thousands of them. The problem is having a reliable way to work out which ones deserve your time and which ones are just noise.

After three and a half years of testing, I’ve landed on a framework that takes most of the guesswork out of it.

The Seven-Question Tool Evaluation Framework

Run any new AI tool through these questions before it earns a place in your workflow.

1. Does it solve a problem I actually have?

Before you test anything, name the job you need done. Not “I want to use more AI” but something specific: I spend two hours summarizing research every week and it’s killing my Friday afternoons. I need a better way to repurpose webinar recordings. My slide decks take forever and always look the same.

If you can’t name the problem before you open the tool, you’re browsing, not evaluating. Browsing is how you lose an afternoon.

2. Is it worth even testing?

Not everything that lands in your inbox deserves a trial. I only pay attention to a tool when at least one of these is true: it comes recommended by someone whose workflow I respect, it solves a specific problem I’ve already named, or it keeps appearing from multiple independent sources. If three different people mention the same tool unprompted, I take notice.

That last point only works if your sources are worth trusting. I used to follow dozens of accounts and newsletters and retained none of it. Now I rely on a small handful:

• Superhuman newsletter: a daily AI digest without the noise. The only newsletter I read every weekday.

• Matt Wolfe (YouTube): weekly roundups aimed at people who use AI but aren’t developers. He tests tools live on screen, which beats someone just describing them. I watch at 1.5x.

• The Verge: not AI-specific, but when something genuinely gains traction they cover it with more scrutiny than most.

• Word of mouth: still works. Three unprompted mentions and I take notice.

The goal isn’t to catch everything. It’s to catch the things that matter.

3. How do I run the first real test?

I watch a short tutorial first, usually on YouTube, to understand how the tool actually works before I touch it. Then I find a free trial and immediately apply it to a real task from my current workload, not a made-up scenario designed to make any tool look good.

The only honest test is a live one.

4. What signals am I looking for?

In that first session, I’m asking one question: did this make something genuinely easier, faster, or better? Not in theory. Right now, with real work.

The signals I’m watching for: does it reduce a step I was doing manually, does it produce output I’d actually use without heavy editing, and does it feel intuitive enough that I’m not constantly consulting a tutorial to move forward.

5. What makes me reject it quickly?

If the UX isn’t clear within the first session, I move on. I don’t have the patience to decode complex tools, and I’ve learned that anything genuinely useful shouldn’t require a learning curve just to get started.

I also walk away fast if the output needs so much correction that I’m doing most of the work anyway. That’s not a tool. That’s extra admin.

6. What makes it worth paying for?

I never upgrade during a free trial. I only consider paying once a tool has already proven its value in real work, and even then, it needs to clear one more bar: does it do something that the tools I’m already paying for don’t?

If the answer is yes, it’s worth it. If I’m paying for overlap, I’m just accumulating subscriptions.

7. Would I use it without thinking about it?

The tools that genuinely stick are the ones that quietly become part of how you work. You stop noticing them, the same way you stop noticing a good chair. If I’m still consciously deciding to open something three weeks in, it hasn’t earned its place.

Subscribe now

One Tool That Passed. One That Didn’t. One That Won a Straight Fight.

Passed: NotebookLM

I had a specific problem: too many long documents, not enough time to read them properly before meetings or projects. NotebookLM’s ability to ingest multiple sources and let me ask questions across all of them directly addressed that. The first real test took about twenty minutes and produced something I actually used. I’ve never considered dropping it.

Didn’t pass: a browser extension I tested earlier this year

I won’t name it because the category has several versions and this isn’t a verdict on all of them. The promise was AI-powered page summarisation and research support while browsing. In practice, the summaries were shallow, the interface kept pulling my attention away from the actual page, and after four days I realised I’d gone back to doing the same task manually without noticing. That’s the clearest rejection signal there is: you forget to use it.

A straight fight: Claude vs ChatGPT vs Gemini

This one didn’t start with a new tool. It started with a problem I’d been quietly tolerating.

Most of my week is writing. Articles, newsletters, emails, YouTube descriptions, Instagram captions, website copy. Copywriting is the thing I’m actually good at, which makes it an awkward job to hand over. I don’t need something to write instead of me. I need something that helps me write more of what I’d have written anyway, faster.

So I gave the same real task to all three: one live piece, same brief, same source notes, same deadline. No test prompts, no clever benchmarks. Just the thing I actually had to write that week.

The signal I ended up watching for wasn’t quality in the abstract. It was how much of me survived the draft. ChatGPT was fast and reliable and flattened everything into the same reasonable, faintly corporate register. Gemini was strongest at pulling research together and weakest at holding a thread once the piece got long. Claude read more like an editor than a replacement: it kept my voice, pushed back when something was weak, and left me with a draft I was editing rather than rewriting.

Nothing failed on question five. The UX was fine everywhere. It came down to question four, and specifically to the version of it that matters if writing is your craft rather than your chore: does the output need so much correction that I’m doing the work anyway?

Then question six finished it. Paying for all three would have meant paying for overlap, so I cancelled the other two rather than quietly stacking subscriptions. Three weeks later I noticed I’d stopped choosing, which is question seven answering itself.

When tools are genuinely close, the framework stops being a pass/fail gate and becomes a tiebreak. And the tiebreak is almost always fit, not features.

What’s Currently Making the Cut

A framework is only convincing if it produces something. So here’s what has actually survived mine right now, with what each one is for. This is a snapshot, not a permanent list. Ask me again in a year and it’ll look different, which is rather the point.

• Claude: writing and thinking. Replaced ChatGPT and Gemini in my daily work not because it’s dramatically different, but because it suits the way I write. Sometimes adoption really does come down to fit.

• Claude Design: turning rough ideas into visuals and prototypes without leaving the tool I’m already thinking in. It’s become a daily habit rather than an occasional one.

• NotebookLM: reading across long documents before meetings, when there’s more to get through than time to do it.

• Descript: video and audio editing, without needing a video editor’s brain to use it.

• Canva: quick visual design and social assets when I don’t need to start from scratch.

• Apple Voice Memos: recording meetings and letting it auto-transcribe them, filed by date and location. I read back through, then drop the notes into Claude to draft follow-ups, pull out the interesting points, or tidy them up for colleagues.

• Notion: notes and knowledge management, the place everything eventually lands.

• LMArena: comparing how different models answer the same prompt, useful when I’m deciding which one to trust for a task.

One final thing

There’s a strange guilt that comes with dropping a tool you once liked. You invested time learning it. You might have recommended it to someone. Moving on can feel like admitting something.

It isn’t. Your workflow will keep getting better if you let it.

Ilia has been on the show before where we talked about Claude Skills. He writes Prosper and spends a lot of time testing AI workflow systems. He came in with a list of the new things he has been using in the app, then showed us a loop he runs on his posts.

Before we get into the session, a quick introduction.

Ilia writes Prosper, a newsletter with practical AI workflows, prompts, and guides you can try the same day. He has also written for AI Maker several times before, including pieces on weekly SEO brief, AI memory, when not to use AI, Claude in Chrome, and our Claude Q1 update breakdown.

Prosper

Every week, practical AI workflows, prompts, and guides you can put to use the same day - no matter your technical background.

By Ilia Karelin

In this session, he joins us to test the new Claude Code app updates. If you want more from Ilia, these are a good place to start:

1. AI Releases Are Accelerating...Even More? on why better models and better tools are changing the kinds of projects he is willing to attempt.

2. How To Build Your First Claude Code Artifact That Lasts for a practical walkthrough of turning files into a useful, shareable tool.

3. I Built My Own Local WisprFlow: Free, Offline, and Limitless — Here’s How to Build Yours

As you may know, I’ve been using the Claude Code app more and more. That’s why I think this session is important: there are two groups of people I want to address.

• The first are those who think Claude Code is only for developers

• The second are those who think the Claude Code app is just sluggish and laggy

While the latter was true a few months back, trust me, the desktop app has changed a lot since I last spent time with it. It’s now more user-friendly and intuitive for most typical knowledge work.

We covered multi-pane sessions, permissions, the built-in browser, artifacts, routines, and loops.

Here is what we looked at.

Claude Code App Multi-pane view

The first feature Ilia showed was the multi-pane view.

You can drag sessions from the sidebar into the main window and put them next to each other or stack them. Both can run at the same time.

If you love to run bigger tasks that require more time for the agent to finish, this feature might be suitable for you, letting you spend more time deploying more agents while the rest are still working.

But we also talked about the part that does not show up in screenshots of people running ten agents at once: it gets confusing quickly.

I said I usually stay around two to four agents at a time. Dheeraj said his work-in-progress limit is two. Ilia said that once he goes past two sessions, he starts losing track of what he asked each one to do.

So, while multi-pane view can be useful, it is not an invitation to launch as many agents as possible, even though I’d agree that it is a cleaner way to keep an eye on the few tasks you are actually running.

Just like Codex, new Claude Code app makes activity easier to track. You can see which sessions are still working and which ones are waiting for you. I still like opening Visual Studio Code when I need to see a lot of files, but I can see why this view would be useful for ongoing agent work.

Another tip I want to share is that, since I work on multiple folders at once, I like to group the agent sessions in the left sidebar by project so I can clearly see which agents are running on which projects. This gives me a helicopter view of all progress across agents and folders.

Permissions Still Need a Decision

We also looked at the different permission modes in Claude Code.

Ilia moves between auto mode and bypass permissions. Bypass permissions is the version where the agent can keep going without asking you for confirmation on the usual actions.

In the session, we were debating Auto Mode versus Bypass Permission to figure out which one is truly the YOLO mode. The answer was Bypass Permission.

Dheeraj shared his experience of what makes Auto Mode different from Bypass Permission. In Auto Mode, Claude Code can carry out much of the work, but it stopped when it was about to deploy a website change to production. It asked for explicit permission before taking that step.

Ilia saw something similar while updating a client’s React Native app. Claude helped investigate package versions and GitHub issues, then stopped before a potentially destructive change.

I think Anthropic is doing the right thing by having some guardrails with Auto Mode. I do not need a confirmation for every small file edit. I do want a moment to look when the action could affect a live site or remove something important.

But in case you’ve never used Claude Code before, I’d suggest starting with Manual mode, then moving to Accept Edit mode before using Auto mode and Bypass Permission.

Subscribe now

The Built-In Browser Is the one I love the most

The browser was probably the feature that became my favorite. And I think Anthropic copied this from Codex.

Ilia opened a website he had been working on and showed the live preview alongside the Claude Code chat. Instead of switching between the terminal and a separate browser window, he could see the changes as the agent made them.

One of the most important parts of having the built-in browser was the feedback flow.

You can select an element on the page, draw or annotate the area you want changed, then add that screenshot to the chat. In the demo, Ilia selected a button and asked Claude to change its color.

That is a much easier way to explain a visual problem than trying to describe it verbally. You can point to the thing you mean.

The browser can also keep you signed in to services like Substack, X, or LinkedIn. I have used this kind of browser access to let an agent help set up scheduled posts. We also talked about using it for research or browser-based tasks where you want to watch what the agent is doing.

I would still be cautious with anything that publishes, buys, or sends something. But being able to see the browser action is better than handing the task to an agent and hoping it made the same choices you would have made.

Artifacts for Things You Want Others to See

Next, Ilia showed the changes to artifacts.

Essentially, an artifact is an HTML file hosted on Anthropic’s cloud service so other people can access it.

He built a small Prosper operations dashboard by pulling numbers from Substack. He can now create artifacts through Claude Code, open them from the app’s sidebar, and keep editing the same shared version.

That makes artifacts more useful for dashboards, simple tools, and presentation-style outputs. Dheeraj said he uses them for reporting and cohort presentations because they are easy to share with other people.

Recently, Anthropic improved Artifacts so you can now connect them to MCP. This means you’re able to pull data from other apps and take action. I think this is going to benefit people who want to run real-time dashboard reports that can be accessed by many people.

In my case, just like Dheeraj, I use it for my Agentic Academy presentations as well as for generating my weekly Google Analytics reports for my Substack.

For those of you who want more visual options of your work that you want others to see, artifact is built for this case.

Routines for Recurring Jobs

One feature we only touched on briefly was Routines.

If you have a job you want AI to keep doing on a schedule, whether that is daily or weekly, it should probably be a Routine.

You could ask Claude to check your emails and give you a to-do list. You could have it check your calendar before the day starts. In my case, I have one Routine that schedules a post and another that generates a weekly dashboard for my Substack.

Anything that has to happen on a schedule is a good candidate.

Routines are scheduled jobs, so they decide when work starts. Because they run in Anthropic’s cloud environment, they can keep working when your laptop is closed. Your morning email and calendar check can be ready before you open your computer. A scheduled post or weekly dashboard does not depend on you remembering to start it.

They can also start from an API call or a GitHub event, not only a schedule. That opens up more useful jobs later, such as checking a pull request when it changes or creating a report when another system sends an alert.

Ilia’s SEO Loop

Loops is a different beast. They describe what happens inside one task: the agent evaluates the work against a condition, makes another pass if needed, and stops when it reaches the condition you set.

Ilia’s biggest loop is an SEO review he runs on each post.

The loop reads the post alongside a small set of SEO files: title and subtitle guidance, research, metadata, internal links, Google-related notes, and an audit file.

Then it checks the post against the conditions he set. In the demo, it found missing metadata, a URL slug, Substack tags, and internal links. The first round failed, explained why, and moved to the next round with suggested fixes.

Ilia capped the example at three rounds. At the end, the report shows what it checked, why something passed or failed, and what would need to change to reach the target score.

I liked that he asks the loop to explain its reasoning. If it only gives you a final score, you do not learn much about what keeps going wrong in your drafts.

The loop is also running on something that already exists. It has a post, a set of rules, and a clear set of checks. That makes it easier to judge the output than asking an agent to start an entire project from scratch and make all the decisions alone.

I said I would use loops on work that is already around 60–70% complete. If you want to learn more, I have a full guide on running loops. You can check it out here.

If you want AI to handle the prompting for you so you can focus on more important work, Loops might be for you.

Share

What I Would Actually Try First

In case you’ve been wondering whether Claude Code might be useful for non-coding work, I highly encourage you to give it a try. I’ve written a full guide on how to start your journey with Claude Code:

1. The Complete Guide to Build Your Personal AI Operating System With Claude Code

2. From Blank Folder to Working System: How to Set Up Any Project in Claude Code

3. How an Agent Harness Made My Claude Code Setup 10x More Reliable

But if you have been using Claude Code on terminal but hesitant to move to app, you also need to shift because the app had just gotten better.

Based on what we have talked about so far, a few things from this session feel worth testing:

1. The browser for visual changes. If I am working on a page, I want to see whether selecting and annotating the issue is faster than writing out a detailed explanation.

2. The multi-pane view for two active tasks. I would use it when one agent is doing research or a longer edit and I have another job to handle.

3. A small review loop on an existing draft. I would start with something that already has clear rules, such as a post that needs metadata and internal-link checks. I would keep the number of passes small and read the report before trusting it more broadly.

The app updates are making Claude Code feel less terminal-only than before. I can see Anthropic is going to invest a lot of their time to move people to the desktop app because terminal is too daunting for the rest of people that could find huge benefit using Claude Code.

So, if there’s one practical takeaway I can share with you today, it’s this: start experimenting with the Claude Code app and learn its full capabilities to handle any type of work you throw at it.

That’s all for today.

Have fun experimenting with the Claude Code desktop app!

Show Details

Show: One Shot Show

Episode: 19

Topic: Claude Code app updates, artifacts, routines, and loops

Hosts: Wyndo and Dheeraj

Guest: Ilia, writer of Prosper

Live schedule: Wednesdays at 10:00 AM ET on Substack

Timestamps

• 00:00: Episode 19 intro and Ilia joins the show

• 05:48: Running sessions side by side and the human limit on parallel agents

• 10:23: Auto mode, bypass permissions, and when an agent should stop for approval

• 14:06: Claude Code’s in-app browser and live previews

• 16:35: Selecting and annotating a page element for an agent to change

• 25:46: Artifacts for dashboards, sharing, and editable outputs

• 31:56: Routines and scheduled work

• 33:38: What loops are for and why they are becoming more practical

• 39:52: Loop anatomy: generate, evaluate, retry, and pass

• 42:35: Why a clear definition of done matters

• 44:34: Dheeraj’s travel-site maintenance loop

• 46:09: Ilia’s SEO-loop demo

• 52:18: Reading an SEO-loop report and using failures to guide the next pass

• 53:55: Why loops work best on work that already exists

• 54:31: Goals, stop conditions, and avoiding wasted usage

Resources Mentioned

• Claude Desktop and Claude Code: The main app and agent environment discussed throughout the session. The team showed split sessions, permissions, browser preview, artifacts, skills, commands, loops, routines, and goals.

• Claude Code Browser: The in-app browser Ilia used to preview work, stay signed into sites, select elements, and add visual annotations to a chat.

• Claude artifacts: Shareable, editable outputs such as dashboards and presentations. The session also discussed connecting artifacts to MCP-powered data.

• MCP and Substack MCP: Connection methods discussed for pulling data, including a Substack dashboard example.

• Codex and ChatGPT: Compared briefly with Claude’s app design and agentic workflow experience.

• Visual Studio Code: Dheeraj’s preferred place to inspect files and run terminals alongside agent work.

• Cursor, Windsurf, Google AI Studio, Antigravity, and Devin Desktop: Other development environments or AI coding tools mentioned while comparing browser and file-viewing experiences.

• Chrome DevTools and Playwright: Earlier ways the team used to help agents inspect websites.

• Expo and React Native: Mentioned in Ilia’s example of updating a client mobile app and checking package compatibility.

• GitHub and macOS beta: Mentioned as part of that package-update troubleshooting example.

• Substack, X, LinkedIn, Airbnb, and Amazon: Sites mentioned as examples of browser-based agent work, including scheduling content, research, and shopping or travel research.

• Notion and Jira: Compared with editable artifacts as tools that can be harder to customize for a specific need.

• OpenClaw: Mentioned in the discussion of people popularizing loop engineering.

• Claude Sonnet, Claude Opus, and “Fable”: Models mentioned during the discussion of long-running work.

If you are building an audience, a newsletter, a coaching business, or a company online, you need some way to see whether the work is going anywhere.

Google Analytics will not explain your whole business. But it can show you whether people are finding your site, where they came from, which pages are bringing in new people, and whether they stay long enough to care.

But, the problem starts after the tracking is set up.

Maybe you review Google Analytics every week, but still spend time clicking through traffic sources, landing pages, and search performance before turning it into a summary.

Or maybe you are more like me. The reports are there, but you keep putting them off because opening them feels like starting a small analysis project from scratch.

Every Monday, six CSV reports arrived in my inbox: traffic sources, landing pages, search queries, and engagement data from Google Analytics and Search Console.

I had already set up the reports I wanted. But some weeks, I skipped them completely because opening the files still felt like starting a small analysis project from scratch.

And when I did open them, I still had the same problem.

The numbers were there, but the insight was not obvious.

One recent week, my overall traffic fell 11%. That sounds bad until you look closer. Organic clicks grew 4%. Search impressions grew 8%. Average session duration went up 20%.

So what happened?

Fewer people came to the site, but search was still moving in the right direction and the people who arrived were staying longer. The real drop was coming from direct traffic, not search.

That is useful information. But I had to compare separate reports and figure out the story myself before I could see it.

So I built a weekly Claude Code routine that creates an Artifact report:

1. The routine is the repeatable Monday job. I packaged its instructions as a Claude skill, so I do not need to explain the reports, comparisons, or output format again every week.

2. The Artifact is the visual report the skill creates. It brings the separate CSV files into one place, with the charts, tables, and weekly summary I need to review.

Every Monday, Google sends the same six reports with the dimensions and metrics I already care about. Then I run a routine in Claude that reads the CSV files from my email and turns them into a visual Artifact report.

More importantly, it saves the raw data and finished report in a dated folder. After a few weeks, I do not just have a snapshot. I have a history I can compare.

In this post, I will show you the exact setup: the reports I schedule, the email routine, the Claude skill that generates the Artifact, and the folder structure that stores every week of data.

All of these can be applied across Claude Code Desktop, Cowork, and ChatGPT Work.

What you will have after you set this up

The goal is to design the reporting once, then stop rebuilding it every week.

When your scheduled reports arrive on Monday, Claude will trigger the skill automatically. It already knows which email attachments to find, what each CSV contains, how to compare this week with last week, how to create the Artifact, and where to save everything.

The skill is called /weekly-analytics-report.

By using the skill, you do not need to write a new prompt every week or recreate the same report by hand.

Here is the workflow:

Google Analytics + Search Console reports

    -> scheduled Monday emails

    -> Claude skill

    -> Artifact report + dated data folder

    -> weekly history you can compare

By the end of this post, you will have:

1. A fixed set of Google Analytics and Search Console reports built around the questions you want answered each week.

2. CSV files delivered to your email automatically every Monday.

3. A Claude skill you can run without writing a new weekly prompt.

4. A visual Artifact report that brings the separate reports into one clear weekly update.

5. A dated folder containing the raw CSV files and finished report from every week.

The outcome is simple: your weekly reporting becomes one repeatable step, and each new report adds another week of history you can use to see what is actually growing.

Subscribe now

🚨 Before you start

This workflow only works when the data is already being collected.

Before you follow the reporting setup in this post, make sure you have:

1. Google Analytics set up for your website or Substack.

2. Google Search Console set up and verified for the same site.

3. Your Search Console property linked to your Google Analytics property.

4. An AI setup that can access the Gmail inbox receiving the scheduled report

There are many resources and guides on YouTube that show you how to set up both Google Analytics and Search Console.

Once the connection is in place, you can use Google Analytics as the place where you build and schedule the reports for this workflow. That includes the normal traffic and engagement data from Google Analytics, plus the search-query and organic search data from Search Console.

You do not need to create one set of scheduled reports in Search Console and another in Google Analytics. For this setup, the reports all come from Google Analytics.

Your AI also needs a way to read the CSV attachments after they arrive. The exact setup depends on whether you use Claude Code, Claude Cowork, or ChatGPT Work. Use the Gmail connection available in your setup, then make sure it can search the inbox and read the report attachments.

In my case, Claude Code accesses my Gmail through Google Workspace CLI. If you want to follow the same path, read my Google Workspace CLI setup guide first. Once that connection is working, the weekly report skill can find the scheduled emails by itself.

Why I used scheduled reports instead of MCP

Someone might ask why I did not connect Google Analytics through MCP and ask Claude to pull the data directly.

I have not tested the Google Analytics MCP route yet, so I am not going to pretend I know which option is better.

But I do know the job I am trying to solve here. I am not opening Claude every Monday and asking a new question about my data. I need the same set of reports, with the same dimensions, metrics, filters, and date range, every single week.

Scheduled reports let me define the data once. Every Monday, the same files are already waiting in my email, and the skill already knows what to do with them.

MCP might be useful for a different job, especially when I want to explore something new in the data. But I am building a repeatable Monday routine that turns a fixed set of reports into a visual record of how my Substack is growing over time.

Now, let’s dive in.

Decide what you actually want to learn each week

Before setting up any report, decide what you need the weekly review to help you understand.

Google Analytics can track far more than most of us need to look at every Monday. If you schedule every available report, Claude will have more files to read, but you will still end up with a noisy report that does not help you decide what to do next.

So, instead of asking, “What can Google Analytics show me?” I started with a simpler question: “What would I want to know before I decide what to pay attention to this week?”

For my newsletter, that became five questions:

1. Did traffic change, and did the quality of that traffic change with it?

2. Which source or channel explains the change?

3. What are people searching for, and are any topics gaining or losing momentum?

4. Which pages are bringing in new readers, and are they spending time with those pages?

5. Is there anything worth checking, fixing, or building next?

Here is how those questions map to the reports I use:

These are the questions for my own newsletter. Your version might focus on leads, booked calls, product pages, course sign-ups, or sales instead of content pages and search queries.

The rule is the same: start with the decisions you want to make, then choose only the reports that give you the evidence for those decisions.

Set up the Google Analytics and Search Console reports

I use six reports. Together, they give me a weekly view of traffic volume, traffic quality, acquisition, search demand, and content performance.

You do not need to copy this exact set if your business works differently. A coach might care more about lead pages and booked calls. A SaaS company might care about product pages and trial sign-ups. But these six reports are a good starting point if your site grows through content, search, email, or an audience.

I also have a video walkthrough below that you can watch to set up and run this entire automation.

Read more

NotebookLM has become one of the favorite tools among AI Maker readers.

Some of the most interesting examples I come across are from people who combine NotebookLM with the rest of the way they already use AI. The tool stays the same, but the workflow around it becomes deeply personal.

I saw this after sharing my AI therapy workflow last year. I uploaded years of journal entries to NotebookLM, asked questions about the patterns inside them, then turned what I found into small reminders I could use in daily life. It worked, but I still had to start every session, decide what to ask, and remember to return.

That is why Gencay’s version caught my attention. He kept NotebookLM as the source for his journal, then built a weekly loop around it:

1. One agent looks for patterns

2. Another searches for contradictions

3. A third turns the evidence into a report

Every claim needs dated quotes from the journal or it gets dropped. The final report also opens with one passage from Marcus Aurelius, chosen to match the week’s dominant pattern.

Today’s guest post is from , the creator of LearnAIWithMe and one of our returning AI Maker contributors.

In his previous guest post, he used five Claude Code sub-agents to turn an expense CSV into a financial dashboard. You might want to check out his previous posts on building SEO-optimized content with Claude Cowork, connecting GLM 5.2 to Claude Code, and hidden NotebookLM features most people don’t know about.

LearnAIWithMe

If you want to build with AI, not just learn how to prompt, this is the right place.

By Gencay

What I like about his work is simple: he builds real things, tests them, and shares what happened.

If you want to learn more about what he writes, start with these three posts:

1. I Built a Second Brain Never Forgets And Thinks While I Sleep

2. I Built an AI Tutor for My Claude Certification with NotebookLM & Claude Cowork

3. 3 Claude Loops That Will Put You Ahead of 99% of Claude Users

I need to say this clearly. I see this kind of setup as a tool for personal reflection, not diagnosis or a replacement for professional care. Gencay builds within that boundary. No clinical labels, no outside advice, and no hallucinations when the journal does not contain enough evidence.

If you read my original workflow and wished it could keep digging without you steering every question, this is a thoughtful next version.

Here’s Gencay.

Hello 👋🏻

A Nature paper published this month tried to answer a simple question:

“How many people use AI for mental health support?”

The reports they reviewed said anywhere between 3 and 70 percent of AI users. Their own estimate landed at 27 percent.

So roughly one in four people talking to AI is talking about their mind.

I was one of them, quietly.

Then I read ’s AI therapy workflow and built his system for myself.

Journal goes into NotebookLM, questions reveal patterns, insights become daily tools.

It worked.

Then I realized there’s one thing I can change now.

In the AI therapy workflow, I was the one writing the questions. Every session, me, typing, deciding what to ask for my own journal.

So I wondered if I could build the same system with a little automation and a loop. Agents who write their own questions. A goal that decides when the digging is done.

A routine that runs it every Sunday before I wake up.

I built it.

Here is the whole thing.

One NotebookLM Journal, Three Claude Code Agents

The journal lives inside a NotebookLM notebook. My Claude Code agents go through it each week and ask questions.

Not from a fixed list. Each agent reads the answer it gets and writes its own next question. One agent hunts patterns, one hunts contradictions, one compiles the report.

Why NotebookLM and not a plain folder of text files?

The answer is grounding. NotebookLM answers only from the sources, and we will configure it to say “Not in source” when the answer is not there.

A hallucinated number about a stock costs you money. A hallucinated pattern about your own mind costs you more. Nothing enters the weekly report that I did not actually write in my journal.

We will do it in 3 steps:

• Connect NotebookLM to Claude Code with CLI

• Create a NotebookLM space by feeding it your journal data

• Build Claude Code agents that analyze your journal

Let’s dive in.

1. Connect NotebookLM to Claude Code With the CLI

Claude Code needs a way to talk to NotebookLM. The bridge is the notebooklm-py CLI.

Open Claude Code and paste this:

Hey Claude, install the NotebookLM CLI from

https://github.com/teng-lin/notebooklm-py

1. Install it with pip

2. Run the auth command and give me the exact login step I need to do myself

3. Confirm the connection works by listing my notebooks

Stop and tell me if any step needs my input.

After pasting this prompt, all you need to do is authenticate your NotebookLM account, and you are done.

2. Add Your Journal to NotebookLM

Now the notebook needs your journal:

1. Go to notebooklm.google

2. Click Try NotebookLM

3. Create a new notebook

4. And hit the + button

Paste your journal entries as text, or upload the files if you keep them as documents.

Any files work: Notes app exports, Word files, and plain text all work.

If you are wondering what an entry should look like, there is no template. Mine are short, dated, and honest. Here are two from the week the report covers.

## June 29

Deadline week begins. Woke at 5 without an alarm, chest already

tight about Thursday’s delivery. Did not walk, went straight to

the desk, which felt productive at 5 AM and stupid by noon.

The tightness stayed all day.

## July 1

Broke the streak of bad mornings, walked 40 minutes at sunrise.

Thursday is still Thursday but it stopped being a monster

somewhere on the way back. Calm, clear, wrote the delivery

checklist in ten minutes.

A date and a few honest sentences. That is all the agents need. The quotes you will see in the report come from entries exactly like these.

Then the part most people skip. Open Configure chat by clicking here.

Choose Custom, and paste this prompt:

Answer only using the provided sources.

If the answer is not clearly supported by the sources, respond exactly with:

Not in source

Here’s the screenshot to follow:

Those lines are the immune system of the whole body. NotebookLM already hallucinates less than a chat model.

With those lines, in my runs, it dropped to almost zero.

3. Build Three Claude Code Agents for Journal Analysis

Here, you only need one prompt:

You are going to build my weekly self-discovery loop. Work step by step.

SETUP

1. Create a folder ~/mind-loop and work there.

2. Search Project Gutenberg for “Meditations by Marcus Aurelius”

   (it is public domain), download the plain text, and save it

   as meditations.md in the folder.

3. Confirm the NotebookLM CLI is installed and my journal

   notebook is reachable. My notebook is called: [YOUR NOTEBOOK NAME]

THE THREE AGENTS

Create an agent team that runs in this order:

Agent 1, Pattern Hunter.

Queries the journal notebook about this week’s entries.

Starts from three seed questions (values driving decisions,

situations triggering emotional responses, how a recurring topic

evolved) and then writes its own follow-up questions based on

each answer. Max 5 queries. Every finding must carry the

notebook’s citation.


Agent 2, Contradiction Finder.

Takes Agent 1’s findings and asks the notebook where my own

entries contradict them. Decisions I wrote down and then acted

against. Values I claim and behaviors that ignore them.

Max 5 queries. Citations required.


Agent 3, State Reporter.

Never queries the notebook. Compiles the week from the first

two agents: mood curve from the emotional language in entries,

active patterns, contradictions, and correlations that come only

from my own data (e.g. weeks with walks read calmer than weeks

without). Then it reads meditations.md and selects ONE passage

that matches this week’s dominant pattern. Not random. Matched.


THE GOAL (this is the loop)

Every claim in the report needs at least 2 dated quotes from this

week’s entries. A claim below 2 quotes gets re-queried, max 4

rounds. Still below? Drop the claim. If the week is quiet, the

report says “quiet week” instead of inventing depth.

Answers of “Not in source” kill the claim immediately.


THE OUTPUT

Build the report as a Claude Code artifact called Weekly Mind

Report. Layout: the Meditations passage on top (quote, what it

means in one line, how it maps to this week with the journal

evidence), then mood curve, active patterns with citations,

contradictions, correlations. No advice that does not come from

my own data.


THE ROUTINE

Create a Claude routine that runs every Sunday at 07:00:

add this week’s journal entries to the notebook as a new source,

then run the three agents, then build the artifact.

Hard rules: max 5 queries per agent per run, every claim cited,

no diagnosis, no clinical labels, no advice from outside my data.

Paste the prompt, and let it run.

You’ll notice the three sub-agents will be created:

And these agents questioned the NotebookLM, using the CLI:

Here’s what happened:

1. The Pattern Hunter asks, reads, and asks again.

2. The Contradiction Finder builds on the Pattern Hunter’s output, which is the part a fixed prompt list can never do.

3. The State Reporter turns both into one page.

The goal is what makes it a loop instead of an automation. Two dated quotes per claim or the claim dies. The agents keep digging until the report earns itself, four rounds max.

Subscribe now

Schedule the Weekly AI Journal Report

The prompt you pasted did one more thing. It created a Claude Code routine called weekly-mind-loop.

Routines are Claude Code’s scheduled tasks. You define a trigger time and a job, and Claude runs it without you. Mine fires every Sunday at 07:00.

When the routine gets created, Claude asks your permission once. Approve it, and you’re ready.

From then on, every Sunday morning, the routine adds the week’s journal entries to the notebook as a new source, wakes the three agents, and builds the report. The notebook grows every week, so the timeline gets richer with every run.

One thing to know. The routine runs on your machine, so your computer needs to be on at 07:00. Closed laptop, no report. It runs the next time the app opens.

Why Marcus Aurelius Opens the Report

In case you haven’t noticed, the prompt includes a Marcus Aurelius–style meditation report.

There are three reasons I did this: one personal and two practical.

The personal one. When I struggle, the Stoic mindset is the most useful way of thinking I know. Meditations was written by a Roman emperor to himself, about deadlines, worry, and things outside his control. It reads like it was written for a Tuesday in 2026.

The practical ones. Meditations is public domain, so the setup prompt downloads it from Project Gutenberg for free, legally, in one step. And it gives the report a fixed lens, the State Reporter matches ONE passage to the week’s dominant pattern instead of opening with a random quote.

So here is what to expect at the top of every report. A passage picked for your week, one line on what it means, and your own dated journal entries under it as evidence of why it landed. The emperor states the principle, your journal proves it applies.

If Stoicism is not your lane, this part is swappable, and I show the alternatives at the end.

The Result: A Weekly AI Reflection Report (Claude Code Artifact)

The result is a Claude Code artifact, with the Meditations passage on top.

The passage is not random. The State Reporter reads the week’s dominant pattern and picks the passage that answers it.

Mine was a week of deadline rehearsals, so Marcus opened the report with “let not things future trouble thee.” Book VII, written around eighteen centuries before my Thursday delivery.

Under the quote, one line on what it means, and my own dated entries showing why it landed on this week.

The one-liner nailed it:

“The future does not need to be pre-suffered.”

And the evidence under it is brutal in the best way.

On 06-30, I wrote that the project was fine, on track even, and I was still rehearsing disaster versions of Thursday. The report put my own sentence next to the emperor’s and let them talk. The thing I feared was imagined, and I had already written the proof myself.

Then there is a mood curve. It shows how the week actually felt, day by day.

The scores come from each entry’s own emotional language, tight on one end, settled on the other. A two-day trough on 06-29 and 06-30, the pivot on the resumed walk, and the peak labeled with my own words, a reward instead of a repair. July 4 has no entry, so the curve shows a gap instead of a guess.

Next, active patterns. This is the Pattern Hunter’s output.

Four patterns made it in, and every one carries two dated quotes plus the notebook citation underneath. P1 caught something I lived but never worded. Deadline anxiety overrides routines, and the skip is chosen and regretted the same day.

My 5 AM desk sprint felt productive in the entry and stupid by noon, in the same entry.

The report just held the two halves next to each other.

Then contradictions, the second agent’s job. It reads what I wrote down and checks what I did after.

C2 is my favorite kind of uncomfortable. On June 8, I made a decision, no new client work this summer. On June 19, I said yes to a project. The report did not scold me. It did the arithmetic. The saying-no promise lasted eleven days, and the verdict quote comes from my own July 5 entry.

I convicted myself. The agent just filed the paperwork.

And finally, correlations.

This section has one rule printed at the top. Only correlations visible in your own dated entries, nothing imported from outside.

Walk days read calm, no-walk days read tight, SUPPORTED, two dated entries per side. The mood and deadline link got tagged CONFOUNDED because the walk resumed the same day the deadline passed and the data cannot separate them. And the third candidate got DROPPED with a sentence I want on a t-shirt. One dated data point is not a correlation.

No advice appears anywhere in the report. It never told me to walk. It showed me my own sentences, dated, side by side, and let me draw the line.

Share

Adapt the NotebookLM Journal Workflow

The system you just built has three swappable parts.

The notebook holds your data. Mine holds a journal. Yours can hold anything you write regularly. Meeting notes, a reading log, your sent emails, a training diary.

The book gives the report its lens. I picked Meditations because a deadline brain needs to hear that the future does not require pre-suffering. Swap it for any public domain book that matches your angle. Seneca’s letters for the same energy, Franklin’s autobiography for habits, the Bhagavad Gita if that is your lane. Project Gutenberg has all of them for free.

The agents adapt to whatever the notebook holds. Point the loop at a training diary and the Pattern Hunter finds your skipped-leg-day pattern, the Contradiction Finder catches the “I will stretch every morning” promise from three weeks ago and does the arithmetic on how long it lasted, and a dead philosopher still opens the report.

One notebook, three agents, one Sunday routine.

The parts are yours to swap.

Your journal already knows things about you. Sunday morning, it starts telling them.