This was Season 2, Episode 6 of the show. and I have spent the last few weeks talking about Claude Code, Codex, and different agent harnesses, but this session felt different because the workflow was tied to a very specific business problem.

Sales admin.

For those who work in sales, I’m sure you can relate to this. You already know how tiring and time‑consuming it is to run a sales process—from researching the right ICP (Ideal Customer Profile) all the way to reaching out, getting a sales call, and converting prospects into clients.

Jonas showed a system that starts with company data from Apollo, filters companies based on his business fit, researches the ones worth looking at, creates records in Attio CRM, prepares a report, and drafts outreach messages for review.

The part I liked most was that he didn’t pretend the agent should own the entire sales process. The agent handles the heavy admin work, while Jonas still decides which companies to reach out to and what kinds of messages to craft for them.

That feels like the right shape for a sales agent.

Why This Caught My Attention

I am not a sales expert.

That is partly why I wanted Jonas on the show. I understand the AI side, the agent side, and the systems side, but sales has its own rules. You can build something technically impressive and still make the actual outreach worse if you automate the wrong part.

Jonas came at it from a more experienced angle. He has been building AI systems for 12 years, led AI teams at H&M Group, writes The Circuit on Substack, and does executive coaching around Claude Code systems.

The Circuit

Helping business leaders become better AI operators

By Jonas Braadbaart

If you want to learn about what Jonas writes about on his Substack, check out his latest posts:

1. There are only four ways to make money in the agentic economy

2. AI doesn’t “take” jobs. It exposes them

3. How to Build a Sales Engine With Claude Code

He also built this for a real business need. He wanted to sell AI strategy, workshops, coaching, and implementation work without depending entirely on recruiters, brokers, or intermediaries.

So the question was simple:

“Could he use Claude Code to handle the repetitive sales admin without turning the whole thing into spam?”

The answer was yes, but with a lot of human judgment around the edges.

The Sales Agent Starts With A List

The first step in Jonas’s system is a company list.

He used Apollo to pull company data. From there, the system could look at things like industry, location, headcount, revenue, and revenue per employee. Jonas was looking for mid-sized, services-heavy companies where AI strategy or AI product work might actually make sense.

I think this process is important because most people don’t really know what type of company they want to offer their services to, so they just blast out DMs aimlessly. But Jonas knew exactly which companies were a good fit for the service he’s offering.

That explains why his sales process started with prescreening. It began with Jonas manually filtering the companies he thought would be a great fit. Then he downloaded a CSV of those companies and let Claude help score and filter them locally against his own criteria.

That included basic signals from Apollo and the kind of subjective judgment that is hard to express inside a sales tool UI:

1. Does this company look like a serious fit?

2. Is there enough operational complexity?

3. Is the company services-heavy enough for his offer?

4. Is there a reason AI strategy or agentic product work could help?

5. Is there an obvious reason to skip them?

Jonas mentioned that he had used different ICPs across different rounds, so this process could keep changing as his idea of the right customer evolved.

Then The Agent Does The Research

After the prescreening step, Jonas picks a smaller list to work through.

In one example, he talked about choosing around 50 companies for a week. For those companies, the agent runs a deeper lead sourcing workflow.

This is where the system becomes more interesting.

The workflow researches the company, identifies who to contact, combines public research with Apollo enrichment data, and creates records in Attio. Jonas showed a lead source skill that could run for one company or many companies in parallel.

The research layer uses Perplexity through a custom MCP server. Apollo gives company data, but Jonas pointed out that Apollo does not have everything. The agent uses public research to understand things like:

1. What the company does.

2. How it makes money.

3. What its AI strategy appears to be.

4. Where its operational bottlenecks might be.

5. Which decision-makers might be relevant.

That used to be the kind of work a sales rep would do with a lot of browser tabs open.

Jonas said traditional sales research could take hours per company. With the agent, a lot of that gets compressed into background work. The output becomes a set of files, CRM records, and outreach prep that he can reuse later.

That is the part I kept thinking about.

The agent is moving the sales process forward, one prepared handoff at a time.

Subscribe now

The CRM Handoff Is Where It Gets Practical

Jonas’s system doesn’t stop at research — it goes further. After the company research is done, the agent creates company and people records in Attio. This is important because you want the research information updated for each company, giving you more context and enriched data you can use later when you’re about to cold outreach them.

Jonas chose Attio partly because it had a mature first-party MCP server. That made it easier for Claude Code to create and update records without having to do it manually by hand.

The workflow also generates a personalized report handout. The report ties the company research back to Jonas’s four service offers, so he can quickly see possible collaboration ideas before reaching out.

He experimented with sending those reports directly in cold outreach, then decided it worked better not to do that upfront.

That was a very practical sales lesson.

The report looked useful, but if you send a polished PDF to someone cold, it can feel like phishing. So Jonas now mostly uses the report for himself. It helps him understand the company, the likely bottleneck, and the reason for reaching out.

Again, the agent prepares the work. The human decides how to use it.

The Agent Drafts Outreach And Stops Before Sending

The system can draft LinkedIn and email messages.

For Gmail, Jonas used an MCP setup so the agent could create drafts. For LinkedIn, he copies and edits manually. Either way, he was very clear about the boundary: he reviews the report and rewrites the messages before sending.

That boundary matters.

Jonas shared a previous experience with automated cold outreach where he sent a large batch and got almost nothing useful back. One reply was basically “your AI sucks,” and another was a clear no. The messages sounded robotic, and the whole thing did not work.

So this version is different. It is still a sales agent, with a clear human review step before anything goes out.

The workflow helps with:

1. Finding companies.

2. Filtering the list.

3. Researching the company.

4. Identifying decision-makers.

5. Creating CRM records.

6. Preparing reports.

7. Drafting outreach.

But the last mile stays human.

Jonas said something that stuck with me: human-to-human communication should remain human. I agree with that, especially for cold outreach. The more AI-generated messages I receive, the easier they are to spot.

The low-effort ones feel low-effort immediately.

What The Results Looked Like

The numbers from Jonas’s setup were useful because they were specific, but he kept them tied to his own case.

He said the first time he ran it, he contacted 80 companies and got one sale. That may not sound huge if you are used to inflated AI promises, but for cold outreach it seemed like a solid result from a small, focused run.

He also said that with the automation in place, he got the review and message prep down to around one minute per lead. Without the system, he estimated the same work could take one to two hours per lead, depending on how much research and preparation was needed.

That is the real gain.

The cost was also pretty grounded. Jonas estimated around 120 euros for the setup he described: roughly 60 euros for Apollo, 60 euros for LinkedIn All In One, plus a small amount for Perplexity credits and a separate email setup through Instantly. He already had a Claude plan, so he did not count that as a new cost for this specific workflow.

Those numbers will change depending on your tools, your list size, and what you already pay for. But the point is that this was a small enough sales stack for a solo operator to run.

The Sales Agent Map

Here is the simplest way I understood Jonas’s system:

That table is also why the system felt practical to me. Each step had a job. Each output moved the lead one step forward. And every risky moment still had a human check before it touched the prospect.

The Smallest Version I Would Build First

If you want to copy the idea, I would not start with the full setup.

I would start with one manual version:

1. Export 20 companies from Apollo or another company database.

2. Write your ICP in plain language.

3. Ask AI to score the companies against that ICP.

4. Pick the top five.

5. Run deeper research on those five companies.

6. Write one LinkedIn message and one email draft.

7. Review and rewrite everything yourself.

Only after that would I connect a CRM, Gmail drafts, or custom MCP servers.

The danger with sales agents is that it is easy to automate before you understand the selling motion. Jonas avoided that by keeping himself in the loop and updating the criteria as he learned.

That is the part I would copy first.

The exact stack matters less than the sequence.

Share

Show Details

Season: Season 2

Episode: Episode 6

Topic: Claude Code sales engine

Guest: Jonas Braadbaart, writer of The Circuit

Hosts: Wyndo and Dheeraj

Key Timestamps

1. 00:01:31 Season 2, Episode 6 introduction.

2. 00:02:01 Why Jonas was invited and what his sales engine does.

3. 00:04:13 Jonas introduces himself and The Circuit.

4. 00:05:32 Jonas explains his current Claude Code setup.

5. 00:13:46 The discussion shifts into the sales engine.

6. 00:14:35 Why Jonas built it in Claude Code instead of n8n or Make.

7. 00:17:01 The business context behind the sales engine.

8. 00:20:17 Why ICP definition matters before automation.

9. 00:24:52 Apollo list strategy and company filtering.

10. 00:26:46 The workflow map: Apollo, prescreening, research, Attio.

11. 00:29:04 Perplexity research and lead sourcing.

12. 00:34:14 Creating company research files and CRM records.

13. 00:35:40 Personalized reports and outreach drafts.

14. 00:39:46 Gmail drafts and LinkedIn review.

15. 00:40:24 Why fully automated cold outreach failed.

16. 00:42:49 Jonas explains why he now prefers augmentation for this work.

17. 00:44:37 The hard human work behind defining the customer profile.

18. 00:46:17 Why human communication should stay human.

19. 00:51:41 Cost breakdown.

20. 00:58:56 Des asks about results and daily time spent.

21. 00:59:05 80 companies contacted, one sale.

22. 00:59:34 Around one minute per lead with the system in place.

23. 01:01:43 Wrap and next week’s topic.

Resources Mentioned

• Claude Code: Jonas’s main agent harness for building and running the sales workflow. Mentioned throughout by Jonas, Wyndo, and Dheeraj.

• Codex: Discussed near the start as a strong alternative to Claude Code, especially for writing and project-aware knowledge work. Wyndo mentioned using it alongside Claude Code.

• Cursor: Jonas used Cursor for about two years before relying more heavily on Claude Code. Wyndo also mentioned using Cursor for coding.

• Antigravity: Jonas tested it against Claude Code and Codex and was disappointed. Wyndo and Dheeraj discussed it in relation to Gemini access.

• Gemini Pro: Mentioned because Antigravity access can come through the Gemini Pro plan.

• GPT 5.5: Discussed as a strong model, especially in Codex.

• Anthropic: Mentioned as Jonas’s preferred model company for coding confidence.

• OpenAI: Mentioned in the context of Codex and model competition.

• Fable 5: Mentioned during the opening discussion as part of recent model drama.

• Apollo: Used to pull company lists, company data, and enrichment data. Jonas mentioned around 60 euros for the Apollo use in his setup.

• Perplexity: Used through a custom MCP server for desk research on companies. Jonas said costs were small for his usage, with larger runs adding more API cost.

• Attio: The CRM Jonas used because it had a mature first-party MCP server. The agent creates company and people records there.

• Gmail: Used for outreach drafts through an MCP setup. Jonas did not let the agent send messages unsupervised.

• LinkedIn: Used for first-touch relationship building and manual outreach review. Jonas mentioned LinkedIn All In One at around 60 euros in his cost breakdown.

• Instantly: Used to set up a separate Google account for cold outreach so Jonas did not pollute his main email domain.

• Make: Mentioned as a tool Jonas still uses for some automations, though he chose Claude Code for this sales system.

• n8n: Mentioned as a familiar automation tool, but Jonas said this kind of flexible, changing workflow was easier for him in Claude Code.

• Obsidian: Jonas built a small plugin so he could run Claude Code natively inside Obsidian for knowledge work.

• VS Code: Jonas uses VS Code with Claude Code for engineering work.

• Gamma: Jonas uses Gamma for presentations after Claude Code helps generate the slide outline.

• Google Slides: Mentioned as slower for Jonas’s presentation workflow compared with Gamma.

• NanoBanana: Mentioned as an image-generation MCP server Jonas had used, with API costs that could add up.

• Hunter.io: Dheeraj mentioned it as a lead enrichment platform.

• ZoomInfo: Dheeraj mentioned it as another lead enrichment platform.

• The Circuit: Jonas’s Substack newsletter.

• H&M Group: Jonas mentioned leading AI teams there.

• Lodestone Digital: Jonas’s AI agency context behind the sales engine.

I have been moving between both tools a lot lately. Codex has become the place I reach for more often when I am writing, especially because the writing style feels better to me right now. Claude Code is still where I spend most of my time for coding, design, brainstorming, and more agentic work.

So the original question was simple: where are they actually different?

But the more useful question showed up during the demo: what happens when you stop treating Claude Code and Codex like rivals, and start treating them like two agents that need a clean handoff?

That was the part I kept thinking about after the session.

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

Why This Comparison Matters Now

Most AI tool comparisons push you toward a decision.

Use this one for coding. Use that one for writing. Pick this model if you want speed.

That kind of comparison is useful to a point, but it can also create another layer of mental overhead. You already have too many AI tools to choose from. Now you also have to decide which agent should touch which project, which app should hold the conversation, and what happens when one tool runs out of usage or gets stuck.

Dheeraj framed this well at the beginning of the session:

• Codex feels closer to one app. You open it, pick a folder, start a thread, and work.

• Claude feels more like a suite. You choose between chat, CoWork, and Code before you even begin.

But that does not make one better in every case. It just changes the amount of friction when you’re about to use each of them.

For me, Codex feels easier to open. It also feels more like a super-app that can do many things. Claude Code desktop still feels extremely useful, but the app is confusing because it has too many features. Even though there are many differences between them, I don’t think I’m ready to use only one of them right now.

The Demo Was Really About Handoff

Dheeraj used a very simple compound interest calculator for the live demo.

That was a good choice because the app itself was not the point. It had an initial deposit, a monthly contribution, an interest rate, and a final balance. Pretty basic.

The useful part was the shared handoff system behind it.

Dheeraj created a changes.log file that both Claude Code and Codex had to read before starting work and update after finishing work. Claude Code had instructions in Claude.md. Codex imported those instructions into AGENTS.md when the project was opened in Codex.

So instead of relying on memory, vibe, or a long chat thread, both tools had one shared place to check:

1. What changed?

2. Which agent changed it?

3. Which files were touched?

4. What should the next agent know before continuing?

Claude Code went first and added a year-by-year breakdown to the calculator. Then Codex picked up the same project, read the handoff file, improved the interface, turned the breakdown into a growth chart, and verified it in the browser. Then Claude Code came back in, read the latest state, and rebranded the whole calculator with Dheeraj’s Gen AI Unplugged colors.

That is the actual insight for me.

Even though during the demo the interest calculator showed a properly working table with a nicer UI, the bigger lesson was that the work could move between tools without everyone pretending the previous session never happened.

Subscribe now

Where They Felt Different And Where They Felt The Same

Before the handoff demo, Dheeraj and I tried to separate the obvious differences from the deeper overlap.

The biggest difference was how to get started with each app:

• Codex felt closer to one app. You open it, pick a project folder, start a thread, preview work in the browser, control parts of it from mobile, and generate images in the same general flow.

• Claude felt more split. You choose between chat, CoWork, Claude Code, Chrome, VS Code, and the terminal depending on the job. That can create more starting friction, but it also gives you more specialized surfaces when you know what you want.

That difference helped me more than a feature-by-feature comparison. The question is not only what each tool can do. It is how much thinking you have to do before you can start doing the work.

At the same time, they are similar in a lot of important ways. Both can work with project folders, run agentic coding tasks, use terminals, follow computer-control patterns, handle GitHub pull requests, manage cloud tasks, access remote servers, schedule work, use skills, and support MCP-style integrations.

But there’s one big difference: Codex has an in-app browser, so you can ask it to browse the internet and watch it work live. Claude, on the other hand, requires Chrome to browse the internet, but you can still see it in action by having it take over your Chrome tabs.

Image generation was another clear difference. Dheeraj uses Codex CLI to generate images through his subscription instead of paying per image through a separate API every time. He mentioned that API image generation had cost around 15 to 18 cents per image in some setups, while batch or delayed generation could bring that closer to 8 or 9 cents depending on the model and route.

For my own workflow, I also talked about using Codex with Paper Design or Magic Path to create HTML banners, then generating an image inside the same flow and dropping it into the design. That is one of the places where Codex feels useful because the app can move between writing, coding, browser preview, and image generation without making me jump through too many tabs.

The confusing part was integrations. Both tools have some version of connectors, plugins, skills, apps, and MCP servers. But the naming gets messy fast. In Codex, a plugin can include app connections and skills. In Claude, similar things show up under connectors, plugins, CoWork, or project setup depending on where you are.

That is probably less important once everything is configured. But when you are starting, naming and interface shape matter because they decide how quickly you can learn how to use them.

The Handoff Became The Review Process

The more I think about the demo, the less it feels like a tool comparison.

The bigger lesson was that using two agents can create a natural review loop, but only if the handoff is clear enough for the second agent to understand what happened.

That is the part most people might have missed at first.

When Claude Code finishes a task, Codex can pick up the project and inspect what Claude Code actually did. It can look for flaws, missing pieces, rough interface choices, or places where the first agent followed the instruction too literally.

Then the same thing can happen in reverse. Claude Code can come back after Codex and inspect the changes, adjust the implementation, or bring the project back toward the original intent.

That is where the handoff becomes more than a status update.

A useful handoff gives each agent enough awareness to do more than continue the task. It gives the next agent something to judge.

That judgment needs a few simple pieces:

1. What changed?

2. Why did it change?

3. Which files matter?

4. What is unfinished?

5. What should it be careful not to undo?

Without that, two agents can create more confusion than one agent. With it, the second agent can review the previous pass, catch blind spots, and improve the work instead of restarting from scratch.

That was the part I found real useful.

Share

What I Would Try First

If you already use Claude Code and Codex, I would not start by designing a complicated multi-agent setup.

I would start with the smallest true version:

1. Pick one low-risk project where both tools can access the same folder.

2. Add a changes.log file.

3. Add instructions to both tools to read the latest log entry before starting.

4. Add instructions to both tools to append a new entry after finishing.

5. Run one small round trip between the two tools.

That is enough to feel the difference.

That round trip can be simple. Claude Code builds the first version, Codex checks the interface, then Claude Code picks it back up. Or Codex drafts the asset, Claude Code wires it into the project, and both tools leave notes for the next step.

The mistake would be trying to make the handoff perfect before you have seen whether it helps.

For me, the better question now is not “Claude Code or Codex?”

It is: which part of the work needs a second agent, and what does that agent need to know before touching it?

That is a much more useful decision.

If you want the Calculator Demo and the handoff kit shown in the livestream session, you can grab them here:

Calculator Demo and Handoff File

Show Details

• Show: One Shot Show

• Season: Season 2

• Episode: Episode 5

• Topic: Claude Code and Codex handoff workflow

• Hosts: Wyndo and Dheeraj

• Live schedule: Wednesdays at 10:00 AM EST on Substack

Timestamp Notes

• 00:00:09: Episode 5 introduction and agenda

• 00:00:21: Reference to Episode 3 Codex deep dive

• 00:00:32: Wyndo explains why he has been using Codex more for writing

• 00:03:19: Dheeraj frames the session as how Claude Code and Codex can work together

• 00:04:24: Wyndo explains using one model to review the other model’s output

• 00:07:02: Discussion of Codex as one app versus Claude as a suite of apps

• 00:13:08: Wyndo asks whether Dheeraj still uses chat or CoWork

• 00:14:33: Dheeraj explains using CoWork for non-technical research workflows

• 00:17:50: In-app browser differences between Codex and Claude

• 00:21:43: Codex mobile app and GPT Image discussion

• 00:23:15: Wyndo describes using Codex with Paper Design or Magic Path for banners

• 00:25:14: Similarities between Claude Code and Codex

• 00:26:52: Plugin, connector, MCP, and skill naming confusion

• 00:30:22: Dheeraj introduces the shared changes.log bridge

• 00:32:36: Compound interest calculator demo begins

• 00:36:32: Claude.md handoff instructions explained

• 00:40:17: Claude Code adds a year-by-year breakdown

• 00:42:43: Codex improves the UI and creates a growth chart

• 00:45:03: Codex imports Claude instructions into AGENTS.md

• 00:48:36: Codex verifies the chart in the browser and adjusts the output

• 00:50:18: Claude Code picks up after Codex and rebrands the calculator

• 00:51:04: Wyndo points out that Claude can run inside the Codex app terminal

• 00:55:18: Dheeraj explains when to use both tools

• 00:58:12: Viewer question from Des Kennedy about image generation with Codex and MCP

• 01:03:05: Session wrap and next episode note

Resources Mentioned

• Claude Code: Agentic coding tool from Anthropic. Dheeraj used it in VS Code and Terminal for the calculator demo.

• Claude app: Anthropic desktop/app experience with chat, CoWork, and Code sections. Discussed by both hosts.

• Claude Chat: Used by Dheeraj for quick advice or research on the go, less than 5% of his monthly usage by his estimate.

• Claude CoWork: Used by Dheeraj for easier non-technical research workflows and scheduled tasks. No exact pricing discussed.

• Claude in Chrome: Browser integration Dheeraj described for using logged-in Chrome sessions.

• Claude VS Code extension: Mentioned by Wyndo as a way he uses Claude Code. Dheeraj had not tested it deeply yet.

• Opus: Claude model Dheeraj selected during the demo because his usage limit was available.

• Codex: OpenAI agent app used for writing, coding, browser preview, and the second step of the calculator demo.

• Codex CLI: Mentioned by Dheeraj as part of his image generation workflow.

• Codex mobile app: Mentioned by Dheeraj as a way to control sessions from mobile.

• ChatGPT: Mentioned by Wyndo in the context of possible merging into Codex.

• GPT 5.5: Mentioned as the model release that made Codex more reliable for Wyndo and Dheeraj’s workflows.

• GPT Image 2: Mentioned by Dheeraj as a major Codex advantage for image generation.

• GPT image generation: Discussed as included in a $20 Codex subscription in Dheeraj’s setup.

• Nano Banana: Image model mentioned in the viewer question and by both hosts.

• Nano Banana Pro: Mentioned by Dheeraj as a pay-as-you-go image route.

• Midjourney: Mentioned in the viewer question and Dheeraj’s image routing example.

• Gemini CLI: Dheeraj suggested using Gemini CLI documentation to build a direct wrapper.

• Gemini API reference documentation: Suggested by Dheeraj as source material for building an image-generation wrapper.

• Glif: Wyndo mentioned using Glif often for image generation.

• Ideogram: Wyndo suggested it as a possible MCP route because it can connect to multiple image models.

• Leonardo.ai: Mentioned by Dheeraj as another image tool with a subscription cost.

• Paper Design: Wyndo mentioned connecting it with Codex through MCP to generate HTML banners.

• Magic Path: Wyndo mentioned using it for banner design workflows.

• Canva: Mentioned as an example app inside creative production/plugin workflows.

• Figma: Mentioned as an example creative production app.

• VS Code: Dheeraj used it to open the calculator project and run Claude Code in an integrated terminal.

• Terminal: Used by Dheeraj to run Claude Code.

• Integrated terminal: Discussed as the way Dheeraj prefers to run Claude Code inside VS Code.

• Codex in-app browser: Used to preview and verify the calculator UI.

• Chrome: Used in the discussion of Claude in Chrome and logged-in sessions.

• LinkedIn: Used as an example of a site Claude in Chrome could check while logged in.

• X: Mentioned as a site Codex could browse in a logged-in browser session and as a research source.

• Amazon: Mentioned as an example of a tab an agent could browse.

• Telegram: Mentioned as one way to initiate Claude Code through channels.

• Discord: Mentioned as an app where agents could eventually do work.

• Slack: Mentioned as a connector/app example.

• Gmail: Mentioned as an app connector and data source.

• Google Calendar: Mentioned as an app connector.

• GitHub: Mentioned as a connector and for pull requests.

• GitHub pull requests: Mentioned as a shared capability.

• Amplitude: Mentioned inside the Data Analytics plugin/app list.

• Deepnote: Mentioned inside the Data Analytics plugin/app list.

• Reddit: Mentioned by Dheeraj as a research integration.

• Hacker News: Mentioned by Dheeraj as a research integration.

• Substack: Mentioned as the publishing platform and as where generated images were embedded into articles.

• YouTube: Mentioned by Dheeraj as a place where generated images are used for video b-roll or assets.

• Data Analytics plugin: OpenAI plugin Wyndo showed as an example of bundled connectors and skills.

• Creative Production plugin: OpenAI plugin discussed as a bundle of creative apps and skills.

• Product Design plugin: Mentioned in the Codex plugin discussion.

• Small Business Legals plugin: Mentioned by Dheeraj as a Claude CoWork plugin example.

• Plugins: Discussed as bundles that may include connectors, apps, and skills.

• Connectors: Discussed as app integrations, especially in Claude’s naming.

• Apps: Discussed as Codex naming for integrations.

• MCP: Mentioned throughout as the integration layer behind some connectors and workflows.

• Skills: Mentioned as reusable workflows inside plugins and projects.

• Hooks: Mentioned by Dheeraj as the stricter way to enforce updates to changes.log.

• Git worktrees: Mentioned as a way to let multiple agents work in isolation on larger projects.

• Cloud tasks: Mentioned as a shared capability where tasks can run without keeping the local machine open.

• Remote or SSH: Mentioned as a shared capability for accessing servers.

• changes.log: Shared handoff file Dheeraj used to coordinate Claude Code and Codex.

• Claude.md: Claude Code instruction file used in the demo.

• AGENTS.md: Codex instruction file created when Codex imported the Claude setup.

• Compound interest calculator: Demo app used to show Claude Code and Codex handing off work.

There was no starter template. No code written by hand. There was a description of what he wanted, a lot of back‑and‑forth, and a few moments where he had to slow Claude down and tell it to keep going.

This was Season 2, Episode 4. co-hosted with me, and our guest was Mark Miller (). Mark reached out a while back after I mentioned I wanted to feature readers building real AI workflows. The thing that caught my attention was an RSS reader he built for himself to track the blogs and Substack posts he cares about. He logs into it every morning.

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

So I asked him the obvious question: could you show people how to build this from scratch, live, at the minimum useful version?

He said yes. And what the session actually taught was bigger than RSS.

The real lesson was this: The gap between something you can imagine and something you can actually use has shrunk to almost nothing.

Mark said it plainly near the end:

“This thing can do whatever you imagined. That’s my bottom line to you.”

I want to show you why a guy who has been coding since 1996 believes that, and what he did differently to make it true.

Why This One Is Worth Your Time

Most people reading this have an idea backlog. A tool you wish existed. A small app that would fix one annoying part of your week. Or an app that collects the 100+ newsletters you actually read into one clean feed, so they stop dying unread in your inbox.

The reason those ideas stay ideas is the build. Building used to be the wall. You needed to know how to code, or hire someone, or learn a no-code tool well enough to fight through it.

That wall is what Mark watched come down, and he is convinced this AI moment is the early internet all over again. “It’s the same thing that happened when the internet came out,” he said on the stream. “It scared everybody to death.”

So when he heard Boris, the creator of Claude Code, say on Lenny’s podcast that he had not touched a line of code since November, Mark’s reaction, from someone who wrote Perl for a living, was, and I am quoting him, “bullshit. There’s just no way that can happen.”

So he turned the podcast off, went to his computer, and half an hour later had a functioning app pushed to the web. His words: “in my mind I was going, this is impossible.”

That is where it started for him.

That is the shift worth paying attention to. Not the RSS reader. The fact that the building part has gotten small enough that the only real question left is what you want to make.

The One Habit That Made the Build Work

Here is the part I did not expect from someone with Mark’s background.

His coding experience was the thing slowing him down at first. When he started with Claude, his instinct was to define everything. Tell Claude what to do and exactly how to do it. He kept hitting walls. Then he realized the move was the opposite of how he had worked for a decade.

“Don’t tell Claude how to do something,” he said. “Tell Claude what you want done, and then follow his instructions.”

You could watch this play out the whole session. His very first prompt was not a spec. It was this: “I want to create an RSS reader that’s available for public viewing. Ask me questions.”

That last part matters. When you tell Claude to ask you questions, it walks you through the decisions instead of guessing. It asked Mark about AI features, visual style, where to deploy, which feeds to include. For each one, Mark mostly took the recommended option. Instead of steering the architecture, he was answering an interview about his own idea.

Within a few minutes a working reader showed up in the preview window. Plain, a little lame looking, but real. Running locally on his machine. From there the session was just refinement, all in plain English:

• Pull in a featured image for each article, and if a source has not set one, use the author’s headshot instead.

• Make it one card per row, image taking up about 30 percent, total width 850 pixels.

• Add a left-hand menu listing the sources so I can filter.

• Put a search bar under the menu so I can search the text of any article.

• The headlines are too small, fix them.

At one point he stopped typing and just talked to it through the microphone. Same result. The app got better with every instruction, and you could see each change appear on screen as it happened. That is the thing about building this way. You are not imagining what it might look like. You are watching it become the thing you described.

None of those instructions required knowing what Next.js or Tailwind CSS is. Claude offered those, Mark accepted them, and they never came up again. As he put it, the job is not to know how to program. The job is to know enough to tell Claude what you want as the output.

Subscribe now

Steal the Whole Build as One Prompt

Mark built this the slow way, one request at a time, and honestly that is how I would tell a beginner to learn. The back and forth is where you figure out what you actually want. But some of you just want to paste one thing and get a working reader.

So I took every request he made during the session and stitched it into a single prompt. Open Claude Code on an empty folder, swap in your own feeds, and let it run:

Build me a public-facing RSS feed reader, then run it locally and give me the URL so I can see it in my browser. If anything is unclear, ask me questions before you start. Otherwise build it, start a local server, and tell me the local address.

Feeds to include (swap in your own):
- https://aimaker.substack.com/feed
- [your second feed]
- [your third feed]

Some sources I will hand you as a page instead of a feed. When I do, find the correct RSS feed yourself. For example, find the feed for this Substack: https://substack.com/@acommunityarchitect, and the RSS feed for this YouTube channel or video: [paste a YouTube URL].

Layout:
- One article card per row. Each card is 850 pixels wide and centered on the page.
- Inside each card, show the article image on the left taking up about 30% of the width, with the title, source, date, and a short description beside it.
- Pull in the featured image for each article. If an article has no image, show a clean placeholder instead.
- Make the headlines large enough to read at a glance.

Navigation:
- A left-hand menu attached to the left side of the content area, listing each source as a filter.
- Pin the menu so it stays visible while I scroll.
- Put an orange bracket next to the active source in the menu.
- A search bar directly beneath the menu that searches the text of any article.

Background:
- A gradient that starts as deep royal blue on the left and fades into soft pink on the right, with the cards kept clean and readable on top of it.

Keep this first version simple, with no accounts and no database. I just want to run it locally, see my feeds, and click through to read.

It will still ask you a question or two, and it will still show you a plain first version before it looks like anything. That part does not go away, and you would not want it to.

You can also execute this in one shot using Goals, where the agent will build it end to end—from planning and self‑verification to deploying it to Vercel.

It Was Never Really About RSS

Somewhere in the middle of the build, Dheeraj said the thing that reframed the whole episode. We were watching an RSS reader take shape, but the RSS reader was never really the point. The point was that the process underneath it now works for almost anything. You describe an app, you get an app, and you never have to know the code running it.

Mark gave the example that made it land for me. He pays for read.ai to transcribe his meetings. One day he opened Claude and typed “build me a substitute for read.ai.” Claude just said okay. Sit with that for a second. If you are paying for a tool you like, you can often describe it to Claude and get your own version of it. You can even point Claude at the app’s webpage so it sees how the thing is put together before it starts.

The real unlock is bigger than newsletters. The gap between “I wish this existed” and “here it is running on my screen” has mostly closed. Mark put a bow on it near the end: “This thing can do whatever you imagined. That’s my bottom line to you.”

But here is what gets interesting once building stops being the hard part. The hard part moves.

Dheeraj raised it live, and a viewer named Laurie backed him up. If you can pull in every feed you care about, you are one step from rebuilding the exact problem you were trying to escape. Dheeraj described his Gmail inbox as a graveyard of newsletters he never opens. Laurie said that back when she had a mountain of feeds in Feedly, deciding what to actually read got brutal. This explains why, if you build an RSS reader carelessly, you’ll just end up in the same position again, with too many newsletters you won’t read.

So the question shifts from “can I build it” to “what do I actually want this thing to let through.” Mark’s answer is deliberately small: show only the 10 most recent items from each source, and stop there. Dheeraj pushed it further, imagining an agent that reads what matters to you and surfaces the five things worth your time. Either way, the machine builds it in minutes. You are the one deciding what it is for and what it keeps out.

That is the part that does not get easier. When anyone can build anything, the scarce skill is deciding what is worth building and what is worth your attention.

Mark’s Rules of Thumb

Across the session Mark kept dropping one-liners that were really just years of trial and error compressed into a sentence. Here are the ones worth taping above your desk:

• Check your model before you start. Sonnet 4.6 will do pretty much what you want on your first builds. Opus with the giant context window is a token hog, and using it as your default is how you go broke without noticing.

• For anything bigger than a small app, start in a chat first. Talk through what you actually want, let it help you shape an outline and a plan, then take that plan into Claude Code to build. The plan is the work. The build is the easy part.

• Push it when you want the result. Ask it to teach you when you want the skill. “You do it for me” gets the job done. “Walk me through this step-by-step” turns the same moment into a lesson.

• Treat the first build as a minimum viable version, full stop. It works, and that is all it does. No security, no sanity check, no engineering review until you ask for one.

• Be polite to it. Costs you nothing, and the back and forth just goes better when you are not barking at it.

What I’d Tell You to Do With This

My advice is simple: pick the smallest real thing you have wanted to exist. Not a business. A small app that fixes one annoying part of your week. Then:

1. Open Claude Code on a desktop plan, point it at an empty folder, and start with one sentence that ends in “ask me questions.”

2. Take the recommended answers when you do not know. You will learn the terms by being curious as they come up, not by studying first.

3. Keep it on your own machine to start. Local is safe and fast. Deploying to the web is a later problem, and a different skill.

4. When Claude tells you to do a technical step, try “can you do it for me?” before you assume it is yours.

5. Before you trust it with anything real, ask it to review its own work as a release engineer and a security reviewer. Read what it says.

You do not need Mark’s 30 years. He spent most of the session arguing that the experience was almost beside the point now. What you need is one idea small enough to finish, and the willingness to describe it and keep going.

The gap between thinking it and using it is the smallest it has ever been. The only thing left on your side of that gap is deciding what to build.

See you in the next one!

Share

Watch the Full Session

This was Season 2, Episode 4 of One Shot Show.

We go live every Wednesday at 10:00 AM EST on Substack.

Timestamp:

• (01:46) What we’re building today: your own RSS reader

• (02:30) How Mark and I connected through the newsletter

• (06:01) Mark’s background: coding since 1996, and why this feels like the early internet

• (08:31) The story behind his first build: calling BS on “no code since November”

• (09:09) His orchestra deep-dive site, built before he ever touched Claude Code

• (10:04) A look at the full RSS reader he uses every morning

• (11:00) “If you can think it, Claude can help you build it”

• (14:39) The desktop setup: three windows, one blank folder

• (15:41) The first prompt: “create an RSS reader, ask me questions”

• (18:40) Watching Claude build it, and the “allow, allow, allow” lesson

• (20:51) The core habit: tell Claude what you want, not how

• (22:39) The first working version shows up in the preview

• (24:34) Audience question: how do you keep a feed from becoming a doom scroll?

• (25:49) Laurie’s point on Feedly, and using an agent to rank what to read

• (27:47) Dheeraj: the real takeaway is not RSS, it’s building any app

• (28:52) Why “Claude Code” might scare the people who’d benefit most

• (30:23) Adding a YouTube feed, and the feed scraper for sites without RSS

• (31:29) Does politeness actually change Claude’s output?

• (33:46) The featured-image fallback, using a headshot when one is missing

• (36:13) Refining the layout, and the model that quietly burned $20 in an hour

• (38:21) Adding a source menu and a search bar

• (42:14) Talking to Claude by voice instead of typing

• (44:40) Deploying to Vercel live, and what you actually need to understand first

• (52:54) Personas: the release engineer, security, and why the first build isn’t safe

• (55:40) “Build me a substitute for read.ai,” and it just said okay

• (57:49) The microphone button, RSI, and brainstorming out loud

• (58:47) Wrap-up and next week

Resources Mentioned

• Claude Code: the tool Mark used for the entire build, run from the desktop app. Mark noted you need a paid Claude plan to access the desktop version. The whole session happened here.

• Vercel: free website hosting. Claude can push a project to it directly. Mark deployed the reader live during the show.

• Next.js: the web framework Claude chose for the build. Mark never had to think about it.

• Tailwind CSS: the styling Claude used. Same story, it just handled it.

• Sonnet 4.6: the model Mark ran for this. His warning: an upgrade had quietly defaulted him to Opus 4.8 at 1 million context, and he burned through $20 in an hour. For a build like this, Sonnet was plenty.

• Wispr Flow: the voice dictation tool I use to talk to Claude instead of typing. Mark mentioned getting repetitive strain before he found the microphone button.

• Lenny’s Podcast: where Mark heard Boris, the creator of Claude Code, say he hadn’t written code since November. That doubt is what kicked off his first build.

• read.ai: the meeting transcription tool Mark uses. He also asked Claude to build him a substitute for it, and it just started.

• Feedly: the RSS reader Laurie brought up in the chat, and the source of the “millions of feeds, brutal to manage” problem an agent could help filter.

• YouTube and Anthropic RSS feeds: every YouTube channel has its own RSS feed Claude can find. For sites like Anthropic’s research pages that lack one, Mark built a scraper into his full version.

The session started with a simple topic: how to use Codex.

I walked through the Codex app, projects, plugins, skills, MCP (Model Context Protocol), file previews, browser use, automations, goals, and how I use it next to Claude Code. Dheeraj pushed on the comparisons, especially where Codex feels more like Claude Cowork even though the underlying job is closer to Claude Code.

But the more useful lesson was bigger than a tool comparison.

I’ve realized that regardless of which models you use—OpenAI or Anthropic—it’s no longer as important, because each model keeps getting better over time. The competition is so tight that locking into a single model limits my ability to reach my full workflow potential and keeps me from understanding the nuances of which models to use at different points to best fit my workflow.

So, I have been shifting back and forth between Codex and Claude Code because GPT 5.5 changed the tradeoff for me. Before GPT 5.5, I mostly avoided GPT for this kind of work. I did not like the writing as much, and it did not feel as agentic as Opus for the way I work.

That has changed enough that I keep reaching for Codex now.

Not for everything. I still use Opus for planning, brainstorming, designing, and some coding work because it often understands the broader context of a project better. And Opus has a better design taste. But for typical knowledge work, especially writing, documents, files, and daily operating tasks, GPT 5.5 inside Codex has become good enough that I do not treat it as a backup tab anymore.

Let’s explore what Codex can do for you as your new alternative to Claude Code.

🚨 A quick break from sponsor…

Ever shipped an AI hallucination? Cuey sends one prompt to ChatGPT, Claude & Gemini in one tab, so you can cross-check answers before you hit publish. Built for makers who can’t gamble on one answer.

Get 2 months of Pro on us 👉🏻 AIMAKER

The Friction That Made Codex Worth Testing Again

The reason this series exists is pretty practical, but usage limits are only part of it.

Dheeraj opened the session by saying what a lot of heavy Claude users have felt lately. The limits can be erratic. Sometimes they work in your favor. Sometimes they stop you right when you were finally making progress.

That happened enough that many of us started building backup routes.

But for me, there was another reason Codex became worth testing again.

When Opus 4.7 launched, I was disappointed by it. The answers often felt lazy. Sometimes it did not generate the complete output I asked for. And the writing style did not work well for me. It could feel mechanical, and sometimes it did not sound like my voice.

That was frustrating because I had been using Claude Code heavily for my newsletter work. It was where I brainstormed, wrote, built skills, and shaped a lot of AI Maker system.

Then I started hearing that Codex 5.5 had improved for knowledge-work tasks.

So I tried it again.

I started moving small pieces of newsletter work into Codex first. Brainstorming. Writing newsletter. Testing the same kinds of tasks I normally ran through Claude Code.

And so far, it has worked better than I expected.

That is why Codex caught my attention this time. GPT 5.5 improved enough for the work I actually do, and the Codex app made that work feel easier to keep close to the files, skills, and outputs I already use.

Codex Feels Different Because The Work Stays Close

The first thing I showed was the Codex app itself.

It has a simple chat area, pinned chats, projects, and a right-side panel where you can inspect files, documents, spreadsheets, presentations, browser sessions, and changes. That sounds basic, but in practice it changes the feeling of the work.

When I use Codex inside my AI Maker Newsletter folder, the app can see the files I am already working with. I can open a markdown draft, ask Codex to turn it into a document, generate a presentation from it, inspect the output on the side, and keep refining without jumping between six tabs.

That matters because a lot of AI work breaks at the handoff point.

You get a good answer, then you have to copy it somewhere. You ask for a file, then you have to open Finder. You generate slides, then you have to inspect them somewhere else. You want to compare versions, then the conversation and the artifact are no longer next to each other.

Codex reduces some of that friction.

I showed an example from my One Shot Show brief skill. I can give it a topic, generate a markdown episode brief, ask Codex to turn that into a document, then ask for a presentation. The outputs show up on the side, and I can keep talking to the same agent about the same artifact.

The default slide was not perfect. I would still edit it before using it publicly. But the result was readable enough from a very simple prompt, and that is the point.

For a lot of knowledge work, the first useful version matters more than the perfect version.

Subscribe now

Plugins, Skills, And MCP Are Different Jobs

One thing I tried to make clear in the session is that Codex has a few different layers that people can easily mix up.

The naming is still a little weird. You click “plugins” and then you also see “skills.” I do not think that label helps new users much.

But here are three key features you need to understand when you click “plugins” in the Codex app:

1. Plugins connect Codex to apps. Google Calendar, Gmail, Google Drive, Chrome, spreadsheets, slides, and other tools belong here.

2. Skills tell Codex how to do a repeatable job. A skill can encode your process, format, judgment rules, and output shape.

3. MCP is the more manual connection layer when the built-in app connection through plugins is not enough.

I’m sure OpenAI will fix this UI/UX problem, because I don’t think many people realize they can access the skills they already have or add more MCP connections, similar to how Anthropic handles this with its custom connectors feature.

Codex Makes The Claude Code Folder Easier To Reuse

This is the part I think matters most if you already use Claude Code.

Codex does not force you to rebuild everything from zero.

If you open an existing Claude Code project folder inside Codex, it can bring over a lot of the structure you already built. Your CLAUDE.md instructions can become an AGENTS.md file. Your skills inside the folder can show up inside Codex. Your files, drafts, outputs, and project structure are already there because Codex is reading the same folder.

For my newsletter, that matters a lot. I already have instructions, skills, drafts, source files, and output folders for AI Maker. If I had to recreate all of that just to test Codex, I probably would not bother. The friction would be too high.

But when I can open the same folder and Codex understands enough of the structure to get going, the experiment becomes much easier.

This is why I feel like Codex makes the migration process frictionless and portable. I no longer have to worry about moving between Claude Code and Codex because I can work with both of them at the same time.

Additionally, if you choose the CLI to connect with external apps, then you will find no problem moving to Codex. If an app works through a CLI, then a skill can often call it from Codex the same way it can call it from Claude Code. That makes tools like Google Workspace CLI, Tavily, Twitter, or Todoist easier to carry across.

But it becomes a different story if you use MCP.

If you already configured MCP servers inside Claude, Codex does not automatically import those for you. You still have to set them up again. That is the part that does not travel cleanly yet.

So the honest version is this:

1. Folder instructions transfer more easily.

2. Skills inside the folder transfer more easily.

3. CLI-based tools can transfer more easily.

4. MCP servers still need manual setup.

That is the main reason Codex felt interesting to me. It gave me a lower-friction way to test GPT 5.5 on the newsletter system I already built in Claude Code.

This makes experimentation with your own project folder much easier.

Codex Also Has Automations And Mobile Access

One of the practical features we showed was automation.

This is similar to scheduled tasks in Claude Desktop. You can create a workflow in Codex, then schedule it to run on a regular basis. In the session, I created a simple AI news skill: gather AI news from the last 24 hours with Tavily, summarize the results, then schedule the skill to run every morning at 9 a.m.

One of the audiences asked a good question near the end: can you get the news, then have the agent generate topic options from the news, then turn that into writing ideas?

Yes, that is possible. Dheeraj described a more complete version he calls Content Radar, where the agent filters news through brand guidelines, audience fit, content calendar, urgency, and whether something is evergreen or time-sensitive.

Codex also has mobile access. I showed the iPhone connection in settings, and there is an option to keep the Mac awake so Codex can keep running while you access it from your phone.

That is similar to how Claude has Dispatch. You still need your computer running, but you can continue or monitor work from mobile instead of being tied to the desktop screen.

Share

The Browser Demo Showed The Boundary

I also showed how Codex can use an in-app browser.

The browser can open pages inside the Codex app, which makes it easier to watch what the agent is doing. In the demo, I used Substack Notes analytics as the example.

The workflow was pretty simple:

1. I asked Codex to visit my Substack profile.

2. Codex went through my last five Substack Notes from yesterday.

3. It collected the data I wanted: impressions, clicks, and comments.

4. It put that data into a Google Sheet.

That part worked.

The issue was impressions.

To get impressions, Substack needs to know that I am logged into my own account. If the in-app browser opens Substack without my login state, Codex can still visit the profile, but it cannot see the private analytics data behind my account.

So right now, the practical version is: open the Codex browser, log in to Substack first, then ask the agent to collect the data.

Eventually, I think the browser should store the user’s authentication state. If I log in to X, Substack, LinkedIn, or another account inside the Codex browser, I should not have to log in again every time I ask the agent to visit that site. The browser should remember that I am authenticated, the same way a normal browser does.

That is the boundary the demo showed.

There is a big difference between an agent browsing the public web and an agent operating inside your private accounts.

The second version is more useful, but also riskier.

But I can see OpenAI will keep improving this feature over time, because it makes sense for users to deploy multiple agents to browse the internet for them while they are doing something else.

Security Is Boring Until It Matters

Someone asked about guardrails and security when connecting apps with your credentials.

I am glad they asked, because this is where agent workflows can get weird fast.

When you connect Google, Gmail, Calendar, Chrome, or any other account, you are trusting the platform and the permission system behind it. If the connection uses OAuth, you can often choose what access to grant. That matters.

If an agent only needs to read your calendar, do not give it permission to edit your calendar. If an app comes from a random GitHub repo and you do not trust it, do not install it just because it looks useful.

Dheeraj also brought up prompt injection, especially around email. That is a real concern. If an agent reads incoming emails and acts on them, a bad email can try to influence the agent’s behavior.

Here are some guardrail suggestions I can share:

1. Use trusted app connections when possible.

2. Grant the least permission that still lets the workflow run.

3. Keep human approval on actions that can send, delete, publish, or change important files.

4. Split risky workflows into smaller agents or checks.

5. Keep the agent in a more restricted mode when the downside is high.

I am still figuring out my own comfort level here.

For now, I feel safer using major platforms like OpenAI and Anthropic than connecting sensitive work through tools I do not understand. That does not make the risk disappear. It just makes the tradeoff clearer.

My Current Codex And Claude Split

The honest version is that I do not have a final answer yet.

Right now, I use Claude Code and Codex differently.

For brainstorming, planning, coding, and broader project understanding, I still often prefer Opus. It usually feels better at holding the shape of a larger task in its head.

For writing, document work, file-based tasks, app previews, and anything where I want a smoother visual flow, I am using Codex more often.

GPT 5.5 is the reason that changed. Before this version, I did not enjoy using GPT for much of my serious writing or agent work. Now it is good enough that I keep moving between both tools based on the job.

That might be the more practical future anyway.

I do not think the goal is to find one tool and stay loyal forever. The goal is to build your work so it does not collapse when one tool hits a limit, changes pricing, moves a button, or gets worse at the exact moment you need it.

That means the layer around the model matters:

1. Your project instructions.

2. Your skills.

3. Your handoff files.

4. Your logs.

5. Your app connections.

6. Your CLI tools.

7. Your safety rules.

That is what I would build before overthinking which model wins this month.

The Takeaway

The practical takeaway from Episode 3 is simple:

Build your AI workflow so it can survive one model’s mood, limits, or interface.

Start with the layer you can carry.

For me, that means keeping more of my work in folders, markdown files, skills, handoff notes, and tool commands that can move between Codex and Claude Code. It is not perfect. There is still setup friction. MCP migration is still annoying. Some app connections need to be rebuilt. Some outputs still need another model to review them.

But that is better than being trapped.

Codex is getting good enough that I can use it for real knowledge work now. Claude is still strong enough that I do not want to leave it. So I am trying to build a setup where both can help.

So, would you give Codex a try? If you have tried it, what sort of experience have you had? Share it with me in the comments section.

Best,
Wyndo

Subscribe now

One Shot Show Details

This was Episode 3 of One Shot Show, Season 2. One Shot Show goes live every Wednesday at 10:00 AM EST on Substack.

Season 2 One Shot Show:

1. Episode 1: What I Learned From Dheeraj’s Agentic AI Workspace

2. Episode 2: How To Build An AI Job Finder Agent That Finds Roles Worth Opening

3. Episode 3: Why I’m Moving Some of My Work From Claude Code to Codex

4. Episode 4: How to Build Your Own Newsletter RSS Feed

Timestamps:

• 00:00: Welcome to Season 2, Episode 3 and why Codex matters now

• 00:37: Claude usage limits and the need for backup routes

• 02:17: Why I started using Codex for knowledge work

• 03:56: Codex as an introductory session for agentic tools

• 05:13: My current split between Codex, GPT 5.5, Opus, and Claude Code

• 06:13: Codex app overview: projects, chats, folders, and pinned work

• 07:56: Plugins, skills, and the confusing naming layer

• 08:42: Plugins as app integrations

• 10:23: Skills inside folders and why Codex can discover them

• 11:28: Managing plugins, skills, MCP, and marketplace options

• 12:03: Adding MCP servers manually

• 13:02: Connecting Codex to mobile and keeping the Mac awake

• 14:22: Starting a new chat inside a project folder

• 14:51: Full access, permissions, GPT 5.5, and high reasoning

• 15:40: Mentioning documents, spreadsheets, browser, and files in chat

• 16:38: Memory, personality, and path options

• 18:00: Goals and long-running agent loops

• 20:03: Using goals for article quality checks, brand voice, SEO, and verification

• 22:03: Running handoffs between Codex and Claude Code

• 22:24: Adding a new folder and generating AGENTS.md from an existing Claude setup

• 24:30: Skills import from folders and the MCP migration limit

• 25:46: One Shot Show Brief skill example

• 26:51: Viewing markdown outputs inside Codex

• 27:27: Turning a brief into a document

• 28:00: Turning a brief into a presentation

• 29:10: In-app previews for documents, slides, apps, and outputs

• 31:16: File browsing, side panels, and folder inspection

• 31:57: Side chat while an agent is running

• 33:28: Opening terminal inside Codex and using Claude Code inside the same folder

• 34:30: Handoff skill and shared files between Codex and Claude

• 36:47: Skill Creator and Skill Installer

• 38:04: Creating an AI news skill with Tavily

• 38:44: Scheduling a skill as an automation

• 39:52: Browser use inside Codex

• 41:52: Browser login limits and when Chrome access matters

• 43:35: Usage limits on the $20 plan

• 45:44: Codex usage compared with Claude usage

• 46:40: GPT image generation inside Codex

• 48:02: Preview of the next Codex versus Claude episodes

• 49:06: Codex as OpenAI’s move toward a larger work app

• 50:24: Why tool bridges matter when usage limits interrupt momentum

• 50:54: MCP migration friction

• 51:09: Why CLIs can make skills more portable than MCP servers

• 52:48: Nick asks about open-weight models

• 54:31: Sensei asks about chaining news collection into topic ideas

• 55:53: Viewer question on credentials, guardrails, and security

• 56:24: Prompt injection risk and email-reading agents

• 58:44: Trusted apps, OAuth, least permission, and restricted mode

• 60:04: Closing notes and next episode preview

Resources Mentioned

• Codex: The OpenAI app I demonstrated for file-based agent work, documents, slides, browser use, automations, and project folders. I use it on the $20 plan, though usage limits can still vary based on model and reasoning settings.

• GPT 5.5: The model version discussed during the session. I framed it from my own usage: it has become much better for knowledge work and writing than earlier GPT versions I avoided.

• Claude Code: Anthropic’s coding and agent tool. I still use it heavily, especially when I want Opus for planning, broader project understanding, or coding work.

• Claude Cowork: Referenced as the Claude interface that Codex can feel similar to from a usability perspective, especially for people who prefer visual workflows.

• Claude Desktop / Claude app: Mentioned as the broader Claude environment where connectors and related tools live.

• Claude Opus: The model I still prefer for some planning, brainstorming, coding, and broader project understanding.

• Claude Sonnet: Mentioned during the open-weight model discussion as a strong model that can still create workflow friction compared with Opus in some cases.

• Plugins: Codex app integrations for tools like Google Calendar, Google Drive, Gmail, Chrome, spreadsheets, slides, and other services.

• Skills: Reusable instruction packages that teach Codex how to perform a repeatable job, such as generating a One Shot Show brief or running an AI news workflow.

• MCP: A manual connection layer for tools that are not covered by built-in plugins. We discussed it as useful, but more annoying to migrate across apps.

• AGENTS.md: The Codex instruction file that can act as the folder brain, similar to how CLAUDE.md works for Claude Code.

• CLAUDE.md: The Claude Code instruction file that can be replicated or translated into AGENTS.md when moving a folder into Codex.

• Handoff skill / handoff.md: A portable bridge file that summarizes what one agent did so another agent can review, continue, or challenge the work.

• Computer Use: A Codex plugin that can let the agent interact with local Mac apps.

• Chrome plugin: Mentioned as useful when Codex needs to access a browser where the user is already logged in.

• Codex in-app browser: The browser panel inside Codex. Useful for visible browsing, but limited when private account login is required.

• Google Calendar: Mentioned as an installable Codex plugin.

• Google Drive: Mentioned as an installable Codex plugin and connected app.

• Gmail: Mentioned as an app connection and as a higher-risk source if agents read untrusted incoming email.

• Google Sheets / spreadsheets: Mentioned as a Codex output and connected tool for structured data.

• Slides / presentations: Mentioned as a Codex output type. I showed a presentation generated from an episode brief.

• Documents / Word docs: Mentioned as a Codex output type. I showed a document generated from a markdown brief.

• Goals: A Codex feature for long-running tasks where the agent works, checks, and continues until the target condition is met.

• Memory: A Codex option that can help the system learn from repeated friction and prior instructions.

• Automations: Scheduled Codex tasks. I showed a daily AI news skill running at 9 a.m.

• Skill Creator: A Codex skill for creating new skills.

• Skill Installer: A Codex skill for installing available skills.

• One Shot Show Brief skill: My example skill for turning a session topic into a structured episode brief.

• Tavily: The search and research tool I used in the AI news skill example. Pricing was not discussed.

• Google Workspace CLI: Mentioned as a CLI approach that can make agent skills more portable across Claude Code and Codex.

• Todoist: Mentioned as a tool I can access through a CLI-based skill.

• Notion CLI: Mentioned by Dheeraj as another example of apps moving toward CLI access.

• Substack Notes analytics: Used as an example browser automation target that may require logged-in browser access.

• Google Sheets: Mentioned as the destination for structured Substack Notes analytics.

• GPT image generation: Discussed as a way to generate images inside the OpenAI side without paying for a separate image model in some cases.

• Nano Banana / Gemini image tools: Mentioned as image generation tools Dheeraj had paid for before using GPT image generation more.

• Open-weight models: Nick asked about models like Qwen and Kimi. I said I have not explored them deeply because I am currently optimizing for less friction.

• Qwen / Gwen: Mentioned in Nick’s question as an open-weight model family. The transcript pronunciation is unclear.

• Kimi: Mentioned in Nick’s question as another open-weight model.

• OAuth: Mentioned during the security discussion as the common permission flow for app connections.

• GitHub installs: Mentioned as something to be cautious with when installing third-party app connections or tools.

• Prompt injection: Discussed as a risk when agents read untrusted sources like email.

joined me and to show the job finder agent he built for his friends and family. It searches across job sources, scores roles against a personal profile, sends a morning email, lets the person reply with feedback, updates the profile, and saves history in a tracker.

For context, Pawel writes Digital Thoughts, where he shares AI experiments and future-of-work notes with the mistakes included. He describes himself as a curious tech enthusiast, which fits what I liked about the session where he was showing a real build that came from trying to help people close to him instead of another polished theory.

Digital Thoughts

Practical AI insights from an e-commerce manager who builds agents at night

By Pawel Jozefiak

I also recommend checking out these three pieces from Pawel:

1. How to Build Your First AI Agent (Basics)

2. How I Structure CLAUDE.md After 1000+ Sessions

3. My $600 Mac Mini Runs a 35B AI Model. Yesterday I Swapped Its Brain

What I liked most in this demo was how real it felt.

This was not a vague “AI can help you find jobs” demo. Pawel had built the thing around actual people close to him, with all the small details that make a tool usable: a morning report, fit explanations, concerns, feedback, history, and a way to keep improving the search.

The part that stayed with me was the profile.

Before the dashboard, before the email, before the tracker, the system needed to know what a good job actually means for one person.

That is what this post is about: how to build an AI job finder that does not just give you more listings, but helps you spot the roles that are actually worth opening.

The problem is not finding jobs

Most job search tools solve the obvious problem.

They help you find more listings.

But Pawel said something early in the demo that felt much closer to the real problem. The hard part is finding a role that is actually aligned with the person, not only aligned with the title.

A “marketing manager” role can mean ten different things depending on the company. One company might mean brand, positioning, and writing. Another might mean lifecycle email. Another might mean paid acquisition, dashboards, events, sales support, or whatever nobody else owns.

The title is not enough.

That is why Pawel’s job finder started with a profile. Not a resume. Not a LinkedIn export. A profile that explains the person’s experience, target roles, salary floor, location rules, company preferences, and what they actually want next.

That matters because the agent needs something to judge against.

If the profile says, “I want AI jobs,” almost anything can look relevant. If it says, “I want remote AI workflow roles where I build internal tools for small teams,” the agent has a real filter.

This is the first lesson I would take from Pawel’s build: The job finder is only as good as the profile it reads.

What Pawel built: A job finder AI agent

Pawel’s full version has a lot of pieces.

The morning flow looks roughly like this:

1. The agent reads a personal profile.

2. It searches across multiple job sources.

3. It scores each role against the profile.

4. It sends a short morning email with five to ten roles.

5. Each role includes the company, link, why it fits, concerns, and next steps.

6. The recipient can reply with feedback.

7. The agent updates the profile or state files for future searches.

8. A job tracker shows what was found, saved, applied to, and rejected.

The impressive part was not only the automation. It was that Pawel built around the people using it.

He started with email because everyone knows how to open an email. Then he added a tracker because email alone was easy to forget. He made the system accessible through a local app, then later moved toward a server so people could access it more easily.

To be honest, I didn’t expect this. I thought he was going to show me how he ran the job-finder agent inside Claude Code’s terminal. Instead, he built a proper UI and dashboard that people can see visually and click through. I think it was awesome.

And he shared his agent secret with me!

Subscribe now

What this walkthrough will help you build

After the live session, I kept coming back to one practical question:

“What is the smallest version of Pawel’s job finder that an AI Maker reader could actually run this week?”

Not as a polished product. Not as a dashboard for other people. Just as a useful daily job finder inside Claude Code, Codex or Cowork.

Thanks to Pawel for generously sharing his agent template with me.

So I adapted the idea into a skill-based folder. You open the folder, ask the agent to run the scout, and it follows the steps from there. The agent reads the files, calls Tavily, scores the results, writes the report, and remembers what it already showed.

The outcome is simple:

1. You describe the kind of work you want in profile.md.

2. You describe where to search in config.json.

3. The scout searches with Tavily.

4. It scores each result against your profile.

5. It writes a short report with the roles worth opening.

That is the version I want you to leave with.

I called this version the Daily Job Scout.

Not an agent that applies for jobs. Pawel was clear about this too. The agent should reduce noise. The human still decides.

Job applications involve your time, reputation, preferences, and future. I do not want the agent pressing submit for me. I want it to bring me a short list good enough to inspect.

The report you are building toward looks like this:

That is the whole value of Daily Job Scout.

It delivers jobs that actually suit you, based on who you are and the criteria you’re looking for.

And the bigger lesson is reusable beyond job search.

You can apply lessons here to turn a messy recurring decision into an agent loop:

1. Give the agent a profile.

2. Give it a search plan.

3. Give it a scoring rule.

4. Make it produce a small report.

5. Use the report to improve the profile and search plan.

That pattern can show up in job search, client research, lead sourcing, grant discovery, freelance opportunities, competitor tracking, or anything else where personalized results or quality matter more than quantity.

For this post, we will keep it concrete: a Daily Job Scout that runs inside Claude Code, Cowork, or Codex.

The build: Six files inside AI agent skill folder

Here is the file structure that you can download in this post and run it yourself:

What you need to pay attention to is the SKILL.md. It tells Claude Code, Cowork, or Codex how to run the scout: read the profile, read the config, call Tavily, score the results, write the report, and update state.

Now let’s explore what they’re built for, and how to use and customize them for your needs.

File 1: profile.md

This is the most important file.

It should answer:

1. Who are you?

2. What roles do you actually want?

3. What rules should reject a job immediately?

4. What signals make a job more interesting?

5. What signals make a job suspicious?

6. What strengths should the agent look for in the posting?

7. What matters this month?

Here is the shape:

Read more

The idea was simple, but it changed how I looked at almost every AI tool I was using.

For a long time, my AI lived in a chat window. My real work lived somewhere else. I used to save my content calendar and ideas in Notion. Newsletter drafts went into Google Docs. Research lived in NotebookLM. When I needed to post on X or LinkedIn, I still had to visit each platform and publish manually like a caveman. And I saved my post analytics in a Google Sheet I then forgot to check.

AI helped me think, but I was still the one moving the work around.

That was the copy-paste tax.

The promise of AI was supposed to be that it could help me move through my work. But in practice, I was still carrying everything from room to room.

That was the question underneath the agentic AI workspace idea:

What would it look like if AI lived closer to the work itself?

This week’s One Shot Show felt like a continuation of that question.

shared his full AI automation stack with us. Not a polished diagram of how agentic work might look someday. A real setup he is using right now to run research, writing, creative work, video production, distribution, data, approvals, and even server maintenance.

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

It was a lot.

And honestly, that is why I found it useful.

Most examples of AI workflows are too clean. One tool. One prompt. One magical before-and-after. Dheeraj’s setup was messier, wider, and more interesting because it showed what an agentic AI workspace starts to look like when someone keeps building on top of it for months.

I can assure you that his AI stack is worth studying for.

That is the thing I want to unpack.

From AI Tool Stack to AI Work Environment

Season one of One Shot Show was mostly about foundations.

Dheeraj and I talked about Claude Code, Claude Cowork, n8n, research agents, competitor intelligence, skills, and a bunch of other pieces that all live somewhere around the same question: how do you make AI useful beyond a single chat?

Season two starts from a different place.

Instead of asking whether one tool is better than another, we are trying to show the actual work environments people are building around AI.

Because we believe that by sharing this, we can help more people understand what’s happening behind the scenes and how people actually use AI.

If you look at Dheeraj’s setup as a list of tools, it can feel overwhelming:

1. Claude Code

2. Codex

3. MCP servers / CLI

4. Skills

5. Sub-agents

6. Gemini

7. Tavily

8. Perplexity

9. GPT Image

10. Nano Banana

11. Kling

12. Veo

13. Descript

14. Remotion

15. Playwright

16. Chrome extensions

17. n8n

18. Notion

19. SQLite

20. Oracle Cloud

That is a lot of names.

But the more useful way to look at it is as a set of layers.

Each layer has a job. Claude Code coordinates. Research tools fetch and compare information. Creative tools generate visuals and video assets. n8n handles always-on distribution. Notion holds structured planning and human review. SQLite holds searchable data and subscriber state. Dheeraj still steps in where the system needs judgment.

That is the part worth studying.

Because the stack includes so many tools, each with its own role in Dheeraj’s workflows.

Subscribe now

The Brain Layer: Claude Code Runs the System

At the top of Dheeraj’s setup is Claude Code.

That is his main operating layer. He has stayed there for the past few months because, in his words, it was already doing what he needed. He never fully migrated to Claude Cowork because Claude Code was comfortable enough and flexible enough for the work he was doing.

Around Claude Code, he has built the pieces that make it feel less like a chatbot and more like a working environment:

1. MCP servers for external tool access.

2. Skills for repeatable workflows.

3. More than 50 user-invoked commands or skills.

4. Around 30 sub-agents, each with a narrower responsibility.

5. A few orchestrators for bigger flows like video and content pipelines.

6. Hooks for safety and automation.

7. Codex as a backup and future complement.

This is where the agentic part starts to show.

Claude Code answers questions, but it also reads files, chooses skills, calls tools, sends work to other systems, generates assets, checks logs, and decides what to do next based on the task.

For example, during his demo, Dheeraj showed a hero image workflow. He can reference a post ID from Notion. Claude Code looks up the metadata, finds the related article file, loads the hero image skill, reads the content, builds the image prompt, calls the image generation script, and produces a Substack cover image using his recurring monk avatar and background style.

This is what it means to have a truly agentic workspace: AI automates the end-to-end workflow while only requiring you to set the goal. It can see the work, understand the rules, and act inside the same places the work already lives.

The Part Nobody Wants to Talk About: Progressive Disclosure

One of my favorite parts of the whole session was also one of the least flashy.

Progressive disclosure is the idea that your agent should not read every instruction, file, rule, and example every time it starts a task.

It should start with a small set of routing instructions, then load the deeper material only when the task calls for it.

Because if you dump everything into one giant instruction file, the agent gets slower, more expensive, and often worse. It sees too many rules at once. It can mix requests together. It can load material that has nothing to do with the job.

The better pattern is closer to a simple router:

1. Keep the root instruction file small.

2. Tell the agent how to recognize the task.

3. Point it to the right support files.

4. Load only the rules, examples, and source material needed for that job.

5. Leave everything else alone.

In practice, that might look like this:

1. AGENTS.md or CLAUDE.md explains the main routes.

2. A newsletter request sends the agent to the newsletter rules, draft examples, and style guide.

3. A LinkedIn request sends it to LinkedIn examples and the platform rules.

4. A Substack Notes request sends it to the best-performing Notes and the Notes rules.

5. A technical build request sends it to the project files, setup notes, and implementation rules.

The root file is the front desk. The support files are the rooms behind it.

You do not want the agent walking into every room just because the doors are open.

Dheeraj described a similar habit. When his root instruction file gets bloated, he trims it back and pushes the deeper details into more specific files or skills.

The more capable your system becomes, the more important routing becomes. More tools, more files, and more automations do not automatically make the agent smarter. Sometimes they just give it more ways to get confused.

This is boring infrastructure. But boring infrastructure is usually what makes agentic systems usable.

It is easy to make a demo where the agent has access to everything.

It is harder to make a system where the agent knows what to ignore.

If you want to learn more about how progressive disclosure works in your Claude Code setup, I’ve written a running series you can start learning from right away:

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

The Research Layer: Cost Almost Nothing

Dheeraj’s research layer also had a useful pattern.

He does not go straight to the most expensive or powerful option for every query. He has layers.

At the first level, he uses built-in web search and Gemini CLI for cheaper or simpler research tasks. One example he gave was Reddit research. If Claude’s fetch tools get stuck, Gemini can sometimes pull enough of the page to keep the workflow moving.

Then Tavily handles more serious research work. Dheeraj said he moved toward Tavily because the free credits are useful and because it can cover many research jobs in one place.

Perplexity is still there as a backup when needed.

This is a small design choice, but I like it because it treats research as a routing problem.

Not every question deserves the expensive path. Some tasks need a quick search. Some need structured extraction. Some need deeper synthesis. Some need a fallback because the first tool fails.

And the best part is that all of this costs you almost nothing.

Share

The Creative Layer: How Integrated Do You Want It to Be?

The creative layer was where the conversation got more interesting for me personally.

Dheeraj uses GPT Image, Nano Banana, Kling, Veo, Descript, and Remotion in different places.

The important part is not just which model he prefers. It is how those tools fit into the larger system.

For Dheeraj, the creative workflow runs through Claude Code as much as possible. Claude Code does not replace the image model, video model, or editing tool. It coordinates them. It sends the right prompt, calls the right script, passes the project ID, and keeps the creative step connected to the rest of the work.

He has been leaning more toward GPT Image for some visual work because the output feels warmer and closer to what he wants, especially for oil-painting style images and infographics. He also mentioned using the Batch API to reduce cost, with roughly a 50% discount discussed during the stream.

For video, he uses Kling for lighter animation tasks like animating a cover or thumbnail, and Veo for clips that need more quality inside a video.

Descript is part of his editing flow. He uses its MCP server to talk to Underlord, Descript’s AI assistant. The basic pattern is: record a video, upload it to Descript, get the project ID, hand that ID to Claude Code, and run a skill that asks Underlord to do a first cleanup pass.

Then there is Remotion.

That was one of the more concrete demos. Dheeraj showed animated overlays and text effects generated with Claude Code and Remotion. These can sit on top of his videos, support product storytelling, or become part of a faceless video format he is experimenting with.

I shared my own setup here too.

For my thumbnails and infographics, I have been using Glif for months. Most of AI Maker thumbnails and One Shot Show thumbnails have been made there.

I do not have a serious video creative workflow yet. But if I wanted to add one, I would probably still start with Glif because it gives me one place to work across multiple creative AI models.

The tradeoff is that I still need to open the website, write or refine the prompt, and make the creative decision myself. It is not as deeply wired into my agentic workspace as Dheeraj’s Claude Code setup.

But it also means I do not need to manually integrate GPT Image, Nano Banana, video models, and other creative tools one by one.

That has been impactful for me. Glif has streamlined the creative layer without forcing me to build a full creative automation system around it.

So the question is not only, “Which creative model is best?”

The better question is: how do you want creative work to fit into your agentic workspace?

The Automation Layer: He Did Not Move Everything Into Claude Code

This was probably the most practical lesson from the episode.

Dheeraj used to be deep in n8n. He taught it. He built workflows in it. A lot of his older automation work lived there.

Over the past few months, he moved much of the thinking, generation, and orchestration into Claude Code.

But he did not migrate everything.

He kept n8n for the parts where it still makes sense:

1. Distribution across TikTok, Twitter/X, Facebook, Instagram, and other channels.

2. Posting clips from Substack Live.

3. Generating branded PDFs from content.

4. Running workflows on a server when his local machine is off.

5. Handling app integrations that are already reliable.

That is worth saying clearly because a lot of AI people, including me sometimes, can get too obsessed with tool purity.

If Claude Code can do something, the temptation is to move everything there.

Dheeraj did the more sensible thing. He kept the parts that already worked.

For example, his PDF workflow in n8n was already tuned. Page breaks. Tables. Headers. Formatting. All the annoying details. He could rebuild it inside Claude Code, but why spend that time when the old workflow still works and Claude Code can just send content to it?

Same with distribution.

When Substack generates live clips, he can process them locally, upload them to a server, and let n8n take care of distribution. He mentioned that he has not logged into LinkedIn for a long time because that part is handled by the system.

This is what a mature agentic setup looks like to me.

The Data Layer: Files Are Not Always Enough

The data layer was another place where the episode pushed beyond my own default bias.

I like plain files. A lot.

My own newsletter system works because so much of the work lives in Markdown files that Claude Code can read and edit directly. My Obsidian setup works for the same reason. The fewer walls between the agent and the work, the less I have to carry in my head.

Dheeraj uses files too, but he does not stop there.

His planning system lives in Notion. His content calendar, YouTube content calendar, review states, and approval points are structured there. He connects Notion to Claude Code through the API rather than the Notion MCP server because the MCP path was using too many tokens.

That was a useful distinction.

Sometimes MCP is convenient. Sometimes direct API access is cleaner.

Then there is SQLite.

I asked why he needed a database instead of just storing everything in files.

His answer was practical. SQLite gives him fast text search, a structured place to store Substack content, analytics, subscriber information, and data for tools like magic links. He can host the database on his Oracle Cloud server and use it as the data layer for several projects.

That includes:

1. A searchable archive of his Substack content.

2. Substack analytics collected through his own Substack Intelligence layer.

3. Subscriber data for validating access.

4. Magic links for tools.

5. Data for GenAI Unplugged and cohort work.

This is where the agentic workspace becomes more than “a folder Claude can read.”

Files are great for writing, rules, drafts, notes, and context the model needs to inspect.

Databases are better when the system needs structure, speed, authentication, and repeatable queries.

That does not mean everyone needs SQLite. I do not think most people should start there.

But it helped me see the larger pattern: an agentic AI workspace can include files, databases, APIs, and human review surfaces; it doesn’t make one approach better, you still have to choose what suits your current need instead of overcomplicating things by adding extra integration layers.

Notion vs Obsidian Is Really About How You Work

One of audience asked a good audience question: why not use Obsidian as the data repository?

Dheeraj’s answer was basically that Notion still works better for his needs.

He likes structured databases. He likes being able to approve things from his phone while sitting in his son’s class. He likes publishing pages publicly and sharing guides with embedded resources. He also has team or audience-facing use cases where Notion makes more sense.

I shared my side too.

I use both, but I am now much more on Obsidian because I like the file-based structure and the way agents can work across plain Markdown. If I want to ask what I should think about for the next post this week, the agent can scan the ideas, drafts, and notes in the vault and surface possible angles.

But I understand why Notion works for Dheeraj.

The simple version is:

1. Obsidian feels better for single-player, file-based thinking.

2. Notion feels better for structured planning, phone review, sharing, and team visibility.

That is not a universal rule. Every person has their own preferences. I’m just speaking from a tradeoff perspective.

And again, this is why copying someone else’s stack too literally is risky.

Dheeraj’s setup makes sense because of his work. My setup makes sense because of mine.

The Human Layer: The Last 20% Is Still Hard

Near the end, Dheeraj said the thing that probably matters most.

AI gets you 80% of the way in 20% of the time.

That feels incredible.

It is also where a lot of people get fooled.

The last 20% still takes a lot of time. Sometimes it takes most of the time. That last stretch includes edge cases, error handling, weird API responses, performance issues, security issues, and all the odd little failures that do not show up in a demo.

Dheeraj gave a painful example from one of his products. He built the app over a weekend and thought it was ready. Then someone hit it with a denial-of-service attack, the system crashed, and credits burned. He spent another weekend hardening the security layer.

That is the difference between demo and reality.

I think this is the part people need to hear when they look at a stack like his.

The point is not “look how easy AI makes everything.”

The point is closer to: AI makes it possible to build more than you could before, but then you inherit more systems that can break.

That changes the work. It does not remove the work.

The same thing is true in content.

You can generate a lot of articles with AI. But if they do not sound like you, if you do not validate them, if you are putting your name on something you would not actually say, then the automation has not solved the real problem.

Dheeraj made a similar point about social platforms. You can automate posting, but if you are not actually participating, commenting, replying, and building relationships, the platform will not magically reward you.

AI can move the work.

It cannot care on your behalf.

That is still your job.

Subscribe now

What I Would Copy From Dheeraj’s Setup

I would not start by copying the full stack.

That would be the wrong lesson.

If you are still paying the copy-paste tax, a huge system like this will probably create more overhead than relief. You do not need 30 agents, 50 skills, a SQLite database, a self-hosted server, n8n, Remotion, and multiple research fallbacks just to make AI more useful.

But I would copy the shape.

Here is the version I would start with:

1. Pick one control layer. For me, that is usually Claude Code or Codex. For someone else, it might be Notion agents, Gemini inside Google tools, or a simpler Claude setup.

2. Put real work where the agent can reach it. Drafts, notes, rules, examples, project files, research, and outputs should not all be trapped in separate apps.

3. Write down the routing rules. The agent should know which files to read for which task.

4. Use skills for repeated work. If you do the same workflow more than a few times, turn it into a reusable instruction or command.

5. Keep old automations that already work. If n8n, Make, Zapier, Typefully, or a custom script is reliable, let the agent call it instead of rebuilding everything.

6. Add a data layer only when files stop being enough. Do not start with SQLite because it sounds advanced. Use it when you need structured search, subscriber state, analytics, or repeatable queries.

7. Keep a human review point. Approvals, publishing, security, and judgment should not disappear just because the workflow can run.

That is a much saner starting point.

The agentic AI workspace grows from repeated friction.

It does not need to arrive fully formed.

The Possibility This Revealed

What I liked about this episode is that it made the abstract idea visible.

When I first wrote about agentic AI workspaces, I was mostly writing from my own experience. I had moved my newsletter into one repository. I had connected Claude Code to my writing system. I had started using Obsidian as a place where AI could read across my plans, notes, and decisions.

That gave me the first version of the idea.

Dheeraj’s setup shows a much larger version.

His system helps him write, but it also researches, creates images, prepares video assets, cleans up recordings, generates overlays, distributes clips, manages planning data, queries analytics, validates subscribers, runs server tasks, and debugs failures.

Again, not perfectly.

Not magically.

But enough that the direction is obvious.

The next phase of AI work will still include better chats and prettier automations, but the bigger shift is environmental. AI starts moving through the same systems your work already depends on.

That is why I keep coming back to the question:

Where should your AI live?

For Dheeraj, the answer is a layered setup around Claude Code, Notion, SQLite, n8n, creative tools, research tools, and a lot of hard-earned operating rules.

For me, the answer looks more like a newsletter repo, Obsidian, Claude Code, Codex, and a growing set of skills.

For you, it might be much smaller.

It might be one project folder.

It might be one Notion database.

It might be one Google Drive folder where your client work actually lives.

You do not need the biggest stack. Instead, what you need is one real place where AI can work with the material your day already depends on.

That is when the compounding starts.

One Shot Show Details

This was the opening episode of One Shot Show, Season 2. We go live every Wednesday at 10:00 AM EST on Substack.

Timestamps

• 00:00: Welcome and Season 2 setup

• 02:50: What viewers will learn from Dheeraj’s AI automation stack

• 04:00: Dheeraj introduces the six-layer stack

• 06:00: Claude Code as the main brain

• 06:57: MCP servers, skills, slash commands, agents, and hooks

• 07:51: Research layer with Gemini, Tavily, and Perplexity

• 08:19: Creative layer with image and video tools

• 09:06: GPT Image vs Nano Banana for image generation

• 10:35: Kling and Veo for different video jobs

• 11:04: Descript MCP and Underlord

• 13:10: Remotion for animated overlays and faceless video

• 13:52: Playwright, Chrome extensions, and browser automation

• 14:22: n8n as the distribution and PDF layer

• 18:02: Clip distribution to LinkedIn and other channels

• 19:15: Twitter/X video posting and Playwright fragility

• 20:46: Notion as the structured planning layer

• 21:45: Why SQLite exists alongside files

• 25:20: The six-layer system in one view

• 26:29: Root instruction file size and progressive disclosure

• 29:55: Lee asks why not Obsidian

• 34:36: Why use multiple research tools

• 38:32: Wyndo on using Glyph for creative work

• 41:23: Remotion overlay demo

• 43:30: Voiceover, ElevenLabs, and faceless video experiments

• 45:18: What happens when something fails at 2 a.m.

• 46:34: Hero image skill demo

• 50:23: Debugging and the 80/20 trap

• 51:52: Demo to dependable

• 53:18: Automation does not replace platform participation

• 55:33: Audience question about image generation models

• 56:07: Season 2 wrap and next episode preview

Resources Mentioned

• Claude Code: Dheeraj’s main operating layer. It coordinates files, skills, agents, MCP servers, hooks, scripts, and external tools.

• Claude Cowork: Mentioned as part of Season 1 and as a less technical option, though Dheeraj said he stayed mostly with Claude Code.

• Codex: Mentioned as Dheeraj’s backup layer and a likely future topic for Season 2.

• MCP servers: Used to connect Claude Code with tools like Descript, n8n, and other services.

• Claude Skills / user-invoked skills: Dheeraj has more than 50 command-like skills for repeated workflows.

• Sub-agents: Dheeraj mentioned around 30 agents with narrower responsibilities.

• Hooks: Part of the Claude Code extension layer for automation and safety.

• Gemini CLI: Used as a lower-cost research layer and fallback when web fetch gets stuck.

• Tavily: Dheeraj and I both discussed it as a stronger research layer. The free credits were mentioned as useful.

• Perplexity: Used as a backup research option when Tavily credits or other paths are not enough.

• GPT Image 2: Dheeraj’s current preferred image model for some workflows, especially warmer visuals and infographics.

• Nano Banana / Nano Banana Pro: Compared against GPT Image for image generation.

• Batch API: Mentioned as a way to reduce image generation cost by about half.

• Kling: Used for lighter video animation tasks such as animated covers or thumbnails.

• Veo: Used for higher-quality video clips, with Dheeraj noting it is more expensive than Kling.

• Descript: Video editing tool Dheeraj uses, partly through its MCP server.

• Underlord: Descript’s AI assistant, which Claude Code can interact with through the Descript MCP setup.

• Remotion: Open-source tool for creating programmatic video overlays, text effects, slides, and faceless video assets.

• Playwright: Used for browser automation, especially when API access is limited or fragile.

• Chrome extensions: Dheeraj builds extensions for tasks he wants automated in the browser.

• n8n: Dheeraj’s always-on automation and distribution layer, still used for social posting, PDFs, and workflows that already work well.

• Oracle Cloud: Dheeraj hosts parts of his system on an Oracle Cloud instance so workflows can run even when his computer is off.

• Notion: Dheeraj’s structured planning layer for content calendars, review states, approvals, and shared pages.

• Notion API: Dheeraj prefers direct API access over the Notion MCP server because of token usage.

• SQLite: Used for searchable Substack archives, analytics, subscribers, magic links, and structured data.

• Substack Intelligence: Dheeraj’s name for the layer that collects Substack data into his SQLite database.

• Substack Live: Source of clips that Dheeraj processes and distributes through his automation setup.

• Obsidian: Discussed as an alternative file-based system, especially for single-player thinking and agent-readable Markdown.

• Glyph: The creative AI tool I use for The AI Maker thumbnails, infographics, and One Shot Show visuals.

• Typefully: My current tool for posting and scheduling LinkedIn carousels from Cloud Code outputs.

• Google Drive: Mentioned as one possible place to host video files for downstream automation.

• Twitter/X API: Discussed because video posting through the API may require a more expensive developer tier.

• LinkedIn, TikTok, Facebook, Instagram, YouTube: Social and video channels Dheeraj’s distribution layer touches or supports.

• CapCut: Mentioned as a manual editing tool Dheeraj still uses for placing video overlays.

• ElevenLabs: Mentioned as the likely voice cloning or voiceover layer for future faceless video automation.

• Reddit: Mentioned as a research source where Gemini can sometimes help when other fetch paths struggle.

• GenAI Unplugged: Dheeraj’s newsletter and broader AI education work.

Michael writes for Forbes, Harvard Business Review, and Fortune. His articles have been seen over 100 million times. On Medium, his average post pulled more than 250,000 views. For the past decades, he has been obsessed with one question: how do you build a system that reliably produces blockbuster content, not just one good article?

These days he writes Blockbuster Blueprint, where he breaks down how to apply that system using AI. He is also building Cozora (where I’m an active creator and contributor), an AI community where members learn directly from the creators behind some of the most interesting AI workflows on the internet. Michael co-hosts weekly masterclasses there with practitioners walking through how they actually build.

Blockbuster Blueprint

Receive a step-by-step, proven system to create 10x quality & quantity content with AI. Weekly emails contain a deep-dive or video lesson from a famous thinker and an easy way to apply it. Think Masterclass for idea creators.

By Michael Simmons

A few weeks ago, Michael invited me on his livestream to share how I run AI Maker inside Claude Code. We talked about skills, MCP, the CLI, and how I have been wiring most of my newsletter workflow into one harness. After that conversation, one thing was clear: we both love Claude Code, and we both keep finding new ways to bend it around our own work. In case you missed it, you can watch the session here:

So this time I invited him on. Because in that same conversation, Michael casually mentioned a workflow that I could not stop thinking about. He uses podcasts as a research source for his Claude Code setup. Not as background entertainment. As actual raw material that flows into the same vault his agent reads from when he is drafting a Forbes piece or a newsletter post.

That is what I wanted him to walk through on this episode. And the answer he kept coming back to was podcasts.

Podcasts Are a New Source for Your LLM Wiki

When Andrej Karpathy posted his LLM wiki idea, most of us latched onto the same intake sources. Articles. Web clippings. Book highlights. Old documents. Things you read on the internet, saved to Obsidian, and pointed Claude Code at.

I wrote about it in this post:

That works. I do a version of it. I’m sure a lot of you do too.

But there is a whole other channel of information most of us already consume every day that almost never makes it into the vault: podcasts.

Think about how much of your AI learning right now happens through audio. If you’re like me, you might be listening to Lex Fridman, Lenny’s Podcast, Dwarkesh, Moonshot by Peter Diamandis, etc. The point is: podcasts are where the most interesting people in AI think out loud, often in more depth than they ever do in writing. You listen on a walk, on a commute, while cooking. You hear something that lands. An hour later, you cannot remember which episode it was, let alone the timestamp.

That insight is gone. It never enters your second brain. It never becomes raw material for Claude Code to draft from.

Michael’s setup fixes that. He treats podcasts as a first-class source for the LLM wiki, on the same level as articles and books. Every episode he listens to is a potential stream of clips, transcripts, and atomic notes flowing into the same vault his Claude Code agent reads from.

That single shift, treating audio as a real intake source instead of background entertainment, is what I want to walk through.

💡 A quick related note…

I found this entire Claude free guide library. It maps out everything you need to know about Claude. From beginner to expert. 10+ free guides. Claude 101, Cowork, Skills, Code, Teams.

Access it here → claude101.com (there is no catch, no paywall).

How the Podcast Pipeline Actually Works

The tool doing the heavy lifting is Snipd. I had heard of it. I had not really tried it. After this conversation, I am setting it up this weekend.

Snipd is a podcast app, but the part that matters is what happens when you tap the snip button. Snipd uses AI to figure out the actual context: where the idea started, where it ended, who said it. You get a clean clip with a full transcript already attached, and a star button to mark the ones you want to keep.

That is the unlock. Every podcast you already listen to becomes a stream of small, time-stamped, transcribed, attributed notes. Instead of typing and summarizing manually, you just keep listening as usual and tap when something resonates.

Then Snipd syncs the starred clips into Obsidian, Notion, or Readwise. A few clicks to set up. After that, every clip you star while walking the dog or commuting shows up in your vault, ready for Claude Code to read.

Michael’s vault now has around 11,000 notes in it. A lot of them came in this way.

A few details from the livestream demo that I had not seen before:

• You can follow specific guests, not just shows. Michael follows Sam Altman, Dario Amodei, Demis Hassabis, Andrej Karpathy, and a few hundred others. When any of them shows up on a podcast he does not normally listen to, the episode lands in his queue.

• You can chat with an episode. Remember a guest said something about agent harnesses but cannot find where? Ask the episode. It jumps you to the timestamp.

• You can upload outside content too. Books from Libro.fm as MP3. YouTube videos. Even long-form articles. Michael built a small Claude Code skill that takes an article he wants to read, sends it to ElevenLabs, gets the MP3 back, and pushes it to a personal RSS feed that shows up in his podcast player. The article becomes a podcast he can clip from.

Once the clip is in the vault, Claude Code can do anything with it. Michael uses the same vault to draft articles, share clips into a paid subscriber WhatsApp group, and run a weekly summary that stitches starred clips together.

The system is doing the work. He is just listening.

Why Podcast Clips Are a Better Than Book Highlights and Saved Tweet

I want to call out one thing that I think gets missed when people talk about second brains.

Most second brain advice treats all sources the same. A book highlight, a tweet, a clipped article, a meeting note. Throw them all in, link them up, query later.

In practice, the source matters a lot for what Claude Code can actually do with it.

A book highlight is just a sentence on its own. No speaker, no context, no surrounding argument. A saved tweet is short and usually missing the thread. A clipped article often loses the part of the argument right before the line you cared about.

A podcast clip is structurally better. It has a speaker you trust. It has a timestamp. It has the surrounding 60 seconds of context. It has a full transcript. And because someone said it out loud, it usually carries the actual argument, not just the conclusion.

When Claude Code searches across 11,000 notes looking for material to draft a piece, that extra context is what lets it pull genuine evidence instead of generic summaries.

This is also why Michael does not just use Snipd for podcasts. He keeps converting other formats into audio so they enter the system through the same pipe. Every input ends up with the same shape: speaker, timestamp, transcript, clip. That consistency is what lets the second brain compound instead of becoming a junk drawer.

Share

How to Add Podcasts to Your Second Brain This Week

If you already have an LLM wiki or second brain running on articles and old documents, the good news is you do not need to redesign it. Instead, you can simply plug podcasts in as one more source.

Here is what I would do this week:

1. Install Snipd and import the shows you already listen to.

2. Pick three guests you trust and follow them as people, not just their shows.

3. For the next week, tap the snip button every time something hits. Star the ones you want to keep.

4. Set up Obsidian or Notion, then start syncing them together so the clips land in your vault automatically

5. Then, and only then, point Claude Code at the vault and ask it to surface patterns or draft something from your clips.

That is the loop. The reason it works is that you are not adding a new habit. You are bolting capture onto a habit you already have.

Other Threads From the Conversation

We covered more ground than just Snipd. A few threads worth pulling on, each one probably its own future post:

1. Codex is now a real alternative to Claude Code. I opened the call telling Michael I have been going crazy with Codex lately. Not the CLI. The app. Claude Code still has the better agent harness and structure in my opinion, but Codex feels like a polished super-app you can actually live in, instead of a terminal. You can even open Claude Code inside Codex and run both models side by side.

2. How we use AI has been evolving fast, and Claude Code is the latest jump. Think about how this has changed in just a couple of years. First it was pure question and answer. Open ChatGPT, ask something, copy the output into wherever you actually do your work. Then it became AI automation. You opened Make.com or Zapier and built a deterministic workflow by chaining steps together: this trigger fires, then this AI step runs, then the result lands in this app. It worked, but every workflow was a small project. Michael told a story on the call about spending eight hours one day in Make.com trying to build a single workflow. Now we are in a third phase. Claude Code, Codex, and tools like them can do most of those workflows directly, just by being asked. The same thing Michael spent eight hours wiring up in Make.com, Claude Code did in 15 minutes. The reason this matters is not just speed. It is that the cost of trying a workflow has dropped to almost nothing, which means you experiment with way more of them.

3. AI video is still expensive enough to matter. Dheeraj walked through his HeyGen experiment. Around $5 per minute at scale via the API. A 30-minute video burns through a $30 plan in one shot. Useful if you already have a funnel and a high lifetime value per viewer. Painful if you are starting out and trying to automate your YouTube channel from zero. The “AI does everything for me” pitch in YouTube videos hides this part.

4. The uncanny valley is closing faster than people think. Michael described three stages of AI content. Stage one is obviously bad and no one engages. Stage two is clearly AI but the value is unique enough that people watch anyway. He used the Epstein Files Podcast as an example, where someone used AI to chew through three million leaked files and shipped 150 fact-based episodes in one drop. Stage three is when AI content gets more personalized, more researched, and easier to update than anything a human can produce one-to-many. We are somewhere in stage two right now.

A Note on the Bigger Pattern

One thing Michael said near the end stuck with me. He thinks the cost of producing high-quality content, once your funnel is set up, is going to keep dropping. The bottleneck for most of us was never the writing; it was the raw material and how we stitch it all together.

That is the part the podcast pipeline really shifts. The audio you are already consuming becomes raw material your Claude Code agent can actually work with. Quotes you would have forgotten turn into clips you can search, link, and draft from.

Articles and web clippings still belong in the wiki or second brain. Podcasts just join them as one more source, and probably the one with the highest ratio of insight to effort once it is set up.

That is the version of the LLM wiki or second brain I am actually going to use.

Subscribe now

Episode Details

One Shot Show, Episode 9. Season 1 Finale.
Live every Wednesday at 10:00 AM EST on Substack.

Guest: Michael Simmons, founder of Blockbuster Blueprint. Forbes, HBR, and Fortune contributor.

Timestamps

• 00:00. What is exciting in AI right now: Codex vs Claude Code

• 04:00. Welcome and season one wrap

• 06:22. Michael’s background and the blockbuster framework

• 09:00. From ChatGPT to Make.com to Claude Code

• 14:52. Connecting writing to a second brain

• 17:00. Michael’s news-to-article workflow

• 18:30. Skills, chained skills, and the second brain

• 20:00. How to actually start a second brain

• 28:30. Snipd demo: AI clipping, follow-by-guest, audio hub

• 36:00. Skills for ElevenLabs, YouTube, and weekly summaries

• 41:00. Build vs buy and the cost of AI tools

• 50:00. AI-generated content and the uncanny valley

• 55:00. One thing to start this week

• 58:00. Codex and Claude Code as a bridge

Resources Mentioned

• Snipd (snipd.com). AI podcast app with smart clipping, follow-by-guest, chat with episode, and Obsidian/Notion sync. Upload your own audio at upload.snipped.com.

• Andrej Karpathy’s LLM Wiki. The second brain idea Michael built around.

• Libro.fm. Audiobook MP3 source you can upload to Snipd.

• ElevenLabs. Text-to-speech, used in Michael’s article-to-podcast skill.

• HeyGen. AI avatar video tool Michael uses for weekly summary clips. Around $30 per month for 10 minutes of video, or roughly $5 per minute via API.

• Obsidian / Notion. Second brain vaults, both sync directly with Snipd.

• Claude Code. Michael’s current agent harness for skills, search, and drafting. Opus 4.6 was the unlock for him.

• Codex. OpenAI’s coding agent app. Came up as a complement to Claude Code, especially around weekly limits and bridging plans.

• Blockbusters by Anita Elberse. The book that shaped Michael’s thinking about high-quality content as a strategy.

In Episode 1, Dheeraj showed a Claude Code agent that could take a topic, research competitor content, pull sources, and create a brief for a new article. That was useful because it solved the painful part most people know too well: staring at a topic and wondering what angle has already been covered.

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

This episode pushed the idea one step further.

Instead of asking an agent to research one topic on demand, Dheeraj built a competitor intelligence agent in Claude Cowork. The agent watches a competitor list, runs weekly scans, finds content gaps, ranks opportunities, and keeps logs so the next run does not start from zero.

That last part is the whole story for me.

The interesting shift goes beyond “AI can research competitors.” We already knew that. The more useful shift is that research can start compounding. The agent can compare this week’s scan against last week’s scan, remember your corrections, notice patterns over time, and change its recommendations based on what already happened.

That distinction matters because most AI research still resets every time you open a new chat. You get a useful answer, then the next session begins cold again.

💡 Quick related note…

If you use Claude long enough, you’ll hit the usage limit. I did. My friend Ruben Hassid figured out the fix: 23 habits that cut his token waste so much he now hits the limit once a month instead of by 2 pm.

Free guide → How to stop hitting Claude usage limits - by Ruben Hassid

Back to the bigger research problem.

That works for one-off research. It starts to break down when the job is monitoring change over time.

Why One-Time Research Is Starting to Feel Limited

Most AI research workflows still work like this:

1. You have a topic.

2. You ask Claude, ChatGPT, Perplexity, or another AI tool to research it.

3. You get a brief.

4. You write the thing.

5. Next time, you start again.

That is already better than manually opening ten tabs and piecing the picture together yourself. I still do plenty of one-off research because sometimes that is all I need.

But competitor tracking is different.

If you run a newsletter, blog, product, agency, or any business where timing matters, today’s competitor posts are only part of the picture. You need to know what changed. Which topics keep coming back. Which gaps you ignored. Which recommendations the agent already made two weeks ago that you never acted on.

Dheeraj used his travel blog as the example. His site covers Himalayan travel, road trips, seasonal route updates, and practical guides. For a travel site like that, freshness matters. If a competitor publishes a route-opening update before him and he waits three weeks, he loses the timing advantage.

That is the weakness of one-time research. It can answer “what should I write about this topic?”

It cannot easily answer “what did I miss, what changed, and what should I stop delaying?”

That is what this competitor intelligence agent was built to do.

The Architecture Matters Because It Changes the Question

Before we get into what the agent found, I think it helps to understand the shape of the system.

Dheeraj published the full technical walkthrough on his newsletter, so I am not going to recreate the build guide here. If you want the exact files, folder scaffold, and setup steps, read his version. What I want to pull out is the architecture because that is the part anyone can learn from even if they never build this exact agent.

The agent has four practical layers:

1. Tool layer: what the agent can use to reach the web. In this demo, Tavily handled search, extract, crawl, map, and deeper research.

2. Knowledge layer: what the agent remembers between runs. Corrections, patterns, scan history, and lessons from past failures live here.

3. Context layer: what the agent knows about the creator. Business context, audience, content pillars, current calendar, competitor list, and what counts as a meaningful gap.

4. Operating layer: how the agent should behave. Weekly scan, monthly review, topic white space check, output format, cost rules, and when to update memory.

That is the practical lesson. A useful agent needs more than a prompt with web access. It needs a small decision system around it. When those layers work together, the question changes.

The Folder Structure Worth Copying

Dheeraj’s full post includes the exact project folder. I think this is useful as a reference because it shows how the abstract layers turn into files.

The structure looks roughly like this:

competitor-intelligence/
├── CLAUDE.md                          ← The operating brain
├── memory.md                          ← Blank to start, updates itself
├── context-profiles/
│   ├── business-context.md            ← Who you are
│   ├── competitor-watchlist.md        ← Who you watch
│   └── content-strategy.md            ← What gaps matter
├── logs/
│   └── competitor-index.md            ← Blank, populated after first scan
├── templates/
│   ├── weekly-scan-template.md
│   ├── topic-whitespace-template.md
│   └── monthly-review-template.md
└── output/
    ├── weekly-scans/
    │   └── _example-weekly-scan.md    ← Real format example
    └── topic-checks/
        └── _example-topic-check.md    ← Real format example

Here are some details for each file and folder:

1. CLAUDE.md is the operating brain. This is where the agent learns how to behave, which scan modes exist, how to use Tavily, how to format output, and when to update memory.

2. memory.md is where the agent stores corrections and patterns that should survive between runs.

3. The context-profiles/ folder is the taste layer. business-context.md tells the agent who you are. competitor-watchlist.md tells it who or what to watch. content-strategy.md tells it what matters, what to ignore, and what is already planned.

4. The logs/ folder is the trail. It gives the agent a way to see what happened across previous scans instead of treating each run as new.

5. The templates/ folder keeps the outputs consistent. Weekly scans, topic checks, and monthly reviews should not all come back in a different shape.

6. The output/ folder is where the work lands. Over time, this becomes the source material the agent can compare against.

That is the part I would copy from Dheeraj’s build: the pattern of operating brain, memory, context, logs, templates, and output. The travel niche and exact competitor list are just his version of it.

The old research agent started with a chosen topic. You gave it something like “research Ladakh travel,” and it returned a brief, sources, angles, and an outline.

The new competitor intelligence agent starts with a watchlist. It already knows the competitors. It already knows Dheeraj’s content pillars. It already knows what his travel site covers, what he avoids, which audience he writes for, and what counts as a meaningful gap.

So instead of asking, “How should I write this piece?”

The agent asks, “Which pieces are worth writing at all?”

During the demo, Dheeraj showed three core modes:

1. Weekly scans: Check the competitor list and surface high-priority gaps.

2. Monthly scans: Look for broader patterns over a longer period.

3. Topic white space checks: Ask whether a specific idea has a real opening, such as solo women riders on Himalayan roads.

This changes the whole ouput. Instead of producing a research brief, the agent now generates ranked gaps, suggested article ideas, and follow-up recommendations.

That sounds like a small difference, but it changes how the agent fits into the creative process.

For those of you who find it easy to get ideas for what to write about, I bet many of you find it hard to prioritize. There are always too many possible topics, too many signals, too many interesting things to chase. The agent’s real job is not to add more ideas; it is to help decide which ideas deserve attention now.

Subscribe now

The Memory Layer Is What Made It Feel Different

The biggest addition from Episode 1 was the memory layer.

Dheeraj had the agent read a memory.md file, output logs, competitor indexes, and scan history. The point was simple: the agent should not treat every run like a fresh conversation.

It should know what happened last time.

For example, after one scan, the agent might surface a high-priority article idea because a competitor published a timely road update. If Dheeraj ignores it, the next scan can notice that the same gap is still open and raise the urgency.

That is a very different kind of recommendation from “here are five content ideas.” It has memory of the recommendation. It has evidence that the recommendation was not acted on. It can compare the current scan against past scans and say, in plain English, “You should probably stop delaying this.”

I added a similar point during the live because this is how I think about research for AI Maker too. If I run AI research every week, isolated summaries are only the beginning. I want the system to notice that AI agents have been showing up repeatedly across the last four scans, or that a specific theme keeps returning, or that my own content plan keeps dodging a topic readers probably need.

The value comes from the pattern across reports.

That is why the logs matter. They turn research from a snapshot into a trail.

I wrote in-depth post about it here:

Of course, there is a caveat. More memory does not automatically mean better output. Dheeraj said his memory file is still something he manages manually, and the logs need a rolling window so they do not get too heavy. I agree with that. If the agent reads every old file forever, it eventually becomes slow, noisy, and expensive.

The craft is deciding what deserves to be remembered.

Tavily Replaced Three Tools in the Research Layer

Another practical shift in this episode was the research tooling.

In Episode 1, Dheeraj used Perplexity, Firecrawl, and Jina AI together. Perplexity handled synthesis, Firecrawl handled scraping, and Jina AI acted as a fallback.

For this competitor intelligence agent, he moved toward Tavily as the primary research connector.

That made sense to me because Tavily covers several jobs in one place: search, crawl, extract, map, and deeper research. When you are building a recurring agent, fewer moving pieces can matter more than having the flashiest individual tool for each job.

I mentioned during the stream that this was a big mover for me too.

My frustration with Perplexity inside an agent is that it adds another reasoning layer. Claude asks Perplexity. Perplexity runs its own agentic search and summary. Then Claude reads that output and reasons over it again.

Sometimes that is useful. Other times, I just want Claude to get closer to the raw internet data and make the judgment itself.

I am not saying everyone should switch. I am still testing where Tavily fits best in my own setup. The bigger lesson is that the agent should let you swap the research tool without rebuilding the whole system. The blueprint stays familiar. The tools change when the job changes.

Where the Agent Started Showing Judgment

This is where the demo stopped feeling like a competitor tracker and started feeling closer to editorial judgment.

The useful part was not that the agent could search the web. Lots of tools can do that now.

The useful part was that it had enough context to decide what the search meant.

Taste Before Search

The best part of the demo happened before the agent ever ran a scan. Dheeraj had already written down his business context, content strategy, competitor watchlist, memory rules, and operating instructions.

That is what makes the output useful. Without those files, a competitor scan is just a summary of what other people published. Helpful, but generic.

With those files, the scan can answer a better question: “Given who I am, what I write, what I already cover, and what I want to avoid, what should I pay attention to?”

That distinction matters because most AI research output feels bland for the same reason. The model does not know your taste, constraints, off-brand angles, or seasonal timing.

The context files give the agent taste before it touches the web.

Constraints Before Ideas

During the demo, Dheeraj asked whether he should write about solo women riders on Himalayan roads.

The agent skipped the easy answer: “Yes, there is a gap. Write it.”

It flagged a constraint: Dheeraj should not publish that guide without first-hand experience or a co-author who actually fits the topic. Since he is not a solo woman rider, the agent suggested finding someone from his community or network who could bring real experience.

That was my favorite moment in the whole session.

A basic content tool would call the gap an opportunity and move on. This agent connected the topic to credibility, reader trust, and what kind of source would make the article worth publishing.

That is the difference between content ideas and editorial judgment.

I do not want agents that only tell me what can be written. I want agents that tell me what should not be written yet because the evidence is not good enough.

That is harder to build, but it is much more useful.

The Less Fun Part: Connectors Can Get Expensive and Noisy

The Q&A brought up something people do not talk about enough: connectors and MCP servers can quietly eat a lot of tokens.

One of audiences asked which actions use more credits for agents: searching local files, accessing Google Drive, accessing Notion, and so on.

Dheeraj’s answer matched my experience. Local file search is usually lighter. Once you trigger MCP connectors, token usage can climb quickly because the model has to inspect tool schemas, tool results, and extra data from those services.

That is why Dheeraj disabled every connector he did not need for the run. Gmail, Calendar, Drive, Notion, and other tools stayed off. Tavily stayed on.

That sounds boring, but it is important.

Agents get worse when they have too many irrelevant tools available. They consume more context, take longer to decide, and sometimes wander into services that have nothing to do with the task.

My rule is getting stricter here:

1. Turn on only the connector needed for the job.

2. Prefer direct API or CLI access when it is available and reliable.

3. Avoid connecting everything just because the tool makes it easy.

4. Treat MCP access like a budget decision, not a default setting.

This is one of those unglamorous operational details that separates a working agent from a demo. The demo looks better when everything is connected. The real system works better when the agent has fewer ways to get distracted.

What Happens If the Agent Learns the Wrong Thing?

Another audience asked the most important safety question near the end: what happens if bad data enters the system and starts corrupting the agent’s future decisions?

That is a real risk.

If your logs contain hallucinated information, stale competitor data, or wrong conclusions, the agent may keep building on top of that bad foundation. The more “memory” you add, the more you need a way to audit and roll back.

Dheeraj’s answer was practical: use Git or some other version control for the folder. If the agent edits memory files, logs, or indexes in a bad way, you can inspect the diff and roll back.

I would add one more thing: start with plan mode when the action matters.

If the agent is only writing a research report, the downside is small. If it is editing files, updating indexes, changing memory, or touching business data, I want to see the plan first. Claude Cowork’s to-do list helps here because you can interrupt, redirect, or stop the run if the plan looks wrong.

Hooks can also help block dangerous actions in Claude Code. Dheeraj mentioned using hooks to prevent file deletion. But hooks are not magic. If you are working with important files or live data, you still need backups, permissions, and human review.

This is the part of agent building that feels less exciting but matters more over time.

The smarter the agent gets, the more boring your safety habits need to be.

How to Use This in Your Own Work

Dheeraj used a travel blog as the example, but the structure works anywhere you need to notice change over time.

The useful move is copying the shape:

1. What should the agent watch? Competitors, customers, job listings, research papers, product updates, support tickets, internal docs, or social conversations.

2. What should the agent care about? Your goals, audience, constraints, deadlines, quality bar, and what counts as important.

3. What should the agent remember? Past recommendations, ignored opportunities, recurring risks, repeated questions, and corrections you made.

4. How often should it run? Weekly scan, monthly review, or topic-specific check when a question comes up.

For a creator, this could surface topics competitors keep covering that you have ignored.

For a business owner or entrepreneur, it could track customer complaints, competitor offers, and recurring buying objections so your next offer is not based on the loudest message from yesterday.

For a sales team, it could watch competitor positioning and flag when prospects keep asking about the same objection.

For an operator, it could review recurring process issues and tell you which problems keep coming back after you thought they were fixed.

The output should not be “here are 10 things I found.” That is how you get more noise.

The better output is closer to:

1. “This pattern showed up three times this month.”

2. “You already acted on this, so do not treat it as new.”

3. “This looks urgent, but the evidence is thin.”

4. “This keeps getting ignored, and the cost of waiting is rising.”

5. “This is worth doing now because it matches your current goal.”

That is the practical value: less information overload, more pressure on the decisions that matter.

Subscribe now

The Takeaway

The practical takeaway from Episode 8 is simple:

If your AI research starts fresh every time, you are leaving value on the table.

You do not need Dheeraj’s full competitor intelligence setup to test the idea. Start smaller: pick one watchlist, one strategy file, and one memory file. Then run the same research process once a week and save the output. After a month, ask the agent to compare the latest scan against the earlier ones.

The first report will probably be ordinary.

The fourth report is where the pattern starts to show.

That is the real promise here. The agent does not need to be perfect on day one. It needs to preserve enough useful history that each run has more judgment than the last one.

I am still cautious about over-automating this. A bad content calendar generated faster is still a bad content calendar. But I am convinced the compounding layer matters.

The future of AI research includes better search, but the bigger unlock is research that remembers what it already learned.

One Shot Show Details

This was Episode 8 of One Shot Show, Season 1. We go live every Wednesday at 10:00 AM EST on Substack.

Season 1 episode list:

1. Episode 1: Building a Content Research Agent with Claude Code

2. Episode 2: Google Opal vs n8n vs Make

3. Episode 3: Substack Competitive Analysis Using Claude Cowork

4. Episode 4: n8n vs Claude Code and Cowork

5. Episode 5: Claude Channels vs OpenClaw vs Dispatch

6. Episode 6: Notion AI Agent

7. Episode 7: Claude Skills with Ilia from Prosper

8. Episode 8: Competitor Intelligence Agent with Claude Cowork

9. Episode 9: How to Turn 1,000 Podcast Clips Into a Living Knowledge Base with Claude Code

Timestamps:

• 00:00: Welcome to Episode 8 and recap of the season

• 01:51: Dheeraj introduces the competitor intelligence agent

• 03:40: Research agent vs intelligence agent

• 05:46: Watchlists, weekly scans, monthly scans, and topic checks

• 06:35: Moving from Perplexity, Firecrawl, and Jina AI to Tavily

• 07:34: Wyndo on why Tavily can simplify the research layer

• 09:02: Adding the memory layer

• 10:57: Business context, content strategy, competitor watchlist, and operating instructions

• 12:06: Claude Cowork setup begins

• 16:24: Startup protocol check and context loading

• 22:13: Business context and audience files

• 23:58: Content strategy file and calendar

• 25:13: Competitor watchlist file

• 26:31: Tavily connector setup

• 29:35: Wyndo asks about instructing the agent to use Tavily

• 31:33: Running the weekly scan

• 34:00: Agent adapts after an initial zero-result search

• 35:00: Memory management and rolling logs

• 36:48: Terry asks how the agent gets better over time

• 39:35: Wyndo on connecting current research to past patterns

• 40:34: Weekly scan output and follow-up suggestions

• 41:50: Topic white space check for solo women riders

• 44:03: The agent flags the need for first-hand experience

• 45:29: Updating memory to skip medium-ranked gaps

• 46:22: Scheduled tasks and Dispatch

• 48:10: Pierre asks about credits and connector usage

• 49:44: Wyndo on MCP token usage and tool sprawl

• 53:24: Terry asks about corrupted data and hallucinations

• 54:33: Git, plan mode, and safer agent runs

• 55:07: Wyndo on accurate context files reducing hallucination risk

• 56:00: Hooks and dangerous actions

• 58:12: Closing notes and Season 2 preview

Resources Mentioned

• Claude Cowork: The Claude interface Dheeraj used to run the competitor intelligence agent through a visual project session. Included in Claude’s product family.

• Claude Code: Anthropic’s terminal-based agent tool. Dheeraj said he usually prefers it because it gives him more direct control.

• Claude Desktop / Claude app: The broader Claude interface where Cowork lives, including chat, projects, connectors, and model selection.

• Claude Sonnet: The model Dheeraj selected for the demo. No pricing was discussed during the session.

• Claude Opus: Mentioned during the cost discussion as expensive when used through direct API calls.

• Claude Skills: Reusable instruction packages discussed as part of previous One Shot Show episodes. Dheeraj referenced them while showing the Cowork UI.

• Skill Creator: Mentioned indirectly through the previous episode with Ilia, where skills were created and tested.

• Tavily: The main research connector used in this agent. Dheeraj and I discussed it as a way to handle search, crawl, extract, map, and deeper research in one tool.

• Perplexity: Used in the first research agent architecture. We discussed it as useful, but sometimes an extra reasoning layer when connected to Claude.

• Firecrawl: Used in Episode 1 for scraping competitor pages. In this episode, Tavily replaced part of that role.

• Jina AI: Mentioned as a backup or fallback layer from the earlier research agent setup.

• MCP: The connector protocol behind many Claude integrations. We discussed how MCP servers can increase token usage when too many are enabled.

• Tavily MCP / Tavily connector: The specific connector Dheeraj enabled in Cowork for live internet research.

• Claude built-in web search: Mentioned as something the agent should avoid when Tavily is intended to be the only research tool.

• Gmail connector: Mentioned as a connector Dheeraj disabled because it was not needed for this run.

• Google Drive connector: Mentioned during the connector and token usage discussion.

• Google Calendar connector: Mentioned as a connector Dheeraj disabled for the demo.

• Notion API / Notion connector: Mentioned as a possible data source and as Dheeraj’s own place for maintaining a content calendar.

• Chrome connector: Mentioned in the Cowork connector list as something Dheeraj disabled for this session.

• Excalidraw connector: Mentioned in the connector list as something Dheeraj disabled.

• Visual Studio Code: Dheeraj said he often uses Claude Code with VS Code.

• Dispatch: Claude Cowork’s mobile companion. Dheeraj described it as a way to trigger a topic white space query from a phone.

• Scheduled Tasks: Cowork feature Dheeraj showed for running weekly or monthly scans automatically.

• Routines: Mentioned as another Cowork feature, though Dheeraj said he probably would not use a routine for this specific agent.

• LaunchCTL: Mentioned as the kind of scheduled job Claude Code might set up on a Mac when asked to automate recurring tasks.

• Git: Recommended as version control for agent folders so corrupted memory, logs, or data can be inspected and rolled back.

• Hooks: Mentioned as a way to block dangerous actions, such as unwanted file deletion, especially in Claude Code.

Ilia writes Prosper, the newsletter about AI and software that gives you an unfair knowledge advantage. His post on the 3-document system for AI memory is still one of our most-shared pieces, followed by “When NOT to Use AI,” and, most recently, “Claude in Chrome,” “Grok 4.2 Agents Updates,” and “Anthropic Q1 updates.”

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

Here are Ilia’s latest three posts that you might want to check out:

1. Claude Automation: Routines vs `/loop` vs Desktop Tasks

2. Before You Use Claude, Create This File

3. My AI Assistant Now Lives in Telegram. Easier Setup Than OpenClaw

He came on to answer the question I keep getting from readers:

“Should I be building Claude Skills yet, and how do I know which ones are worth the effort?”

Before we dive in, let’s understand what Claude Skills are.

💡 Quick context if you’re new to Skills

A skill is a reusable instruction set Claude follows when relevant. You write it once as a folder containing a SKILL.md file and any reference docs or templates. Claude pulls the skill in automatically when your message matches its description, or you can invoke it by name with a slash command. Think of it as an SOP that runs itself.

The reason to care is simple. Most of us burn a meaningful chunk of every Claude session re-explaining the same context: voice rules, audience details, examples, banned phrases. Skills move that setup out of the prompt and into a file Claude reads on its own. You build the skill once, and the work compounds from there. The same skill works in Claude Desktop, Claude Cowork, and Claude Code, so the time you put in once pays off across every interface you use.

It’s a fair question. Anthropic shipped Skills 2.0 quietly a few weeks back. The skill creator got dramatically better. People started posting screenshots of folders with 50+ skills. Meanwhile, most people I talk to still have zero.

I have over 30 skills in my own setup. Every single one came from the same trigger: I caught myself doing the same thing manually for the third time in a week, got tired of retyping the setup, and built a skill so I’d never have to type it again.

That’s the rule. Friction first. A skill earns its place when I’m already tired of doing it manually. You shouldn’t build a skill just because it looks cool. Cool won’t lead you to anything useful if you don’t actually use it or care about it.

So I asked Ilia the question I’d been sitting on: how do you decide what becomes a skill? He showed me the question he asks himself before he builds anything:

“What am I doing too often manually?”

That’s the rule we landed on during the live, and it’s the rule keeping my skill folder useful instead of bloated.

How to spot a skill candidate

Dheeraj put the rule in an even tighter form during the live:

“If I have to repeat something like a long prompt three times a week, that’s a pattern. Then I convert it into a skill.”

Three times in a week. That’s the threshold I use too.

Once I started watching for it, it became obvious whenever I found myself:

• Explaining the same writing rules.

• Pasting the same platform formatting instructions.

• Asking for the same type of critique.

• Turning one newsletter into the same set of social formats.

• Running the same research process before writing.

Those are signals of skills worth turning into systems.

But spotting the candidate is the easy part. The harder craft is evaluating whether a skill actually produces better output than a prompt would on its own. As I said during the show:

“Your time is spent not building the skill. Your time will be spent evaluating the skill output.”

That’s where the episode shifted from “what is a skill” into “how to build one that holds up.” Ilia built one live, showed how the new skill creator runs evals, then demoed a real research skill he uses for running his newsletter.

Subscribe now

What will you get inside of post

The rest of this post walks through that live build for AI Maker Lab readers. You’ll get:

• The full session recording. The whole live, including the second-opinion skill built from scratch, the Fast Research demo Ilia ran from his phone, and the audience Q&A on Dispatch and memory.

• Ilia’s Fast Research skill, packaged for install. Drop the folder into your Claude setup, give it a topic, and get a sourced research brief saved as a Markdown file in your project. The same skill he ran live on the show.

• A build walkthrough you can run tonight. The four-element prompt structure that gets cleaner output from the skill creator, how to read the eval panel before a skill ships, when to trigger skills with plain English versus a slash command, and how to set up Fast Research’s first-run interview so the briefings come back filtered through your editorial lens, not Ilia’s.

If you’ve been thinking about Claude Skills for a while and keep putting it off, the recording plus the skill plus the walkthrough should compress the first month of fumbling into a Saturday afternoon.

What the Skill Creator actually is

A quick note on the tool that did most of the work in this episode, since the rest of the post assumes you know what it is.

The Skill Creator is a meta-skill: a skill whose job is to build other skills. Anthropic ships it pre-installed across Claude Desktop and Claude Cowork so you don’t have to download or configure anything. It’s already there the first time you open Claude. You can see the details inside the Customize > Skill menu.

But if you use Claude Code, you’ll need to install the plugins first. I wrote an in-depth post about it here: From Blank Folder to Working System: How to Set Up Any Project in Claude Code.

To trigger it, mention it by name in your prompt:

“Help me create a [name] skill using the Skill Creator.”

That’s the whole invocation. When you mention “Skill Creator” in a prompt about building a skill, Claude loads the meta-skill and walks you through the build flow: scaffolding the SKILL.md, generating test prompts, running evals against them, and saving the result into the right folder.

Once you know the Skill Creator exists and how to call it, building a skill takes about five minutes.

The live build: a second opinion skill

The first live demo was a skill Ilia wanted to create during the show: a “second opinion” skill. He wanted Claude to push back on his ideas, frameworks, and drafts from multiple perspectives instead of agreeing too easily.

That use case made sense immediately. Writers need it. Builders need it. Anyone making decisions with AI needs it. The point isn’t to make Claude negative. It’s to stop Claude from defaulting to “great idea” when you actually need useful pressure.

What to include in your prompt to the skill creator

When you invoke the skill creator, the cleanest results come from putting four things in the prompt:

Read more

My AI setup runs on Claude Code and Obsidian. Everything. Writing, research, client work, newsletter drafts, my entire repo of ideas. It works really well for me, and based on my performance data, Claude Code posts have been some of the best-performing content I’ve published. A real segment of this newsletter already lives in that world with me, and I’ll keep writing for that group.

But I also hear from the other half of you all the time. You don’t want to open a terminal. You don’t want to spend weekends writing custom commands and sub-agents. You want AI that fits the tools you already use, without a second job as a configurator.

For a long time I didn’t have a clean recommendation for that group. “Just use ChatGPT” felt too shallow. “Build your own Claude Code setup” felt too deep. The middle path was missing.

That’s why I had from Solopreneur Code on One Shot Show last Wednesday. and I wanted to see someone who’d solved the same problem I solved, but from a completely different direction. Anfernee runs his entire business inside Notion AI. No Claude Code. No terminal. No custom scripts. He relies purely on Notion with one AI agent he calls Nova, and years of context.

Solopreneur Code

Weekly ideas, systems, and AI workflows for solopreneurs who want to build a profitable one person business without the hustle. Subscribe and get the free Solopreneur Success Hub.

By Anfernee

Solopreneur Code is Anfernee’s twice-weekly newsletter for solopreneurs who want to earn more and work less. Every issue covers practical systems, AI workflows, content creation, and digital products. Subscribe free and grab the Solopreneur Success Hub — ready-to-use systems that save 20+ hours a week.

If you want to go deeper after reading this post, start with these three:

1. First Digital Dollar Project

2. [Live with Wyndo] From $0 to $500: Why Your First Digital Dollar Changes Everything

3. It’s Been 2 Years on Substack: What 5,863 Subscribers (and Real Data) Taught Me

Watching his screen made me realize that the real problem I’ve been solving isn’t a technical one. It’s something I think a lot of you are quietly suffering from too, no matter which tools you use.

The copy-paste tax nobody talks about

You’ve probably heard some version of this advice: “Use the best tool for the job. Claude for writing. ChatGPT for reasoning. Gemini for Google stuff. Perplexity for research.”

It’s a half-truth. Yes, different models have different strengths. But every time you cross a tool boundary, you pay a tax. You manually carry the context over. And that tax compounds.

Think about what you do in a single writing session:

1. You look up your own past notes (Notion, Obsidian, or wherever your thinking lives)

2. You research the topic (Perplexity, Google, ChatGPT)

3. You draft (Claude, ChatGPT, or your writing tool)

4. You save the output (back to Notion, Google Docs, Substack)

If those four places are four different apps with four different AI models, you’re doing the work of the AI. You’re the one remembering what the research said. You’re the one re-pasting your voice guidelines every session. You’re the one holding the thread together.

You’ve become the middleman in your own business.

If this is the future promised by AI, I don’t think it will change how we work.

The reframe I needed

Here’s what Anfernee said on the show that reframed this for me:

“To me, context is a lot more important than whether the LLM name is powerful or not.”

That one line is the whole thing. Every AI company is racing to have the smartest model. Every Twitter feed is arguing about Opus vs. GPT-5 vs. Gemini 3 Pro. Meanwhile, the builder who’s 99% committed to one place, with years of history already loaded in, is running circles around people jumping between fresh chat windows.

The question stopped being “which AI is best?” It became “where does my work actually live, and can I let the AI come to me instead of me going to it?”

Two answers to that question work. Mine is Claude Code plus Obsidian. Anfernee’s is Notion AI. They look different on the surface, but they solve the same underlying problem: one home, AI that lives in it with you, no middleman work.

Since my path takes a long detour through terminal-land, the rest of this post is about Anfernee’s. But before we get into how he built Nova, a quick primer for anyone who hasn’t looked at Notion AI recently.

First, What is Notion AI?

Notion AI is the AI layer built directly into Notion. It lives in the sidebar, reads every page you have access to, and does the things you’d expect: summarize, draft, answer questions, generate content. What makes it different from opening Claude or ChatGPT in a separate tab is that it already knows everything in your Notion. No copy-paste. No file uploads. No “here’s the context you need first.”

Three things matter about where Notion AI is today:

1. Custom instructions. You can write a personality and rules for how the AI should behave (the equivalent of a CLAUDE.md file if you use Claude Code). Whatever you put in the instruction file is applied to every chat. This is the feature that turned Notion AI from “meh” into “actually worth using” when it launched late last year. Anfernee’s Nova is built on top of this.

2. Custom agents. Released in early 2026. You can now spin up specialized agents with their own instructions, triggers, and scheduled runs. Think sub-agents, but no-code. Anfernee’s “modes” (content writer, decision maker, strategy) are the pattern that predates Notion’s official custom agent release, and they still work the same way.

3. Model choice. Notion AI lets you pick the underlying model: Claude Opus, GPT-5, Gemini 3 Pro. On certain plans, Opus is unlimited inside Notion AI. That alone is a big deal if you’ve ever hit the Claude Pro usage cap at 10 a.m. and had to wait four hours.

Notion AI is the fastest way to have AI that actually knows your work, without building anything technical. If your notes, meetings, and projects already live in Notion, you’re already 80% of the way there. You just haven’t turned it on properly yet.

That’s what the rest of this post is about.

If you’re tired of being the router between six AI tools, this is the post that fixes it.

Meet Nova

Anfernee shared his screen and walked us through Nova.

Nova is his custom Notion AI agent. The name (Neural Operative Virtual Assistant) was suggested by Notion AI itself when he asked it what it wanted to be called. He also asked it to design its own logo. He’s been building Nova for years inside his Notion, which by his count holds roughly 15 million blocks across two years of writing, client work, meeting notes, and ideas.

Here’s what’s inside Nova’s custom instruction file:

Read more

It’s a fair question. Channels dropped a few weeks ago. Anthropic also banned the OpenClaw harness from running on their subscriptions last week. And suddenly the whole OpenClaw community started rethinking their setup.

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

So we ran both tools live on the stream. Dheeraj demoed Claude Code channels with a Telegram integration in under 30 minutes. We also walked through what it takes to get OpenClaw running, drawing from my own setup and Dheeraj’s experience deploying it to a server. Then we scored both across eight categories and tried to give you a real answer.

Here’s the short version: no, Anthropic didn’t kill OpenClaw. But they’re clearly walking in that direction, and the gap is closing faster than I expected. What actually matters is that these two tools solve different philosophies of autonomy, and figuring out which philosophy fits your workflow is the real decision.

Why Anthropic vs OpenClaw Matters Right Now

If you’ve been anywhere near the AI agent conversation lately, you’ve probably heard both names.

OpenClaw is the open source project that exploded in popularity because it let you run Claude autonomously on your own machine. You could give it a personality through config files like SOUL.md and USER.md. You could set up a heartbeat so it would monitor your email every hour or check your Notion to-do list at 2 a.m. without you touching it. People started building 24/7 AI employees on top of it.

Claude Code is Anthropic’s official CLI. Until a few weeks ago, it was mostly an AI agent you ran in your terminal. Then Anthropic started shipping new connection features. First remote control. Then dispatch. And now channels, which lets you connect Claude Code to Telegram, Discord, and iMessage through plugins so you can talk to your projects from your phone.

Read the full Anthropic updates for Q1 2026 right below 👇

So the surface-level question is: if Claude Code now lets me chat with my projects from Telegram, do I still need OpenClaw?

And the answer we landed on is more interesting than yes or no.

The Setup Tax Tells You Half the Story

Before the philosophical stuff, let me talk about what it actually feels like to get these running.

I set up OpenClaw back in February. Hands-on time for me was around two to three hours. Reading the docs, picking a server, walking through onboarding, connecting my Anthropic subscription, and getting it paired with Telegram. Not insane, but enough that I had to block out a real chunk of time on a weekend to get through it.

Dheeraj’s experience was rougher. He told the story on stream: his OpenClaw setup ended up taking around two days because his first cloud server attempt failed and he had to move everything to a different host. Once he was on the second server, things worked, but the failed attempt cost him a full day of debugging.

Then he pulled up Claude Code channels live during the stream and the contrast was immediate. He opened a Claude Code project, installed the Telegram plugin through the marketplace, made sure he had BUN installed, ran claude --channels plugin:telegram, created a bot through BotFather, and paired it to his session. The whole thing ran in under five minutes on camera.

We both agreed: if you already have Claude Code on your machine, channels setup is hardly anything. Under 30 minutes even if it’s your first time.

For a non-technical person, the real gap is the decision. If the initial setup makes you question whether it’s worth it, you’ll never get to the interesting part. And if you don’t want to spend time on the setup process, I don’t think you’ll want to maintain and improve it.

That’s the first half of the story. But setup ease alone doesn’t tell you why someone would still want OpenClaw.

Event-Driven vs Self-Driven: The Real Split

Here’s what clicked for me about halfway through the session.

Claude Code channels is fundamentally event-driven. Something happens. It reacts. You send a Telegram message asking about yesterday’s job and Claude Code picks it up inside the project context you opened. A CI/CD (Continuous Integration/Continuous Delivery) pipeline fires a webhook. Your channel responds. It’s reactive by design.

OpenClaw is self-driven. You point it at a task and it keeps running. The heartbeat feature lets it check your inbox every hour on its own. My chief of staff agent in OpenClaw monitors my Notion to-do list every 2 a.m., picks up new tasks, executes them against Google Docs or Google Slides, and updates me on the whole project state when I wake up. I’m not prompting it. It’s working through the night.

Dheeraj summed it up on stream: channels react, OpenClaw decides.

That’s the split. And once I saw it that way, the “did Anthropic kill OpenClaw” question stopped making sense. They’re not quite competing for the same job. Channels wins if your workflow is “something happens, respond to it.” OpenClaw wins if your workflow is “watch this and let me know.”

One quick caveat I should mention: Claude Code does have scheduled tasks as a separate feature, so you can get some cron-like behavior inside the Anthropic world. It overlaps with some of what OpenClaw’s heartbeat does, though it’s not the same as an agent that runs continuously with memory and project context. Anthropic is piecing together those capabilities across multiple features. OpenClaw gives it to you in one place.

The Honest Scoring

We scored both across eight categories during the stream. But the scores are less interesting than what we learned deciding them:

1. Setup time: Claude Code channels 4 / OpenClaw 2. Channels assumes you already have Claude Code running, so it’s basically installing a plugin. OpenClaw is a deeper configuration exercise, especially if you’re going cloud-hosted.

2. Where it runs: Claude Code channels 4 / OpenClaw 3. Channels keeps it local on your machine, which is both a strength and a limitation. OpenClaw is usually better on a dedicated server, which is more work but safer for always-on use.

3. Trigger types: Claude Code channels 3 / OpenClaw 4. OpenClaw wins because heartbeat lets it be both proactive and reactive. Channels is mostly reactive. Schedule tasks close some of the gap but not all of it.

4. Project context and memory: Claude Code channels 4 / OpenClaw 5. Both know your project. OpenClaw has built-in RAG and memory, so it references past conversations naturally. In Claude Code you can achieve similar things, but it takes manual work.

5. Platform reach: Claude Code channels 3 / OpenClaw 5. OpenClaw is wild west. It connects to Todoist, Notion, Obsidian with natural prompts like “hey, can you connect my Todoist” and it figures out where to ask for the API key. Channels supports Telegram, Discord, iMessage, and custom MCP webhooks, but connecting to new platforms still takes real configuration work.

6. Security: Claude Code channels 4 / OpenClaw 2. This is where staying inside Anthropic’s world really pays off. Read-only defaults, allow lists, plugin reviews, SOC 2 Type 2 certification. OpenClaw pushes the security burden onto you. If you ship a plain vanilla deployment, you’re in trouble. And OpenClaw’s community skills hub has had malicious skill incidents in the past, which is a real problem without a formal review process.

7. Cost: This one got complicated fast. If you already have a Claude subscription, channels is basically free. OpenClaw, after Anthropic banned the harness on subscriptions, now pushes you toward API costs or a secondary model like Kimi or Codex. API cost burns through money in seconds compared to the Max plan. I’ve seen horror stories of $800 bills from unmonitored OpenClaw instances. That’s the kind of cost that falls on you as the operator.

8. Always-on: Claude Code channels 3 / OpenClaw 5. OpenClaw wins by design because it’s built to run continuously. Channels needs your system on, which you can mostly solve with tmux to detach the session, but it’s still not the same as a dedicated cloud instance.

We ended at roughly 31 to 30. On the raw math, it’s a tie. But the raw math is misleading.

Share

Two Things That Stood Out

1. OpenClaw’s Magic Was Always Anthropic Under the Hood

Here’s the thing I keep thinking about since the stream.

What made OpenClaw feel wild was Opus 4.6. The long-running autonomous tasks, the heartbeat monitoring, the whole “AI employee” vibe. All of that ran on Anthropic’s models. And Anthropic just banned the harness from working on subscriptions.

If you want to keep running OpenClaw now, you’re looking at paying for the Anthropic API directly, which gets expensive fast. Or moving to Codex, which as I said on stream, feels obedient rather than wild. Or falling back to a local model like Kimi, which is great for some tasks but not the same thing.

So the cost math for OpenClaw changed overnight. And it’s made me more cautious about building long-running agents on top of it. I don’t trust my budget to agents I haven’t monitored carefully, and I’ve seen too many horror stories in the community.

2. Anthropic Is Walking Toward OpenClaw’s Feature Set

If you zoom out from this single comparison and look at what Anthropic has shipped in the last three months, there’s a clear trend. Remote control. Dispatch. Channels. Scheduled tasks. They keep adding features that solve the same jobs OpenClaw was built for, one release at a time.

I think the direction is obvious. Anthropic wants people running agentic workflows inside their own tools, not through a third-party harness that costs them money every time someone spins up a long-running OpenClaw agent on a subscription plan.

And that’s probably why they banned the OpenClaw harness from subscriptions last week. Running OpenClaw at scale through a flat-rate subscription is expensive for any AI lab. Every long-running heartbeat, every overnight agent monitoring your inbox, every 24/7 AI employee running on Opus 4.6 burns compute that a $100/month plan was never priced to support. I think more bans are coming. Not because Anthropic hates OpenClaw, but because the economics don’t work if a big chunk of your user base routes through an open source harness you don’t control.

Here’s what makes this really interesting. OpenAI just acquired OpenClaw. Right now, Codex doesn’t feel as agentic as Opus. Codex is more obedient. It can do detailed tasks well, but it doesn’t have that wild, autonomous feel that made people fall in love with OpenClaw in the first place. But if people start feeling pushed out of the Anthropic world because of the harness ban, that’s a massive opening for OpenAI. If they can make Codex work naturally with OpenClaw, if they can match the feel that Opus gave it, they have a real shot at pulling the entire OpenClaw community over. I wouldn’t underestimate how much frustration with Anthropic’s bans could accelerate that shift.

So the bigger picture for me is this: the “did Anthropic kill OpenClaw” question is actually a proxy for a much larger battle. Both companies want to own the agentic layer. Anthropic is building it natively through features like channels and scheduled tasks. OpenAI is betting they can own it through an open source community they just bought. Both could work. But for us as users, it means this landscape is going to keep moving fast, and whatever setup you pick today will probably look different in six months.

So What Should You Actually Use

This is where we landed at the end of the session:

1. If you already live inside Anthropic’s tools and you’re non-technical: Stick with Claude Code channels. You don’t need to spin up a server. You don’t need to monitor API costs. You don’t need to manage security layers. Channels plus scheduled tasks covers most of what a knowledge worker actually needs, and setup is under 30 minutes. If 90 percent of your workflow is “talk to my projects from my phone and react to events,” this is the right answer.

2. If you want full autonomy and you’re comfortable with infrastructure: OpenClaw still wins for that specific job. The heartbeat feature, the built-in memory, the 24/7 monitoring, the easier platform connections. These are real advantages if you’re building an AI that runs while you sleep. But you’re taking on setup, security, and cost monitoring as your own responsibility. Go in with both eyes open.

3. If you want something in between: Look at Perplexity Computer or Manus. They came up in our Q&A as alternatives that sit between the two philosophies. I’ve tried Computer and it’s genuinely powerful because it orchestrates multiple models and has pre-built integrations with most apps. The cost structure is different though, since you’re paying for a wrapper that calls the underlying APIs. Worth testing, but probably not your first stop.

The deeper point is that this is a moment-in-time snapshot. Anthropic has shipped five different connection methods in the last few months. They’re walking toward OpenClaw’s feature set one release at a time. I wouldn’t be surprised if the next batch of updates closes more of the gap around always-on execution and memory. So whatever you pick today, plan for the tools to keep evolving underneath you.

What I’m Taking Away From This

Before the session, I half expected to walk out convinced one of these tools was dead.

What I walked out with is a clearer picture of why both still exist. OpenClaw has its magic in the wild west kind of autonomy. You can point it at a problem, give it a heartbeat, and let it work. That’s genuinely different from anything Anthropic ships natively today. But that same autonomy is also the reason you need to be careful with it, especially after the harness ban.

Claude Code channels doesn’t try to be that. It tries to be the simpler thing that most people actually need. Talk to your projects from your phone. React to events. Keep the security tight. Don’t make setup a two-day project. For a non-technical person, or anyone who doesn’t want to become a part-time sysadmin, that tradeoff is the right one.

So the answer to “did Anthropic kill OpenClaw” is no, not yet. But the split is real, the gap is closing, and if you’re picking a stack today, pick based on which philosophy fits how you actually work rather than which tool has the louder hype cycle.

Subscribe now

Watch the Full Session

This was Episode 5 of One Shot Show, Season 1. We go live every Wednesday at 10:00 AM EST on Substack.

Here’s the season lineup:

1. Build a Content Research Agent with Claude Code (Episode 1)

2. Google Opal vs n8n vs Make: Newsletter Repurposing Tool Audit (Episode 2)

3. Substack Competitive Analysis Using Claude Cowork (Episode 3)

4. n8n vs Claude Code & Cowork: Which Is Better? (Episode 4)

5. Did Anthropic Kill OpenClaw? Claude Code Channels vs OpenClaw (this episode)

6. How to Build Your First AI Agent on Notion - Guest:

7. TBD

8. TBD

Watch the replay of Episode 5 [link to replay]

Jump to a specific section:

• (00:00) Welcome and intro

• (02:15) What is OpenClaw and why it exploded

• (04:50) The solo.md, memory, and heartbeat features that define OpenClaw

• (08:30) Anthropic’s connection methods: remote control, dispatch, channels

• (10:15) How Claude Code channels work under the hood

• (11:40) Live demo: Claude Code channels Telegram setup in under 5 minutes

• (15:50) Why your system needs to stay on (and the tmux workaround)

• (18:00) Where OpenClaw configuration gets complicated

• (22:20) Scoring setup time: 4 to 2

• (24:35) Where it runs: laptop vs server debate

• (26:20) Trigger types and why heartbeat is second to none

• (28:40) Project context and memory scoring

• (30:05) Platform reach: why OpenClaw connects to Todoist and Notion easier

• (32:45) Security posture deep dive and the community skills problem

• (38:00) Cost picture and the Anthropic harness ban

• (43:30) Always-on scoring and the tmux solution

• (45:00) Final tally and why the scores don’t tell the full story

• (46:30) Three workflows: CI/CD triage, morning briefs, inbox triage

• (48:20) Final takeaway: OpenClaw decides, channels react

• (50:40) Robert’s question: terminal feels like the dark ages

• (52:35) Perplexity Comet, Manus, and other alternatives

• (57:20) Closing thoughts

Resources Mentioned

• Claude Code channels: Anthropic’s feature for connecting Claude Code sessions to chat platforms through plugins. Included with Claude subscription.

• OpenClaw: Open source project for running autonomous Claude agents on your own infrastructure. Free to run, but requires API or subscription for the underlying model.

• Claude Code: Anthropic’s official CLI. Works with subscriptions starting at $20/month (Pro) or $100/month (Max).

• Opus 4.6: The Anthropic model that powered most of OpenClaw’s early traction.

• Codex: OpenAI’s coding agent, mentioned as a possible replacement model for OpenClaw now that Anthropic banned the harness.

• Kimi: Open source model some people are using as an alternative for OpenClaw.

• BotFather: The Telegram tool for creating bots, used in the Claude Code channels setup.

• BUN: Runtime utility required for Claude Code channels plugin setup.

• tmux: Terminal utility for detaching sessions, used to keep Claude Code channels running without an open terminal window.

• Hetzner Cloud: Where you can spin up a cheap always-on server for OpenClaw, starting around $4 to $5 per month.

• Perplexity Computer: Alternative AI agent with multi-model orchestration and pre-built app integrations.

• Manus: Alternative AI agent mentioned during the Q&A.

So when we sat down for Episode 4 of One Shot Show this week to compare Claude Code and n8n, I expected him to defend his home turf. He did, in some areas. But then he said something I wasn’t prepared for:

“I’m using Claude Code to manage the entire server of n8n, including the backups, regular sanity checks, health checks of the server, security updates, patching. Everything is done by Claude Code for my server.”

The person most qualified to champion visual automation tools is quietly using a conversation-based AI to handle the hardest parts of running them.

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

n8n vs Claude Code, What Are These Tools?

If you’re already familiar with both, skip ahead. But if either name is new to you, here’s the short version.

n8n is a visual workflow automation tool. Think of it like a digital assembly line where you drag and drop boxes (called nodes) onto a canvas, wire them together, and each box does one thing: send an email, call an API, process data, trigger a notification. It’s in the same category as Make.com and Zapier. You build automations by connecting these blocks visually, and then they run on a schedule or when something triggers them. It’s popular because you can see the entire flow at a glance.

Claude Code is Anthropic’s AI coding agent. You open a terminal (or the desktop app), describe what you want in plain English, and Claude builds it. It reads your files, writes code, runs commands, connects to external tools through MCP (Model Context Protocol), and manages your entire project. It was originally built for software engineers, but turns out it works just as well for anyone who want to build automations, agents, and apps without learning to code themselves. I run my entire newsletter operation through it.

If you want to learn more about Claude Code, I wrote two in-depth posts to help you kickstart your project with Claude Code:

• How I Turned Claude Code Into My Personal AI Agent Operating System for Writing and Research (Beginner’s Guide)

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

So the question is: if you want to automate your work with AI, which path do you take? The visual builder or the conversational agent?

Why This Comparison Matters Right Now

If you’ve spent any time in AI automation communities on Reddit or YouTube, you’ve seen the debate. Visual workflow builders like n8n, Make.com, and Zapier on one side. Claude Code and similar AI coding agents on the other. People asking: which one should I learn?

The common answer has been pretty consistent: learn n8n (or Make) because it’s visual, it’s easier to debug, and you can hand it off to clients. Claude Code is for developers.

Dheeraj and I wanted to test that assumption. So he rebuilt the exact same AI research agent from Episode 1 in both Claude Code and n8n, and we walked through both live.

Same Agent, Two Very Different Paths

Here’s what jumped out immediately when Dheeraj showed both versions side by side.

The Claude Code version was a collection of markdown files written in plain English. The agent file described the goal, the research profiles, the process, and the tools to use. To run it, you type something like “run a research on bike tours to Ladakh in 2026” and it starts working.

The n8n version was a visual canvas full of nodes. Input nodes, context nodes, HTTP nodes for Perplexity API calls, Firecrawl for scraping, Jina AI as a fallback, merge nodes, synthesis prompts, formatting nodes. You could see the whole flow mapped out, which looked impressive.

But Dheeraj pointed out something important:

“If someone is creating an n8n workflow, you have to know about all these nodes. You have to understand the intricacies. You have to yourself define Firecrawl, the backup, the fallback. You are implementing as a human.”

In Claude Code, we just wrote in plain English:

“Use Perplexity for research. If Firecrawl is out of credits, fall back to Jina AI.”

That was it. No plumbing.

The output quality was comparable. Both produced structured research briefs with summaries, findings, sources, content gaps, and angle suggestions. N8N had slightly more cited sources in one run (15 vs 6), but Dheeraj acknowledged that was probabilistic since the queries were slightly different.

But one thing I realized was that the difference wasn’t in the output; it was in the effort to get there.

The 8-Category Scorecard (Claude Code vs N8N)

We scored both tools across eight categories, rating each from 1 to 5. Here’s how it played out:

1. Learning Curve

N8N requires learning nodes, data mapping, JSON paths, and expressions. Dheeraj’s own course is 30+ hours of training. Claude Code has its own curve (understanding the terminal, context management, file structures), but once you get past the initial intimidation of the terminal, you’re just writing in English. And if you get stuck, you can ask Claude Code itself to help you figure it out. That’s a kind of learning curve that bends back in your favor.

2. Building Speed

This one was stark. Dheeraj estimated the n8n workflow took “at least a couple of hours” to build, and he knows n8n inside and out. The Claude Code version from Episode 1? We built it live in roughly 30 minutes while also talking through concepts with the audience. When you combine Claude Code with voice dictation tools like WisprFlow, you’re literally just talking and building.

3. Scope and Ceiling

This was Dheeraj’s “favorite part” to discuss. N8N can build backends and deterministic automations. That’s its world. If you need a custom node, you need to be an engineer. If you need a code workaround, you’re leaving no-code territory. Claude Code has no ceiling. You can build agents, full-stack apps, deploy to servers, manage infrastructure. Dheeraj put it simply: “You can even build n8n workflows with Claude Code.”

4. Scheduling and Triggers

This is where n8n (and Make.com and Zapier) genuinely wins today. Built-in cron jobs, webhooks, retry logic, visual monitoring of executions. I have a Make.com automation that runs every day to curate AI news for me. It just works in the background without me touching it. Claude Code is getting there with loops, channels, and scheduling features, but it’s still catching up in this area. N8N was built for this from day one.

5. Debugging

This is where Dheeraj pushed back against the popular opinion. The common argument is that visual workflows are easier to debug because you can click a failed node and see the exact input and output. True.

But Dheeraj’s counter:

“Here you are doing all the legwork. There is no AI behind it. In Claude Code, you are working with a partner.”

You paste a screenshot or describe the error, and Claude Code runs its own investigation. It’s found tricky bugs that would take humans much longer to replicate manually.

6. Day-to-Day Use and Handoff

N8N gives you a visual overview at a glance. But modifying anything still requires n8n knowledge. Claude Code projects can be handed off with readme files, and the person receiving them just needs to know how to talk to Claude Code. Dheeraj showed a fun example: if someone uses the research agent project and asks about plumbing instead of travel, Claude Code will notice the mismatch and flag it. N8n would just run whatever you configured.

7. Cost

Claude Code Pro is $20/month, Max is $100/month. But Max covers the LLM costs for everything you build. N8n cloud starts at $24/month with 2,500 executions (which runs out faster than you’d think).

Self-hosting is “free” but comes with server management overhead. And on top of n8n’s cost, you’re still paying separately for LLM API calls, which can be 20x more expensive than a subscription.

The key differentiator: Claude Code’s subscription covers vibe coding, app building, agent creation, and automation all in one price.

8. Scalability

Both have caveats. N8N at scale requires understanding server architecture, caching, and parallel instances. Claude Code at scale requires understanding deployment basics (Railway, Vercel, Supabase). But for personal workflows, Claude Code runs on Anthropic’s infrastructure, so you don’t worry about your pipeline’s performance. N8N self-hosted means you’re responsible for everything.

Two Details That Stood Out

Here are two key takeaways I realized from our conversation that you can use as a reference to decide which option you should choose, even though you already know the clear winner at this point:

Claude Code Built the n8n Workflow

The n8n workflow Dheeraj showed during the live session was built with Claude Code. He set up an MCP server connection and talked to Claude Code in plain English, and it generated about 90% of the workflow. He had to jump in and tweak a few things manually (Claude Code tends to output code nodes instead of native n8n nodes, so you have to ask it to use native nodes instead). But even with that back and forth, it was still faster than building the workflow by hand.

Think about what that means. The tool being compared is also capable of building its competitor’s workflows. That’s a different category of capability.

Transferable Skills vs Platform Lock-in

Something I brought up during the show that I keep thinking about: the skills you build using Claude Code transfer to other AI agents. If you learn how to structure context, write clear instructions, and manage files for Claude Code, you can apply that same approach to Codex, Gemini CLI, OpenCode, or whatever comes next. You’re learning how to work with AI agents, period.

N8N skills work in n8n. Make.com skills work in Make.com. Zapier skills work in Zapier. If any of those platforms change direction or a better option appears, you’re starting over.

I’m not saying this to dismiss those platforms. I still use Make.com for scheduled automations. But if I had to pick one skill to invest in right now for long-term returns, it would be learning how to communicate clearly with AI agents. That’s the skill that compounds.

What I’d Recommend Based on Where You Are

If you’re brand new to all of this, start with Claude Projects or Claude Cowork. Get comfortable giving AI context about who you are and what you need. Learn how project knowledge works. That foundation transfers directly to Claude Code when you’re ready.

If you already know n8n or Make.com and have workflows running, don’t abandon them. But consider setting up Claude Code to help you manage and optimize what you’ve already built. That’s literally what Dheeraj does.

If you’re deciding what to learn next, I’d go straight to Claude Code. Yes, the terminal looks intimidating for about five minutes. There’s also a desktop app now that’s nearly at feature parity. The learning curve is real, but it bends back in your favor because you can ask Claude Code itself to help you learn. Try that with a visual workflow builder.

And if you’re an agency or freelancer building automations for clients, this is worth paying attention to. The “visual workflows are easier to hand off” argument holds up only when the client has learned n8n. A well-structured Claude Code project with clear readme files and plain English instructions might actually be easier for a non-technical client to interact with.

One Shot Show Details

Episode 4, Season 1 | Live every Wednesday at 10:00 AM EST on Substack

Previous episodes:

• Episode 1: Building a Content Research Agent with Claude Code

• Episode 2: Newsletter Repurposing Engine with Google Opal

• Episode 3: Claude Coworks + Substack Competitive Analysis

• Episode 4: Claude Code vs N8N

• Episode 5: Claude Channels vs OpenClaw (next week)

Timestamps:

• 00:00 - Welcome and recap of previous episodes

• 00:40 - Today’s topic: Claude Code vs n8n

• 06:06 - Claude Code research agent walkthrough

• 09:28 - Same agent in n8n: visual node comparison

• 17:07 - Side-by-side output comparison

• 24:27 - The 8-category scorecard begins

• 25:33 - Learning Curve comparison

• 31:35 - Building Speed comparison

• 34:02 - Scope and Ceiling comparison

• 37:17 - Scheduling and Triggers comparison

• 41:44 - Debugging comparison

• 46:17 - Day-to-Day Use and Handoff comparison

• 49:00 - Cost comparison

• 54:31 - Scalability comparison

• 58:56 - Final score reveal: 23 vs 32

• 59:07 - The verdict and recommendations

• 1:04:25 - Viewer Q&A

• 1:06:30 - Next episode preview

Resources Mentioned

• Claude Code (Anthropic) - AI coding agent, $20/mo Pro, $100/mo Max

• n8n - Visual workflow automation, free self-hosted or $24/mo cloud

• Make.com - Visual automation platform, similar category to n8n

• Zapier - Automation platform, similar category to n8n and Make

• Perplexity - AI search API, used in both implementations (Sonar Pro model)

• Firecrawl - Web scraping tool, used for competitor content analysis

• Jina AI - Free web scraping alternative, used as Firecrawl fallback

• WisprFlow - Voice dictation tool for hands-free Claude Code interaction

• Claude Desktop App - Desktop version of Claude, alternative to terminal

• Claude Cowork - Collaborative Claude environment with agent capabilities

• Claude Channels - New Claude Code feature for persistent agent communication

• Claude Dispatch - Scheduling feature for Claude Code

• OpenClaw/OpenCode - Open-source AI coding agent

• Manus - AI agent platform

• Perplexity Computer - Perplexity’s computer-use agent

• Gemini CLI - Google’s command-line AI agent

• Codex (OpenAI) - OpenAI’s coding agent

• MCP (Model Context Protocol) - Protocol for connecting AI agents to external tools

• Oracle Cloud - Free tier server for self-hosting n8n

• Cloudflare - Used for server management and security

• Railway, Vercel, Supabase - Deployment platforms mentioned for Claude Code apps

GenAI Unplugged

Simple AI automation systems for solopreneurs who are done doing everything by hand.

By Dheeraj Sharma

The idea was simple.

Can an AI agent visit your Substack, read your top posts, figure out who your audience is, identify your writing patterns, spot the gaps in your content, and then hand you a growth strategy? All without you doing anything except writing one prompt?

It can. The agent generated a 17-page Word document with audience profiles, content theme breakdowns, writing style DNA, opportunity mapping, SEO analysis, and 10 specific content ideas. And the whole thing ran autonomously while Dheeraj and I sat there talking about what was happening on screen.

But before we get there, a quick primer. Because if you’ve been hearing “Claude” everywhere and wondering which Claude product actually does what, you’re not alone. We spent the first chunk of the episode breaking this down.

Claude Chat vs. Cowork vs. Code: A Quick Primer

For the last three years, most of us have interacted with AI through a chatbot. You ask a question, you get an answer, you copy-paste the output into whatever you’re working on. That’s Claude on the website. It works, but you’re always the middleman. You’re the one moving information between the AI and your actual work.

Claude Projects tried to improve this by letting you store knowledge, brand voice, and style guides in one place. But Projects have real limitations. Every chat has a context window cap (around 200K tokens), and the more files you add, the slower the responses get. You’re still stuck in a back-and-forth where you copy output into your docs, your tools, your spreadsheets.

Then Claude Code came along mid-2025. This was the jump from chatbot to agent. Instead of just answering questions, Claude Code can plan multi-step tasks, read and edit files on your computer, execute work end-to-end, and access your entire system. The catch? It runs in a terminal. And for most people, the terminal is where enthusiasm goes to die.

I’ll be honest. I don’t consider myself a tech person. But I decided to jump into Claude Code anyway, and it changed how I run my entire newsletter. I’d say it was worth all the effort and gave me 10x more capability in what I can do with AI.

But Anthropic clearly saw the gap. In January 2026, they released Claude Cowork. Here’s the simplest way to think about it: Cowork is Claude Code’s agentic engine wrapped in a visual interface. Same planning capabilities, same file access, same ability to deploy parallel sub-agents. But instead of a terminal, you get folders on the left, a chat in the middle, and outputs on the right. No code visible anywhere.

The five core things Cowork can do:

1. CLAUDE.md instructions. You connect a folder from your computer, and inside that folder you put a CLAUDE.md file with your project context, your voice guidelines, your audience profile. This becomes the brain of every task you run.

2. Planning with visible to-do lists. When you give Cowork a complex request, it steps back, creates a plan, and shows you a checklist it works through. You can watch each step get checked off in real time.

3. Claude in Chrome. This is built into Cowork by default. The agent can take over your browser, navigate pages, take screenshots, click through links, and extract information visually. It’s the same as using Claude in Chrome as a standalone extension, but integrated directly.

4. Parallel sub-agents. When tasks are complex, Opus 4.6 will spin up multiple sub-agents that work simultaneously. This makes multi-step workflows significantly faster.

5. File outputs. The agent can read and generate Excel, PowerPoint, Word, and HTML files directly. No more copy-pasting from chat into a document.

There are a few honest trade-offs to know about. Cowork only accesses folders you manually select, and it’s limited to your home directory. Claude Code has full access to any folder on your system. Cowork is also noticeably slower than Code in my experience. And one thing we noticed during the stream: Cowork doesn’t seem to offer the 1 million token context window that Claude Code has in the terminal. We couldn’t confirm whether it’s running behind the scenes or genuinely limited.

But for someone who wants agent-level capabilities without touching a terminal? Cowork closes that gap completely. And that’s what we used for the live demo.

I’ve covered an in-depth guide on how to use Claude Cowork in case you want to explore more.

Why Your Own Newsletter Is the Hardest Thing to Analyze

Most newsletter creators I know, myself included, have a blind spot when it comes to their own content. You know what you write about. You know your audience in a general sense. But you’re too close to the work to see the patterns clearly.

When someone asks “what’s your newsletter’s voice?” or “what makes your content different?”, most of us give a vague answer. Something about AI, practical advice, building systems. That’s the high-level story. It’s the one we tell ourselves.

But the real answer lives in the data. It’s in which posts performed best, what language patterns show up across your top content, what problems you keep solving for readers, and where the gaps are between what you cover and what your audience is looking for.

The problem is that doing this analysis manually takes hours. You’d need to read through your own archive, pull out themes, cross-reference engagement data, and somehow step outside your own perspective to see it objectively.

That’s exactly what we asked Claude Cowork to do.

Subscribe now

How the Newsletter DNA Extraction Actually Works

The workflow chains three capabilities together: vision-based browsing, web scraping, and deep content analysis. Here’s the sequence we ran live:

• Step 1: Homepage reconnaissance. Claude in Chrome navigated to Dheeraj’s Substack homepage and took screenshots. From just the homepage, the agent pulled an initial read on the newsletter’s positioning, recent topics, and overall content direction. This is vision-based. The agent is literally looking at the page the way a human would.

• Step 2: Archive deep dive. We pointed the agent to the top-performing posts archive (the /archive?sort=top URL on Substack). Claude in Chrome browsed this page, identified the highest-performing posts, and extracted the links.

• Step 3: Content scraping. The agent triggered Firecrawl MCP to scrape the full text of each post. Now, something happened here that’s worth calling out. My Firecrawl credits had run out. Instead of failing, the agent fell back to Claude’s built-in web fetch feature and kept going. The analysis continued without us intervening. This is one of those moments that shows the difference between a chatbot and an agent. A chatbot would have stopped and told you the tool failed. The agent adapted and found another way to get the data.

• Step 4: Pattern analysis. With 5-10 full posts scraped, the agent ran its analysis: audience profiling, content theme identification, writing style extraction, structural patterns in top posts, and content gap mapping.

• Step 5: Report generation. Everything got compiled into a Word document. 17 pages. Formatted with sections, headers, and actionable recommendations.

What the 17-Page Report Actually Contains

Let me walk through the sections because the depth surprised even me:

1. Audience Profile. The report started with “Who reads GenAI Unplugged?” and broke it down into three layers: what frustrates the audience, what they already know, and what they actually want. This wasn’t generic personas. It was derived from the language and topics in Dheeraj’s top posts.

2. Content Themes. The agent categorized Dheeraj’s content into four buckets: code and AI agent builds, tool deep dives, AI automations, and icon automations. What’s useful here is seeing the distribution. You might think you cover topics evenly, but the data often shows you lean heavily into one area.

3. Writing Style DNA. This section pulled out voice characteristics, signature phrases, and recurring concepts. If you’ve never had your writing style analyzed externally, this is genuinely eye-opening. The patterns the agent found were things Dheeraj recognized as true but had never articulated.

4. Content Gaps and Opportunities. This is where it gets strategic. Based on what the top posts covered and what they didn’t, the agent identified specific content territories that Dheeraj could explore. These weren’t random suggestions. They were grounded in what was already working and what was missing.

5. 10 Specific Content Ideas. Derived from the gap analysis. Each idea connected to an existing strength in Dheeraj’s content library.

6. Growth Strategy. The final sections covered newsletter-level SEO analysis, niche clarity, keyword territory mapping, audience segmentation, competitive positioning, and a monetization structure breakdown. It even identified products Dheeraj had mentioned across posts, like SubFlow CLI.

7. Top 5 Immediate Actions. Concrete next steps, not vague advice.

You can check the result here.

🚨 Pro tip: The initial sections of this report, the audience profile, the voice characteristics, the writing style DNA, can feed directly back into your CLAUDE.md file or your brand profile. So the analysis can be transferred as the foundation for every future AI-assisted task you run.

If you want to learn more about what CLAUDE.md can do for you, check out my latest piece: Claude Code Ultimate Guide.

Who Should Use This (and the Prompt to Get Started)

If you run a Substack newsletter and want to extract your own DNA, this workflow works on both Claude Cowork and Claude Code.

For Cowork users: You need Claude in Chrome enabled (install the extension and log in), and Firecrawl MCP connected through the connectors menu. Set the model to Opus 4.6 with extended thinking toggled on. If you’re on the Pro Plan, Sonnet 4.6 with thinking mode also works, but Opus tends to deploy parallel sub-agents more aggressively, which speeds up the process.

For Claude Code users: Same requirements, just running from the terminal instead of the GUI. The advantage is faster execution and access to any folder on your system. The disadvantage is that the terminal can feel intimidating if you’re not used to it.

A few things to keep in mind:

1. This is a token-heavy workflow. Opus 4.6 will burn through tokens because it’s scraping full posts and running deep analysis. Be aware of that before you start.

2. Posts behind a paywall will get skipped. Tell the agent explicitly to move past paywalled content and grab the next available free post instead. Otherwise the report gets messy with partial content.

3. Put your newsletter details in the prompt: your URL, your top archive URL, your current subscriber count, your main topics, and your growth goal. The more context you give, the better the analysis.

Here’s the prompt you can copy and paste:

## Context

I run a Substack newsletter at [YOUR NEWSLETTER URL] and want a comprehensive content analysis to help me grow.

## Task

Analyze my newsletter deeply and provide actionable growth recommendations.

---

## ⚠️ Prerequisites — Read Before Starting

This workflow requires two tools to be active before you begin:

1. **Claude in Chrome** — needed for navigating pages and extracting live URLs

2. **Firecrawl MCP** — needed for scraping the full content of each post

Do not begin until both are confirmed active. If either is missing, stop and ask the user to enable them.

---

## Requirements

### Phase 0: Homepage Overview (START HERE)

1. **Navigate to the homepage**: [YOUR NEWSLETTER URL] using Claude in Chrome

2. **Take a screenshot** of the homepage

3. **Analyze the overview**:

- What content categories/sections are featured?

- What are the recent post titles and themes?

- What’s the visual branding and aesthetic?

- What navigation options are available (tabs, links)?

- What’s the overall positioning and tagline?

4. **Get broader context** from recent posts visible on homepage (titles + descriptions):

- Identify content patterns across recent posts

- Note which themes appear most frequently

- Understand the current focus and direction

---

### Phase 1: Deep Content Analysis

#### Step 1: Navigate to the archive page

Using Claude in Chrome, go to: [YOUR NEWSLETTER URL]/archive?sort=top

Take a screenshot of the archive page.

#### Step 2: Extract real URLs — do not guess

On the archive page, identify the top 7–10 posts by engagement. For each post:

- **Click into the post card** or hover to reveal the full URL

- **Copy the exact URL** as it appears in the browser address bar

- Record this URL before moving to the next post

> ⚠️ **Critical rule**: Never construct, guess, or infer a post URL. Only use URLs that were directly observed in the browser. Guessed URLs will lead to wrong pages or 404 errors.

#### Step 3: Scrape each post using Firecrawl MCP

For each URL collected in Step 2:

1. Pass the exact URL to Firecrawl MCP

2. Extract the full post content

3. If the post is behind a paywall and returns only a preview, skip it and move to the next URL

4. Continue until you have **5 fully readable posts minimum**

For each readable post, extract:

- Core problem being solved

- Target audience signals (who is this for?)

- Writing style patterns (voice, structure, tone)

- Frameworks or methodologies used

- Engagement tactics (calls to action, examples, screenshots)

---

### Phase 2: Pattern Recognition

Analyze across all posts to identify:

- **Audience Profile**: Who reads this? What’s their core frustration? What do they already know?

- **Problems Solved**: What 3–5 pain points does this newsletter address?

- **Content Themes**: What are the main content categories? How do they differ?

- **Writing Style DNA**: What makes this voice unique? What’s the consistent structure?

- **Unique Value Prop**: What does this newsletter do differently than competitors?

---

### Phase 3: Opportunity Mapping

#### Content Ideas — Quality Filter

Generate 10 specific content ideas. Each idea must pass both of these tests before inclusion:

1. **Pattern test**: It maps back to a specific pattern or structure observed in the top posts (cite which post it draws from)

2. **Audience test**: It directly addresses a frustration explicitly visible in the audience profile built in Phase 2

Generic ideas that could apply to any newsletter should be discarded.

**Required format for each idea:**

> **Title**: [Working title]

> **Why it works**: Tied to evidence from top posts or audience profile (be specific)

> **Suggested format**: e.g. breakdown, case study, tutorial, comparison

> **Hook sentence**: One sentence that could open the post

#### Additionally identify:

- **Format Gaps**: What content formats (templates, tools, video walkthroughs) are underutilized given what already resonates?

- **Content Gaps**: What angles or topics are missing that the audience would clearly value based on the problems you’ve identified?

---

### Phase 4: Growth Strategy

#### 1. Newsletter-Level SEO Analysis

Do not analyze individual posts for SEO. Instead, evaluate SEO at the newsletter level by answering:

- **Niche clarity**: Is the newsletter’s positioning specific enough to own searchable territory? What would someone Google to find this?

- **Keyword territory**: What topic cluster does the content naturally occupy? Name 3–5 terms this newsletter could realistically rank for

- **Owned asset opportunity**: What single tool, glossary, or resource page — if created — could drive recurring search traffic back to the newsletter?

#### 2. Content Repurposing

How should existing top posts be amplified across platforms? Be specific about which post types translate best to which channels (LinkedIn, Twitter/X, YouTube Shorts, etc.)

#### 3. Audience Segmentation

Should content be tiered by skill level? If yes, recommend how to segment and what content belongs in each tier.

#### 4. Next Steps

List the top 5 immediate actions in priority order, with a one-sentence rationale for each.

---

## Deliverables

### Comprehensive Analysis (Word Document)

Output a single well-formatted Word document (.docx) covering all sections below. Use headings, subheadings, and spacing to make it easy to navigate. Do not truncate or summarize — the goal is a complete, long-form reference document.

Sections to include:

- Executive Summary

- Audience Profile

- Problems Solved (with examples from posts)

- Content Themes & Patterns

- Writing Style Analysis

- Content Gaps & Opportunities

- 10 Specific Content Ideas (using the quality filter above)

- Growth Strategy Recommendations

- Competitive Positioning

- Next Steps

---

## My Newsletter Details

**URL:** [YOUR URL]

**Top Posts Archive:** [YOUR URL]/archive?sort=top

**Current Stats:** [Subscribers, ARR, posting frequency]

**Main Topics:** [Brief description of what you write about]

**Goal:** [What you want to achieve — more subscribers, revenue, clarity, etc.]

---

## Process Notes

**Do not skip steps or reorder phases.** The sequence matters:

1. Homepage → establishes positioning and branding context

2. Archive page → identifies what resonates with the audience

3. Extract real URLs from the page before scraping — never guess

4. Firecrawl MCP scrapes full content from each confirmed URL

5. This context-first flow prevents generic analysis

**URL rule**: Every post URL must be directly observed in the browser via Claude in Chrome. Do not construct URLs from post titles or patterns.

**Gated content**: If Firecrawl returns only a preview, skip that post. Move to the next confirmed URL. Need 5 fully readable posts minimum.

**Content ideas must be grounded**: Every idea must trace back to observed evidence. If you can’t cite where the pattern came from, the idea doesn’t qualify.

---

## Success Criteria

- [ ] Claude in Chrome was active before starting

- [ ] Firecrawl MCP was active before starting

- [ ] Homepage screenshot and overview completed first

- [ ] All post URLs were extracted directly from the browser — none were guessed

- [ ] Firecrawl MCP was used to scrape each post

- [ ] Analysis based on reading full post content (minimum 5 posts)

- [ ] Gated posts were skipped, not summarized from previews

- [ ] Each content idea passes both the pattern test and audience test

- [ ] SEO analysis is newsletter-level, not per-post

- [ ] Full analysis delivered as a Word document (.docx)

- [ ] Recommendations are actionable with clear next steps

- [ ] Insights are non-obvious and tied to specific evidence from posts

One More Thing About Cowork vs. Claude Code

Dheeraj asked me on the stream whether Claude Code power users should migrate to Cowork. My honest answer: probably not.

If you already have your folders, your CLAUDE.md instructions, and your workflows set up in Claude Code, Cowork is slower and more restricted. It only accesses folders you manually select, and it’s limited to your home directory. Claude Code has full system access and runs faster.

But Cowork has one genuine unlock. It’s for people who want agentic capabilities without touching a terminal. If the command line feels daunting, Cowork gives you the same Claude Code engine wrapped in a visual interface. Folders on the left, chat in the middle, outputs on the right. No code visible anywhere.

I use both. Claude Code for my daily newsletter work because everything is already set up there. Cowork for quick one-off tasks and for the Dispatch feature, which lets me trigger tasks from my phone as long as my computer is awake.

Next week on Episode 4, we’re putting Claude Code and n8n side by side. Same automation, built both ways, so you can see which platform makes sense for what. If you’ve been wondering whether to learn n8n or go all-in on Claude Code for your AI automations, that’s the one to catch. Every Wednesday, 10 AM EST.

See you in the next one.

Share

One Shot Show Details

Episode: One Shot Show, Episode 3 (Season 1)
Live Schedule: Every Wednesday at 10:00 AM EST on Substack

Season 1 Episodes:

• Episode 1: Building an AI Research Agent with Claude Code

• Episode 2: Google Opal vs n8n vs Make for Newsletter Repurposing

• Episode 3: Newsletter DNA Extraction with Claude Cowork

• Episode 4: Claude Code vs n8n for AI Automations

• Episode 5: Claude Code Channels vs OpenClaw

Timestamps:

• 00:00 - Welcome and Episode 3 intro

• 01:35 - Wyndo introduces the competitive analysis use case

• 04:01 - Evolution from chatbot to AI agent (Claude Code to Cowork)

• 09:05 - Five core capabilities of Claude Cowork

• 13:25 - Progressive disclosure in CLAUDE.md (Dheeraj’s tip)

• 14:48 - Walking through the CLAUDE.md custom instructions

• 17:00 - Chatbot vs. agent comparison

• 20:29 - Starting the live newsletter DNA extraction demo

• 24:07 - Cowork features: folders, connectors, and plugins

• 26:05 - Dispatch and schedule features

• 28:01 - Running the prompt and watching the agent plan

• 34:06 - Agent creates planning to-do list, Claude in Chrome takes over browser

• 35:25 - “What do you do while agents work?” discussion

• 37:48 - Firecrawl runs out of credits, agent falls back to web fetch

• 41:04 - Cowork UI appears to freeze (but agent keeps running)

• 43:42 - Pre-run output walkthrough: 16-page report structure

• 46:32 - Live run output arrives: 17-page report

• 47:40 - Closing discussion: Who should use Cowork vs. Claude Code

• 53:55 - Viewer Q&A: Memory between Cowork sessions

• 55:25 - Episode 4 preview: Claude Code vs n8n

Resources Mentioned

• Claude Cowork (Anthropic) - GUI interface for Claude Code’s agentic capabilities, built into Claude Desktop. Included with Claude Pro plan.

• Claude Code (Anthropic) - Terminal-based AI agent with full system access, planning, and parallel sub-agents. Requires Max plan for Opus 4.6.

• Claude in Chrome (Anthropic) - Browser extension that gives Claude vision-based web browsing. Takes screenshots, clicks, and navigates autonomously.

• Firecrawl MCP - Web scraping connector for Claude. 500 one-time credits on the free tier (previously 500/month). MCP docs.

• Jina.ai - Free alternative to Firecrawl for web scraping. Mentioned by Dheeraj as a backup option.

• Gemini CLI - Google’s CLI tool. Dheeraj uses Flash 2.5 for search and fetch capabilities.

• Tavily - Research and web search connector available in Cowork’s connector marketplace. This is my favorite tool at the moment.

• Perplexity - Deep research connector.

• Dispatch (Anthropic) - Mobile access feature for Claude Cowork. Trigger tasks from your phone as long as your computer is awake.

• Claude Code Channels (Anthropic) - Connect Claude Code to Telegram, Discord, and custom hooks for always-on access via Tmux.

• Opus 4.6 - Recommended model for this workflow. Deploys parallel sub-agents and handles complex multi-step tasks.

• Sonnet 4.6 - Alternative model. Works with extended thinking toggled on, uses fewer tokens.

I took Google Opal, Dheeraj brought his n8n setup, and we talked through where make.com fits in the middle.

I walked away understanding what each tool actually gives you and what it quietly takes away.

Before we get into the details, Dheeraj writes about building AI automation systems for Solopreneurs. You might want to subscribe to his newsletter to learn more.

GenAI Unplugged

Simple AI automation systems for solopreneurs who are done doing everything by hand.

By Dheeraj Sharma

Why AI Automation Instead of Just Using a Chatbot

Before I get into the tools, here’s the context for anyone still pasting their newsletter into ChatGPT or Claude and asking for a LinkedIn post.

I used to do this. And it kind of works. But there’s a lot of back and forth. You have to re-explain your context every time. You have to copy and paste everything manually. And the output is usually not platform-specific enough to actually publish without heavy editing.

AI automation tools like Opal, n8n, and make.com solve this differently. You set up the workflow once: define the trigger (an RSS feed, a webhook, a schedule), define what AI does at each step, and define where the output goes. Then you run it whenever you want without rebuilding the whole thing from scratch.

That’s the jump from chatbot to automation. You build the system once, and it runs whenever you need it.

Building the Workflow Live on Google Opal

So I opened up Opal and built the workflow during the stream. Here’s how it works.

You describe what you want in plain English. I typed something like “help me build a newsletter repurpose engine where you take my newsletter posts and generate into LinkedIn, Substack, as well as Twitter threads.” That’s it. The agent parsed the prompt, figured out which AI models to use, and generated the full workflow.

You don’t need to understand nodes, JSON, or webhooks to get started. You describe your goal and Opal builds the automation for you.

Every Opal workflow has three pieces:

1. A user input (where you paste or upload your content),

2. A generation step (where the AI model processes it),

3. And an output (Google Docs, Slides, HTML, or Sheets).

The new Agent feature is the big upgrade here. Previously, you had to manually pick which AI model and tools to use. Now the agent figures out the right combination on its own.

And since Opal is built by Google, all the AI models are Google’s. Gemini for text, Nano Banana Pro for images, Veo 3 for video, Lyria for music. You can chain them together. So if you wanted to generate a thumbnail from your newsletter, you could have Gemini read the post, write an image prompt, and pass it to Nano Banana Pro to generate the thumbnail. All in one workflow.

The whole thing took minutes to set up.

The Output Quality Problem Nobody Talks About

Here’s the part that matters.

The workflow ran. The output came back. And it was fine. Generic. The LinkedIn post read like AI-generated content. The Substack Notes weren’t platform-specific. The Twitter thread was flat.

This is the part nobody shows you in tool demos. The first-pass results from Opal looked like what you’d get from any chatbot. Because at that point, the workflow was just a thin wrapper around a single AI generation step with a basic prompt.

Dheeraj put it well during the stream: this is great for rapid prototyping. But for publishable content, the first pass was still far from what I’d actually use.

How I Refined It Into Something I’d Actually Use

So I showed the audience what my real, production workflow looks like in Opal. And it’s different from the prototype.

Instead of one generation step doing everything, I split the newsletter input into three separate nodes. One for LinkedIn with its own detailed prompt, one for Substack Notes, and one for Twitter threads. Each prompt is written specifically for how that platform works, what kind of hooks land on LinkedIn, how a Substack Note should feel, how to make a thread scannable.

Then I added another layer: a hook generator. This takes the LinkedIn post output and applies 11 different hook frameworks I use. Most powerful, big number versus small number, call out, secret, struggle, how to, believe, flip. The hook generator creates refined versions of the opening so I have options to choose from.

You can also add an editor workflow on top of that. I have one that strips out AI-generated writing patterns. Things like the “it’s not X, it’s Y” rhetoric that AI loves to use. You can tell the editor to remove specific patterns before the final output hits Google Docs.

So the production workflow is: newsletter input → three platform-specific AI nodes with custom prompts → hook generator layer → editor layer → Google Docs output.

It takes more work to set up than the initial prototype. But it all lives inside Opal’s visual builder, and once you’ve built it, you just paste in your next newsletter and let it run.

If you want to build this exact Opal workflow yourself, I wrote a full step-by-step guide for AI Maker Lab member:

It covers the complete setup including the custom prompts, hook frameworks, and editor layer.

When Dheeraj Pulled Up His n8n Screen

Then Dheeraj shared his screen. And the gap was visible the moment we saw it.

His n8n content multiplication system was complex. Webhook triggers, content normalization, platform-specific prompt queues, quality gates that check whether the output passes brand voice standards, revision loops, and direct API publishing to LinkedIn, Twitter, Substack, and more.

Everything I had to do manually (copy from Google Docs, paste into LinkedIn), his workflow does automatically. Opal gets you building fast but stops at Google Docs. n8n requires real learning, but once built, it handles the entire pipeline from newsletter to published social post without you touching it.

And Dheeraj said something that stuck with me. Even though he published an entire n8n course, he doesn’t manually build workflows anymore. He connects Claude Code to n8n through the MCP server and describes what he wants in plain English. Claude Code creates the working n8n workflow. He uses it to build, test, and verify.

So the learning curve advantage that Opal has? It’s shrinking. n8n just shipped a new feature called “n8n as code” that represents workflows as readable code, making Claude Code integration even tighter without needing the MCP server at all.

Subscribe now

The Honest Scoring Opal vs n8n vs Make.com

We scored all three tools at the end of the stream. Here’s where they landed:

Google Opal

• Cost: 5/5 (free, $20/month for Gemini Pro access)

• Speed: 5/5 (prototype in minutes)

• Learning curve: 5/5 (zero technical knowledge needed)

• Flexibility: 2/5 (limited to Google AI models, no direct API publishing)

• Output quality: 3/5 (needs prompt refinement for publishable results)

Make.com

• Cost: 3/5 ($9-24/month, pricing can get complex with steps)

• Speed: 4/5 (moderate setup time)

• Learning curve: 4/5 (need to understand some logic, JSON, module configuration)

• Flexibility: 4/5 (multi-AI support, webhooks, HTTP modules, direct publishing)

• Output quality: 5/5 (depends on prompt quality, same as others)

n8n

• Cost: 4/5 (free self-hosted, $20-24/month cloud)

• Speed: 4/5 (significant setup time, but faster with Claude Code)

• Learning curve: 2/5 (steep, JavaScript knowledge helps)

• Flexibility: 5/5 (full control, code nodes, webhooks, API publishing, any AI model)

• Output quality: 5/5 (depends on prompt quality, same as others)

Who Should Use What

This is what it comes down to.

If you’ve never automated anything and you want to start today: Google Opal. It’s free, there’s zero learning curve, and you can validate whether a workflow concept works before investing serious time. If you’re already in Google’s tools (Gmail, Docs, Drive), it fits right in. Good for one-off generation tasks, prototyping ideas, and building workflows you can share with your team through a single link.

If you’re comfortable with some logic and want more control: make.com. You get direct publishing to social platforms, multi-AI model support (OpenAI, Anthropic, Gemini), and enough flexibility for most content workflows. The visual drag-and-drop builder is more complex than Opal but still approachable. $9-24/month.

If you want full control and you’re comfortable with code: n8n. You get everything. Webhook triggers, code nodes, conditional logic, quality gates, direct API publishing, and the ability to connect to any system that has an API. Self-host it for free (Dheeraj runs his on Oracle Cloud’s free tier) or pay $20-24/month for cloud. Pair it with Claude Code and the learning curve drops significantly.

The output quality is roughly equal across all three platforms because it ultimately depends on your prompts. The real differences are in flexibility, control, and how much of the pipeline you can automate end-to-end.

Watch the Full Session

This was Episode 2 of One Shot Show, Season 1. We’re going live every Wednesday at 10:00 AM EST.

Here’s what’s coming this season:

1. Build a Content Research Agent with Claude Code (Episode 1)

2. Google Opal vs n8n vs Make: Newsletter Repurposing Tool Audit (this episode)

3. Substack Competitive Analysis Using Claude Cowork (Full Tutorial)

4. n8n vs Claude Code & Cowork: Which Is Better?

5. TBD

6. TBD

7. TBD

8. TBD

Eight episodes of real systems and honest breakdowns.

Jump to a specific section:

• (00:00) Welcome and intro

• (01:21) Google Opal feature overview and how it fits into your AI stack

• (02:57) AI chatbot vs AI automation: why pasting into a chatbot doesn’t scale

• (05:55) Google Opal demo: building a workflow with plain English

• (09:35) Agent feature: AI selects the right tools automatically

• (10:10) Key distinction: AI generates the workflow vs human designs it

• (12:07) Comparison table: pricing, triggers, AI capabilities

• (17:12) Opal’s limitation: no direct API publish to social platforms

• (25:23) Output quality reality check: first-pass results aren’t publishable

• (26:05) Anfernee’s tip: one Opal workflow per platform for better output

• (27:14) Wyndo’s refined workflow with custom prompts per platform

• (28:55) Hook generator layer: 11 hook frameworks applied to LinkedIn output

• (29:52) Editor workflow: removing AI-generated writing patterns

• (32:48) Dheeraj’s n8n content multiplication system

• (36:33) Claude Code + n8n MCP: “I don’t create workflows myself anymore”

• (39:07) Final scoring across all three platforms

• (42:02) Who should use what based on technical comfort

• (46:40) n8n MCP setup and n8n as code

• (48:43) Next episode preview: Claude Cowork for competitive research

Resources Mentioned

• Google Opal: Natural language AI automation builder. Free tier, $20/month for Gemini Pro

• n8n: Open-source workflow automation. Free self-hosted, $20-24/month cloud

• make.com: Visual workflow automation. $9-24/month

• Claude Code: Anthropic’s CLI, used with n8n MCP for natural language workflow creation

• n8n MCP server: GitHub project connecting Claude Code to n8n

• n8n as code: New n8n feature representing workflows as code for Claude Code integration

• Nano Banana Pro: Google’s image generation model, chainable inside Opal

• Veo 3: Google’s video generation model available in Opal

• Lyria: Google’s music generation model available in Opal

• Buffer / Typefully: Social scheduling tools, connectable via n8n/make.com

• Oracle Cloud free tier: Where Dheeraj self-hosts n8n at zero cost

All right. That’s it for today!

Until next week 👋🏻

Best,
Wyndo

It’s a live series on Substack where AI builders walk through real AI systems they’ve built — how they work, why they’re structured that way, and how you can build your own. No slides. No theory. We break down what actually works.

For our first episode, Dheeraj walked through a content research agent he built with Claude Code. The kind that takes a topic, scrapes competitor content, pulls research from multiple sources, and delivers a complete research brief with content angles, SEO gaps, and strategic recommendations.

A system that turns 3 hours of manual research into a 4-minute run costing less than $0.10.

Before we get into the details, Dheeraj writes about building AI automation systems for Solopreneurs. You might want to subscribe to his newsletter to learn more.

GenAI Unplugged

Simple AI automation systems for solopreneurs who are done doing everything by hand.

By Dheeraj Sharma

Now, here’s what I learned to during the conversation — and what I think matters way more than the agent itself.

The Real Difference Between a Chatbot and an Agent

Most people doing research with AI right now are using it like a chatbot.

You know the pattern: open ChatGPT or Claude, write a long detailed prompt explaining who you are, what your business does, who your audience is, what kind of research you need, what format you want the output in... and then hit enter.

Every. Single. Time.

And it works. Kind of. But you’re doing all the heavy lifting in that prompt. You’re the one holding all the context in your head and translating it into instructions every time you start a new session.

What Dheeraj showed during the stream was fundamentally different. His agent reads a set of context files before it does anything. These files tell the agent who you are, what your business does, who your competitors are — all written in plain English, not code.

So when you tell the agent “run research on [topic],” you don’t need a long prompt. You just need a short instruction. The context is already there.

That’s what makes it an agent instead of a chatbot. The agent has memory. It has awareness. It knows who it’s working for before you even ask it to do anything.

And the way Dheeraj structured this is worth breaking down.

The Three-Layer Architecture

During the stream, Dheeraj broke down the full structure of his agent. I think this is worth walking through because it makes the whole thing feel less abstract and more like something you could actually set up yourself.

Layer 1: The Tools (MCP Servers)

This is the agent’s hands — what it uses to go out and find information. Dheeraj connected three tools:

• Perplexity for AI-powered web search ($5 per 1,000 requests)

• Firecrawl for scraping competitor pages (500 free pages per month)

• Jina Reader as a free backup when the other credits run out

All three are configured in a single .mcp.json file. The smart move here is having Jina as a fallback — the agent doesn’t just stop working when your paid credits dry up.

Layer 2: Context Profiles (Your Business Brain)

This is the layer I keep coming back to. Three markdown files stored in .claude/research-profiles/:

• business-context.md — who you are, your content history, your audience

• content-strategy.md — your pillars, your voice, what you write about

• competitor-watchlist.md — who you’re tracking, gaps you can fill

This is the layer that makes YOUR agent different from anyone else’s. Same tools, same agent file — but different context profiles produce completely different research. That’s the whole point.

Layer 3: The Agent File (The Brain)

One markdown file — content-researcher.md — that lives in .claude/agents/. It has YAML frontmatter and a system prompt that tells the agent how to behave, what tools to use, and how to structure its output.

This is the part that ties everything together. The brain reads your context profiles, uses the tools, and delivers research that’s actually tailored to your business.

Five files total. No code. Dheeraj estimated about 30 minutes to set up from scratch.

Two Details That Separate Builders from Tinkerers

Beyond the context files — which honestly, that insight alone is worth the whole session — two things stood out to me about how Dheeraj approaches building:

He picks tools with purpose, not hype

Dheeraj’s research layer uses three tools: Perplexity for multi-source synthesis, Firecrawl for competitor page scraping, and Jina AI as a free fallback when credits run out.

What I liked is that each tool has a specific job. He’s not stacking tools because they’re popular. He’s choosing them because they solve a particular problem in his workflow. And having a free fallback (Jina) so the agent doesn’t just stop when paid credits run out — that’s the kind of thinking you only get from someone who actually uses their own systems daily.

He builds in cost guardrails from day one

Dheeraj has a rule in his agent that caps Perplexity API calls at three per research session. Not because three is a magic number — because he already burned through credits figuring out where the waste happens.

Nobody posts about this on social media. But this is the difference between a system you actually use every day and a cool demo you abandon after a week because the bill surprised you.

Subscribe now

Why This Matters for You

Here’s the takeaway I keep coming back to:

If you’re still writing long prompts every time you use AI for research, you’re working harder than you need to. The shift from chatbot thinking to agent thinking is really just this — write down your context once, save it as files, and let the AI read those files every time it works for you.

You don’t need to build exactly what Dheeraj built. But you can start with the foundation today:

• Write your business context in a simple markdown file. Who are you? Who’s your audience? What do you do?

• Write your content strategy. What topics do you cover? What’s your voice? What do you avoid?

• Write your competitor watchlist. Who are you watching? How are you different?

Three files. Plain English. That’s your starting point for any AI agent you build from here.

Watch the Full Episode

This was Episode 1 of One Shot Show, Season 1 — and we’re going live every Wednesday at 10:00 AM EST.

Here’s what’s coming this season:

✅ Build a Content Research Agent with Claude Code (this episode)

2️⃣ How to Repurpose Your Newsletter Using Google Opal (vs n8n vs Make)

3️⃣ Substack Competitive Analysis Using Claude Cowork

4️⃣ n8n vs Claude Code — Which One Is Better?

5️⃣ TBD

6️⃣ TBD

7️⃣ TBD

8️⃣ TBD

Eight episodes with real systems that you can apply in your workflow.

Jump to a specific section:

• (00:00) Introduction — What is One Shot Show

• (04:36) Today’s topic: Building a content research agent with Claude Code

• (07:00) The three-layer architecture explained

• (10:02) Layer 1: Setting up MCP servers (Perplexity, Firecrawl, Jina)

• (13:35) Why Perplexity and Firecrawl over Claude’s built-in tools

• (18:50) Layer 2: Building your business context profiles

• (25:54) Content strategy and competitor watchlist files

• (33:42) Layer 3: The agent file — plain English, no code

• (43:05) Live demo: Running the agent on a real topic

• (48:05) Chatbot vs. agent — why you don’t need long prompts

• (51:07) Reviewing the research output

• (56:01) Q&A: How does this compare to deep research in ChatGPT/Gemini?

• (01:00:01) Q&A: Firecrawl vs. Apify for scraping

• (01:03:06) Wrap-up and what’s coming next

Read Dheeraj’s full technical breakdown — he documented the complete architecture, MCP server setup, and configuration files so you can build this yourself:

👉🏻 How to Build an AI Content Research Agent Using Claude Code

Subscribe to both our newsletters so you don’t miss next Wednesday’s episode.

See you in the next one.