Over the past year, AI Maker grew to more than 20,000 subscribers and became a Top 50 Substack in Technology, making it the fastest growing AI newsletter on Substack.

That did not happen because I found one magic prompt. In fact, there’s no magic prompt.

It happened because I started building a system around my work.

Behind my newsletter, I have source files, style guides, audience profiles, performance notes, draft archives, topic ideas, launch plans, and rules for how good work should look.

All of these are built to help me boost my productivity.

When I use an AI agent inside that system, it helps me do real pieces of the newsletter operation:

1. Read the right source material before giving feedback.

2. Compare a new draft against my actual writing style.

3. Turn messy ideas into clearer outlines.

4. Find gaps in a launch plan.

5. Repurpose one idea across newsletter, LinkedIn, Notes, and X.

6. Catch problems before something goes out.

I still make the judgment calls. I still choose the angle. I still do the final pass.

But the repeated setup work is no longer trapped in my head or scattered across my AI chats.

That’s the part I think more people need to understand.

The next shift in AI isn’t just better chat or better models.

The models are already good enough for a lot of serious knowledge work. The bottleneck is whether your work is set up in a way agents can actually use.

That is where the real productivity jump comes from.

Not from typing one clever prompt into a blank chat window.

From building an agentic workflow where AI can read your files, follow your standards, use the right tools, connect with the apps where your work already happens, and help execute bigger chunks of work.

Chat is still useful. I use it every day.

But if you only use AI as a chatbot, you are leaving most of the new capability on the table.

And this is why the shift is not easy.

Using chat AI is simple. You open a box, type a request, and wait for an answer.

Working with agents is different.

You need to understand:

1. Features: which agentic commands actually matter.

2. Planning: how to create a plan the agent can execute without getting lost.

3. Knowledge base: how to organize your files, chats, transcripts, and examples so the agent can use them.

4. Context files: how to teach the agent who you are, how you work, and what good output looks like.

5. Human in the loop: when to stay involved and when to let the agent run.

6. Connectors: how to connect the agent to the apps where your work already happens.

7. Error correction: how to find the root cause of AI mistakes so they do not keep repeating.

8. Evals: how to create checks so the agent can catch problems before they reach you.

9. Automation: how to turn repeated work into end-to-end skills and workflows.

10. Self-improvement: how to make the agent get better the more you use it.

11. Security: how to protect your files, data, permissions, and work.

12. Strategy: how to decide what to build when AI can build almost anything.

That is why learning agents is harder than learning chat.

Chat is a tool you use.

Agents are systems you design, guide, correct, and improve over time.

That is also why I do not think most people will make this shift just by watching a few tutorials.

They need structure. Examples. Support. And real work to build on.

That is why I’m building something new with .

I first connected with Michael about a year ago, and we’ve been talking ever since about AI, writing, learning, and where this agentic shift is going.

Michael is one of the strongest long-form writers I know. He has spent years studying mental models, learning, and how to turn complex ideas into writing people actually understand. His work through Blockbuster Blueprint has reached 115,000+ subscribers, and he has been deep in AI-assisted thinking, Claude Code, and agentic workflows too.

Our strengths are complementary.

So we decided to build something together.

It is called Agentic Academy for Knowledge Work.

It is a 10-week cohort for people who want to move from AI chat into agentic AI work.

The cohort starts Monday, June 15 at 11:00am EST.

I’ll share more on next Monday, but I wanted to give you the heads up first.

If you’ve been feeling like AI is useful but still too manual, this is the shift we’re going to help you make.

If you want to keep up with the launch notes and the full announcement next week, subscribe to Agentic Academy for Knowledge Work here:

Agentic Academy for Knowledge Work

10-week cohort for building AI agents that 10x your productivity

By Michael Simmons

More Monday,

Wyndo

I keep running into the same annoying problem with AI agents.

I give the agent a real task. Not a tiny prompt like “rewrite this paragraph” or “summarize this file.” A real task.

Research this topic and turn it into a brief. Build this app and check that it works. Take these newsletter posts and turn them into a batch of social posts.

The agent starts working. It makes progress. Then it stops and waits for me.

So I type something like: “Continue, please.”

Then it works again. Then it stops again.

So I type: “Keep going.”

After a while, I realize I am not really delegating the work. I am sitting there like a tiny project manager for a machine that keeps needing permission to take the next obvious step.

That’s the part that feels weird, because I still can’t see the promise of AI fully offloading my work.

As agentic models, Claude Code and Codex are clearly getting smarter. They can handle more work than they could even a few months ago: research, writing, file edits, debugging, batch processing, and longer project tasks.

But that creates a new problem. The agent can execute more steps now, but it still does not always finish the job end to end. It might move the work forward, then stop. It might complete the obvious part, but skip the check. Or it might say the task is done before it has shown any real proof.

And honestly, I don’t see this as delegation at all. Complete delegation means I’m no longer the bottleneck between AI and my work.

I want to give it the job, walk away for a bit, and come back to one of three things:

1. The finished work.

2. A clear blocker.

3. A short report showing what happened.

That sounds simple, but this is where the real shift happens.

For small tasks, prompting is enough. You ask, it answers, you respond, and the loop works fine.

But long-running work is different. If the job needs several rounds of work, checking, fixing, and retrying, the agent needs more than another instruction.

It needs a finish line.

The question changes from “What should I ask next?” to “What does done look like, and how should the agent prove it?”

The Two Ways AI Quits On You

When you give an agent a bigger task, I think there are two common ways it can fail:

1. Fake done

The agent says the work is finished, but when you check it, the source links are missing, the file count is wrong, the page does not render, or half the batch never got processed.

This is the one that makes you lose trust.

2. Undefined done

The agent can move the work forward, but it does not know what the finished version should look like, how to check its own work, or what boundaries it should respect along the way. So it guesses. Sometimes that means it stops too early. Sometimes that means it keeps trying more things. Either way, you are still the person deciding whether the job is actually finished.

This is the one that keeps you as the bottleneck.

At first, I blamed the agent for both. I thought the model was being lazy when it stopped early.

But the more I used these tools, the more I started to think the real issue was the finish line I gave it.

I was giving instructions without giving evidence.

There is a difference.

The Developer Hack: Ralph Wiggum Loop

Developers saw this problem earlier because code gives agents a clearer finish line.

A bug fix can pass or fail. A test can run. A file can change. A terminal can show an error.

So when coding agents started stopping too early or calling work done too soon, developers had an obvious question:

“How do we keep the agent working until the check actually passes?”

One workaround became known as the Ralph Wiggum loop. The basic idea is pretty simple:

1. Give the agent a task.

2. Let it work.

3. Check whether the work passes.

4. If it does not pass, send it back in.

5. Keep looping until the condition is met or the process hits a stop point.

In fact, Anthropic team shipped it as plugins. The Ralph Loop became really hyped earlier this year. And I like the idea because it points at the right problem: the agent should be able to finish the work according to your instructions and stop when the work reaches a condition you can verify, not halfway through.

But the Ralph Wiggum version still feels very developer-centric for me. Because it involves with scripts, terminal commands, task files, test suites, and some kind of loop wrapper. That makes sense if you are shipping code. It feels much harder if the job is research, writing, inbox cleanup, campaign planning, content repurposing, or a messy project backlog.

Most knowledge work does not have a neat test suite. That does not mean it has no finish line. It just means we have to write the finish line differently.

Why /Goal Mode Matters

This is why I think goal modes in tools like Claude Code and Codex are worth paying attention to.

I think this is the evolution of the Ralph Loop. The pattern is moving from a developer hack into the agent itself.

The way it works is pretty simple.

You type /goal and describe the condition you want to be true when the work is done:

• In Claude Code, that condition starts the work. After each turn, a smaller evaluator checks the conversation and asks: has this condition been met? If yes, the goal clears. If no, the evaluator gives a short reason, and Claude starts another turn with that reason in mind.

• Codex treats the goal in a similar way. The goal text becomes both the starting instruction and the completion criteria. Codex keeps that objective attached while it works, and uses it to decide what to do next, whether the task is finished, or whether it needs more input.

Regardless of which agents you use, the core function of the /goal is the same:

Instead of asking the agent to do one thing and waiting for it to stop, you define an outcome and success criteria. Then the agent keeps working across turns until it has evidence that the goal has been met, or until it needs to stop and report what blocked it.

That changes the job of the human. You are defining the finish line clearly enough that the agent can work toward it instead of micromanaging every next step.

This is a different skill from prompting.

A prompt usually says, “Do this.”

A goal says, “This is what should be true when the work is done, this is how you prove it, and this is when you stop.”

The goal can’t be vague, because if it is, the agent has to guess what it means and you’ll end up with an output you don’t really want.

For example:

• “Organize my files” sounds helpful, but what does organized mean?

• “Research this topic” sounds normal, but how many sources count? Which questions need answers? What should happen if something cannot be verified?

• “Repurpose these posts” sounds clear in your head, but does that mean 5 posts, 50 posts, every post in a folder, or only the ones that match a certain topic?

The agent cannot grade what you never defined. And this is the part I think matters most: The agent can only be judged on evidence it surfaces.

If it says, “I checked everything,” that is a claim. If it shows the list of files it processed, the sources it used, the tests it ran, the pages it rendered, the links it could not verify, and the blockers it hit, that is evidence.

A good finish line is built from evidence, not vibes.

Subscribe now

How I Used Goal To Build A Landing Page

The easiest way to see this is with a real task.

I tested this by asking Claude Code to build a landing page for a free download called the Claude Code Goal Kit.

The job was not just “make me a landing page.”

That would have been too vague.

I wanted a single-page responsive index.html that captured an email in exchange for the kit. I wanted it to follow a direct-response structure. I wanted the claims to stay specific. And I wanted the agent to prove the page met the bar before it called the job done.

The prompt I used didn’t just tell the agent to build a page; it also told the agent what the page was for, what structure to follow, where to deploy, what kinds of claims were allowed, what proof to show, and when to stop.

The result was a landing page that was deployed instantly on Vercel, with no back-and-forth at all: https://goal-kit-landing.vercel.app/

The page contains specific numbers as I put in the prompt, which is important, because this shows that the agent has to follow my specific inputs and verify the numbers before it can say the job is done.

It also followed the seven sections of what makes a landing page good for boosting conversions. It included the problem and proof sections. It gave the CTA a benefit. It built the page as a real artifact instead of only giving me copy in a chat window.

This is exactly what I wanted from an agent: I can ask it to do something, walk away, and by the time I get back, the work is done.

What We Are Building

Here comes the most important part of this post: how to replicate what I’ve learned so you can apply it on your own, regardless of what tasks you want the agent to do.

By the end, you should be able to write a goal that gives the agent six things:

1. A clear outcome.

2. Proof that the work is finished.

3. Guardrails for what should not break.

4. Boundaries for what the agent can touch.

5. Next-Move rule that tells the agent what to do after a check fails.

6. A stop rule for when it should report back instead of guessing.

That is the framework.

Then we are going to apply it to three different jobs:

1. A company research goal, where the finish line is a Google Sheet filled with one brief per company from a source list.

2. A landing page goal, where the finish line is a rendered page with the right sections and checks.

3. A repurposing goal, where the finish line is a completed batch with every source accounted for.

I think those three examples well represent the variety of things you can do with ‎⁠/goal⁠. They show three different kinds of “done”: a verified answer, a working artifact, and an empty queue.

After that, the goal is to make this usable beyond my examples.

So we are also building a small interview skill called /goal-prompt-builder. You tell it what you want the agent to do, what proof should count, what boundaries matter, and when the agent should stop. Then it gives you a ready-to-run goal prompt for your own task.

That means the framework is not locked to research, landing pages, or repurposing. You can reuse the same shape for inbox cleanup, project backlogs, company briefs, draft checks, file organization, or any long-running task where the agent needs to work, check, fix, and report back.

That is what I want from agent work: an agent that knows the finish line, shows its proof, and tells me when it cannot get there.

Now, let’s dive into the six frameworks for building effective goals.

The Six-Part Framework For A Goal That Actually Finishes

The landing-page example worked because the goal had more shape than a normal prompt.

If I want an agent to run for longer without me hovering over it, I need to give it that shape on purpose.

This is the six-part framework I am using to turn a vague task into a goal an agent can actually finish:

1. Outcome.

2. Proof.

3. Guardrails.

4. Boundaries.

5. Next-move rule.

6. Stop clause.

Each part prevents a different kind of agent failure.

1. Outcome

The outcome is the end state in one sentence.

This is where you describe what should be true when the job is finished. Not every step the agent should take. Not every possible detail. Just the result you want to come back to.

Weak outcome:

“Research this topic.”

Better outcome:

“Read the company list from this spreadsheet, research each company, and write one completed row per company into a Google Sheet with columns for what the company is, the problem it solves, the product it sells, who it serves, source links, and anything that could not be verified.”

The better version gives the agent a target. It does not just tell the agent to start moving.

2. Proof

Proof is what the agent has to show before it can call the work done.

This is the part most people skip.

They ask the agent to finish the task, but they do not ask it to surface the evidence. Then the agent says “done,” and now the human has to inspect everything manually.

For company research, proof might mean:

1. Every company from the source sheet has a completed row in the output sheet.

2. Each row includes company overview, problem, product, target customer, and source links.

3. Anything unverifiable is marked clearly instead of guessed.

For a landing page build, proof might mean:

1. The page renders successfully.

2. The expected sections are present.

3. The agent reports anything that still looks rough.

For a batch job, proof might mean:

1. Every input file has a matching output.

2. The final count is shown.

3. Failed items are listed separately.

The point is simple: do not let the agent grade itself with a sentence. Make it show the receipts.

3. Guardrails

Guardrails tell the agent what must not break while it works.

This is important because agents can sometimes technically satisfy the outcome while damaging something else.

If the goal is to clean up a batch of drafts, a guardrail might be:

Read more

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.

The replies were good. Better than I expected. But they created a small problem for me.

I could turn every one of those replies into a paid post. The issue is that not every reply actually deserves one. Some of them are a real implementation system with enough setup, files, and checks to justify a full AI Maker Lab guide. But a lot of them are a single skill, a small workflow, or a tweak that I can show you in ten minutes.

So instead of stretching a simple workflow into a deep post just to fill a slot, I decided to compile the smaller ones into a live session and show them in one sitting.

That is what the monthly teardown is for.

This was the second one.

Last month we ran it more like a Q&A, where people submit questions and I answer them. It was helpful, but I felt like it was missing the more valuable part, which is taking a real case and showing the workflow or the skill behind it. So this time I shifted the format. joined me as co-host, monitored the chat, and pushed back on me a few times, which is exactly why having him there is useful.

We worked through six reader questions, plus two bonus workflows I had found on the internet and wanted to test out. I will share the skills and templates in this post.

Why I Bucket Reader Ideas Before I Build Anything

Before we get into the questions, here is the filter I used, because it shaped the whole session.

When a reader tells me what kind of posts they want me to write next, I sort it into one of two buckets:

• The first bucket is a full paid post. This is something that needs role design, company context, multiple files, decision rules, logs, and a maintenance loop to actually work. From this batch, two ideas passed that test: an AI board of advisors for business owners, and an AEO page generator built around a real website. Both of those are coming as their own posts later.

• The second bucket is the teardown. This is the smaller stuff. A skill, a single workflow, a setup question that is better answered by showing the thing running and where it breaks than by writing five thousand words about it.

This was important because most of the replies I got were not actually asking for a bigger system. When I read them together, the pattern underneath was the same. People were not asking for more AI agents. They were asking how to move work from one place to the next without losing it. Chat to action. Transcript to ideas. Document to slides. The agent part was rarely the problem. The handoff between steps was.

That framing carried through almost every question we covered.

What You Walk Away With

Everything I show in this post is yours to keep, the actual skills and the templates behind them, not just a description of how they work:

1. The handoff skill that carries a conversation into your next session.

2. The transcript to angles board that turns a client call into LinkedIn ideas.

3. The docs to deck skill that moves a strategy document into a clean presentation.

4. The Visual Plan Builder that convert your plan into HTML visual file

5. And Opposite Start Ideation for finding a content angle nobody else is writing.

Each one comes with the template, ready to drop into your own setup and run this week.

So read for the question that matches a problem you have, take the skill attached to it, and use it.

Subscribe now

Question One: The Decision That Disappears Three Days Later

The first question described a problem I think a lot of people have. He has a great conversation with AI, makes some decisions, lines up next steps, and then a few days later all of that is gone. The reasoning vanished. He could not pull a real action out of the conversation later.

My answer is a skill I use called handoff.

The idea is simple. Every time you finish a real working session with AI, you do not save the whole conversation. You run something that summarizes what happened, where you landed, and what the next step is, and it writes that into a new file you can open later. When you start the next session, you point the agent at that file and pick up from there instead of starting cold.

The way I run it, I have a conversation in Codex, trigger the handoff skill, and it drops a summary file into a folder. Then I open Claude Code and ask it to review that output, since it was written by a different model. So one tool does the work, the other checks it.

Dheeraj made a good point here that reframed the question. What I was showing was the execution side, how to do the handoff. But the deeper need was memory: how do you manage the conversations that already happened so the AI can reference them in future decisions. His take was that a log file gets you most of the way there as a starting scaffold, but you have to keep optimizing it, because you cannot let it grow forever without hitting the context limit.

We landed on a two-file shape. A log for what is happening in the session, where you are and what the progress is. And a plan file for the bigger thing you are working toward. The log tells you where you are right now. The plan tells you where that sits in the larger project. Both get referenced in your CLAUDE.md so they do not get dropped every time you close a session.

One thing we both agreed on: this does not work well in a plain chat window. Chat has its own context limit, and once you load too much past history it stops making progress. A project folder or a Code session can auto compact and keep going. Although I will add that I do not love relying on auto compact, because you never really know what it kept and what it threw away. I would rather have my own compacting workflow that I can trust, tuned to how I actually want to resume work.

You can grab the handoff skill below:

Read more

Every morning, I was still the glue.

I would check Calendar to see what was coming up. Then Gmail to see who needed a reply. Then Slack to see what changed. Then Granola to remember what happened in yesterday’s meetings. Then Notion or Obsidian to check the work I said mattered.

After all of that, I would open AI and ask it to help me plan the day.

The weird part was that AI was already useful in each individual step.

It could summarize the meeting. It could draft the reply. It could help me think through the project. It could turn scattered notes into a plan.

But I was still the person connecting everything together.

AI gave me the output.

I moved the output into the rest of my work.

That is the human-middleman problem.

The Old AI Workflow Has A Ceiling

For the last couple of years, this was still useful.

We opened ChatGPT or Claude. We asked for help. We copied the answer into Google Docs, Gmail, Slack, Notion, Asana, ClickUp, Sheets, or wherever the real work needed to happen.

Honestly, that first wave changed how I wrote, researched, planned, learned, and built things. I would not be writing AI Maker the way I do without it.

But the pattern had a ceiling.

AI lived in one place. My work lived everywhere else. So even when the answer was good, the handoff was still mine. That is why this year feels different to me.

I have written before about the shift toward the agentic era. The short version is that AI is moving from “answer my question” to “help execute the work.”

Claude Code, Codex, Cowork, and tools like them are not just better chat boxes. They can read files. They can work with connected apps. They can run tasks. They can move closer to the tools where work actually happens.

Given enough context, an AI agent can help with large parts of knowledge work end to end. It can research, plan, draft, review, organize, and prepare the next step.

I know that still sounds a little too big when I say it that way.

And to be clear, I do not think this means you hand your work to an agent and disappear. That is not the version I am trying to build.

The part that excites me is more specific: removing more of the mechanical middle layer so I can spend more time on the work that still needs my judgment.

Strategic thinking. Creative work. Writing. Research.

That is where this Chief of Staff idea came from.

Access Alone Does Not Fix It

When we talk about building an AI Chief of Staff, we mean an AI that can help me set my priorities and execute on them.

Because my work is scattered across multiple apps, the first instinct is to think the problem will be solved once AI connects to enough of them: Gmail, Calendar, Slack, Drive, Notion, Granola, and many more.

But access alone creates a new problem.

Now the AI can see more things, but it still may not know what matters.

It can see your calendar, but it does not automatically know which meeting needs preparation. It can read a transcript, but it does not automatically know which promise should carry into next week. It can find an email, but it does not automatically know whether the person is a customer, a collaborator, a friend, a cold lead, or someone you should ignore.

That is where the context layer matters.

The agent needs to know who you are, what you do, what you are building, who you work with, what happened recently, what you promised, and what matters this week.

Without that, it might summarize everything correctly and still miss the point.

But context alone does not remove the morning loop.

If I still have to wake up, open the tool, paste the prompt, point it at the right files, ask it to check the calendar, ask it to review the meeting notes, ask it to create the brief, and copy the result somewhere useful, I am still doing the mechanical work.

The answer was access plus context plus repeatable jobs that can run at the right time.

That combination is what made the Chief of Staff idea feel more useful than just an AI that can do stuff.

What I Actually Wanted From A Chief Of Staff

I did not want a giant AI employee that runs my life.

I wanted something that could look across the places where my work already lives and tell me what matters today.

That was the first job: daily priorities.

Because that is where the scattered-context problem shows up every morning.

If I have three meetings, fifteen unread emails, two open promises from yesterday, one transcript I have not processed, and a paid post I said I would finish, I do not need another generic productivity plan.

I need a system that can say:

1. Here is what is actually on your plate today.

2. Here are the meetings that need preparation.

3. Here are the open loops you should not forget.

4. Here are the emails or messages that might matter.

5. Here are the drafts waiting for your approval.

That is the kind of Chief of Staff I wanted to build first.

What We Are Building: The Chief of Staff

The version I have working now is built around four layers:

1. Source layer: the apps and files the system can read.

2. Context layer: the folder that tells it what matters.

3. Skill layer: the repeatable jobs it can run.

4. Automation layer: the scheduled runs that make useful work show up.

By the end of this build, you should have a small, working version of the system by copying from the folder I’m sharing, which includes:

1. A source setup that shows the AI where to look: Calendar, Gmail, Drive, Notion, Granola, etc.

2. A folder that explains what matters in your work.

3. A few reusable skills for daily briefs, meeting prep, follow-ups, and reviews.

4. A simple automation pattern so the useful parts can show up without you remembering to ask.

5. Approval rules so the system can help without quietly taking over.

If it works, your morning should feel different.

Instead of opening six apps before you know what matters, the first pass is already waiting for you. Instead of digging through yesterday’s transcript, the open loops are surfaced. Instead of rewriting the same prompt every morning, the recurring jobs have a place to live.

I still review the output, make the decisions, and approve anything sensitive. But I am no longer the person initiating every mechanical step.

The Chief of Staff is the type of AI agent I want in my life that can read the right sources, prepare my day, track open loops, and draft the next useful step while keeping anything sensitive behind approval.

You can build it in Claude Code, Codex, or Cowork. Regardless of the model or the app, it works across them. The Claude ecosystem will read ‎⁠CLAUDE.md⁠, while Codex will read ‎⁠AGENTS.md⁠ as the brain of the system.

In this walkthrough, however, we are going to use Claude Desktop or Cowork instead.

Let’s dive into the first layer: Source.

Subscribe now

1. Connect The Source Layer

The source layer is where the Chief of Staff gets the raw material it needs before it can prepare anything useful.

For my setup, the possible sources are Gmail, Calendar, Slack, Google Drive, Notion, Granola.

Yours may be different. The first thing you need to do is map out which apps you’ve been using in your work. This could include tools like Microsoft 365, Atlassian, ClickUp, Monday, Otter, Fireflies, Zoom, or Asana.

What we want to focus on in this layer is where AI can access your work, including projects, commitments, and people you interact with on a daily basis. Don’t overcomplicate it—start small.

How To Connect Sources In Claude

Fortunately, Anthropic has already most knowledge work apps integrated through their MCPs connectors. The integration process should be easier as you just need to authenticate your Claude into the apps account.

If an app requires a custom connector, you may need to add a remote MCP connector URL before authenticating.

To add MCP connection, go to Customize menu on the left side bar in Claude Desktop app and click “+” to add connectors.

All those apps under Anthropic Partners don’t require custom MCP connectors, so I’m sure you can integrate them instantly.

Just find the apps you are looking for and start integrating them.

After connecting, test them in a simple chat before building the whole system.

For example (Google Calendar):

“Look at my calendar for today and summarize my schedule.”

Then (Gmail):

“Look at recent Gmail messages that may need my attention today. Do not draft replies yet. Just summarize possible action items.”

You can also check your meeting transcript (Granola):

“Get my meeting transcript yesterday on Granola and summarize them for me.”

The goal is to know whether Claude can actually see the sources before you build system around them.

What To Connect First

Here is the order I would use:

1. Google Calendar.

2. Gmail.

3. Google Drive or local folder.

4. Granola or another meeting transcript source.

5. Notion or Asana or Clickup/Monday.com as project management tools.

6. Slack or team chat.

7. Task tools, CRM, or extra databases.

This is a good enough list as the starting point.

However, I would be very cautious with Slack specifically and treat it as optional.

Slack is useful because a lot of real work happens there, but it is also noisy. If you connect it too early, your morning brief can turn into a pile of messages instead of a useful plan.

My recommendation:

Do not connect Slack until the Calendar, Gmail, and folder version is already useful.

When you do connect Slack, start narrow:

1. Direct messages.

2. Mentions.

3. One or two important channels.

Do not start with the entire team history. That is how the system becomes overwhelming too quickly.

What To Avoid On Day One

I would not connect:

1. Every Slack channel.

2. Every Notion page.

3. Every client folder.

4. Every transcript archive.

5. Every task database.

That sounds like a stronger system, but it usually makes the first version worse. You want the Chief of Staff to answer a narrow question first:

“What matters today?”

Once it can answer that reliably, you can widen the sources.

The First Source Test

Before building the folder templates, I would run one simple test.

Ask the AI:

“Using my connected Calendar and Gmail, tell me what may need my attention today. Do not draft anything. Do not send anything. Just identify possible priorities, meetings that need prep, and open loops.”

The output will probably be useful, but incomplete.

That is the point.

It should show you what app access can do by itself, and what is still missing.

Most likely, it will know what is on the calendar. It may find a few email threads. It may identify obvious action items.

But it will not fully know which projects matter, who matters, what you promised last week, how you prefer to work, or which things should stay behind approval.

That is why the next step is the folder.

The source layer lets the AI see the work.

The folder tells it how to understand the work.

2. Build The Context Layer

The context layer is the folder that makes the Chief of Staff useful, but this is where I think a lot of AI systems quietly fail.

People connect the apps first. Calendar, Gmail, Slack, Drive, Notion, all of it. Then they expect the AI to know what matters.

The issue is a calendar event does not explain why the meeting matters. An email does not explain whether the sender is a close collaborator, a paid subscriber, a consulting client, a friend, or someone I should ignore. A transcript does not explain which promise should carry into next week.

The folder fills that gap.

For this build, the context layer is just a set of plain files:

chief-of-staff/
├── AGENTS.md
├── CLAUDE.md
├── about-me.md
├── my-work.md
├── tomorrow.md
├── commitments.md
├── people/
├── meetings/
└── briefs/

Nothing about this has to be fancy. You can put this in Google Drive, a local folder, or whatever place your AI tool can read.

The goal is practical: give the AI enough stable context that it stops treating every morning like a blank conversation.

The Minimum File

If you want the smallest useful version, start with five files:

1. AGENTS.md for Codex or CLAUDE.md for Claude

2. about-me.md

3. my-work.md

4. tomorrow.md

5. commitments.md

That is enough to make the first morning brief much better. You can add people/, meetings/, and briefs/ once the first version works. The mistake I would avoid is filling every file perfectly before running the system.

Instead, you should fill each file just enough, run the Morning Brief, and then improve the files when the output reveals what’s missing.

Now, let’s explore what each file’s main function is and how to customize it for your case.

CLAUDE.md / AGENTS.md: The Operating Manual

The operating manual is the file the Chief of Staff reads first.

In the folder I’m sharing here, I include a CLAUDE.md version because Claude Code or Cowork already knows to read that file. If you are building this in Codex, use the same structure in AGENTS.md.

This file tells the AI:

1. What is the job of this Chief of Staff?

2. Which files should it read first?

3. What can it do without asking?

4. What needs approval?

5. What should it do when it is uncertain?

6. What output format should it use?

7. Which skills are available?

8. How it should handle source conflicts.

The template has eleven sections:

1. Role.

2. Reading order.

3. Approval rules.

4. Uncertainty rules.

5. Output format defaults.

6. Source priority.

7. File map.

8. Available skills.

9. Voice.

10. When to push back.

11. Maintenance.

That sounds like a lot, but the file is doing one simple thing: It tells the AI how to behave before it touches the rest of the folder.

Here is the template I would use myself that you can customize it yourself:

Read more

I think most of us already have more personal data than we know what to do with.

Financial data is the easiest example. We have bank exports, card statements, Google Sheets, budgeting apps, CSV files, and random transaction records sitting somewhere. The data exists. Sometimes it is even organized.

But most of the time, nothing useful happens after that.

Maybe you open the sheet once in a while. Maybe you sort by category. Maybe you look at the total and feel vaguely bad for a few minutes. Then you close it because turning that raw data into something you can actually understand feels like another project.

I have definitely done this.

That is why Gencay’s experiment caught my attention. The interesting part is not just that he built a financial dashboard. It is that he took a very normal problem, having expense data but no clear way to use it, and turned it into something visual, searchable, and conversational.

Today’s guest post is from , the creator of LearnAIWithMe, and this is his third contribution to AI Maker. You might want to check out his previous posts on building SEO-optimized content with Claude Cowork and hidden NotebookLM features most people don’t know about.

What I like about his work is simple: he builds real things, tests them, and shares the lessons from the process.

LearnAIWithMe

If you want to build with AI, not just learn how to prompt, this is the right place.

By Gencay

If you want to learn more about what he writes, check out three of his posts here:

1. I Built a Claude Trading Bot That Copies Millionaires

2. I Built a Warren Buffett Tutor with NotebookLM and Claude

3. 77.8% Win Rate Crypto Trading Bot(Clawdbot + One Prompt)

In this post, he uses Claude Code sub-agents to build a financial dashboard from expense data. You can inspect your spending, see trends, compare categories, forecast what might happen next, and even chat with your own financial history.

But the bigger lesson is the way he built it.

Instead of pushing one long task through one crowded Claude session, he split the work across five agents. One handled the frontend. One handled the data layer. One handled the charts. One handled predictions. One handled the AI counselor.

That feels like an important shift. A lot of AI building is moving from “ask one assistant to make the thing” to “direct a small group of agents around a real task.”

This post is a practical example of that shift, using a problem many of us probably already have sitting in our files.

Here’s Gencay.

Hello 👋🏻

Most people build apps with Claude Code one step at a time.

One file, then the next.

One feature, then the next.

There is a faster way. Sub-agents.

Five Claude instances can work in parallel.

Each one owns a piece of the app.

They coordinate through a shared spec folder and finish in a fraction of the time.

I used this to build a five-page expense dashboard with React on the frontend.

Let me walk you through it.

What Are Sub-Agents in Claude Code?

A sub-agent is a separate Claude instance that runs inside your main session.

It has its own context window, its own system prompt, and its own tool access.

You give it a task. It works in isolation. It returns a summary.

Three things make sub-agents different from just opening another Claude Code window.

1. They preserve your main context. Test logs, file searches, error traces stay in the sub-agent’s context.

2. You can run them in parallel. Five sub-agents, five jobs, at the same time.

3. You can restrict their tools. A research agent gets read-only. A builder agent gets write access. A tester agent gets bash.

To activate one, you can let Claude pick automatically or define your own in .claude/agents/ as a markdown file with YAML frontmatter.

For this build, I defined five.

What We’re Building

We’ll build a five-page expense dashboard.

1. Overview: total expenses, date range, key metrics

2. Dashboard: category pie chart, monthly bar chart

3. History: weekly and monthly trend lines

4. Predictions: Prophet forecast with confidence intervals

5. AI Counselor: chat interface with full expense context

React frontend. FastAPI backend. Playwright for tests (if needed).

This is the fastest stack to spin up with sub-agents.

• React renders the dashboard,

• FastAPI serves the CSV without a database setup

• Playwright catches the bugs the agents miss before you do.

Step 1: Crafting the Prompt to Initiate Sub-Agents

Create a new folder on your desktop, let’s say name it “Financial Dashboard”.

Locate your expense data.

Open VSCode or the Claude app, choose this folder and save this prompt.

Prompt:

I have an expense dataset at [YOUR CSV PATH].

First, analyze this CSV:

- Show me the columns and their data types

- Show sample rows

- Identify date columns, amount columns, and category columns

Then spawn 5 sub-agents in parallel to build a React expense tracker:

Sub-Agent 1: Frontend Architect

- Sets up React + Vite + Tailwind

- Defines the design system, routing, shared components

- Tools: Write, Edit, Bash

Sub-Agent 2: Data Layer

- Builds FastAPI endpoints to serve the CSV data

- Handles category detection and date parsing

- Tools: Write, Edit, Bash, Read

Sub-Agent 3: Visualization

- Builds Overview, Dashboard, History pages

- Uses Recharts for all charts

- Tools: Write, Edit, Read

Sub-Agent 4: Prediction Engine

- Wraps Prophet in a Python microservice

- Exposes a /predict endpoint that returns forecasts

- Tools: Write, Edit, Bash

Sub-Agent 5: AI Counselor

- Builds the chat interface in React

- Connects to Claude API

- Injects expense data as context on every message

- Tools: Write, Edit, Read

Coordinate through a shared /specs folder. Each sub-agent writes its

API contract there before building.

Save everything in [YOUR PROJECT FOLDER].

Replace [YOUR CSV PATH] and [YOUR PROJECT FOLDER] with your paths. Here’s the CSV file you can use as reference to record your financial details.

The trick is the /specs folder.

Each sub-agent writes its contract before it codes.

The frontend agent reads what the data agent will return.

The data agent reads what the frontend expects.

The contracts align before any code is written.

Subscribe now

Step 2: Building the Agents and the Dashboard

Hit enter.

Claude opens with the analysis step. It reads the CSV, prints the columns, the data types, and a few sample rows. Mine was a 2024 weekly expense log, so it picked up the date column, the amount column, and the category column on the first pass.

Once the analysis is in, Claude creates the orchestration task. This is where the five sub-agents get scheduled.

Then it writes a markdown file for each sub-agent. Five files.

One per agent. Each file holds that agent’s name, scope, tools, and the contract it owes to the others.

Open any of them and you can see the structure. Here is the AI Counselor file.

After the files are in place, Claude launches the sub-agents. All five start at the same time.

Each one runs on its own instructions inside its own context window. You can click into any of them mid-run to see what they are doing. Here is the AI Counselor agent live.

It stays organized because of the spec folder.

Each agent reads the others’ contracts before writing code, so the frontend knows what the backend will return and the backend knows what the predictor expects.

The best part is the reporting. Claude promises to notify you when each agent finishes, and it does.

The clock started at 17:08. Three minutes in, Sub-Agent 4 and Sub-Agent 5 reported done. (17:11)

A heads up. My wife could hear the fan noise from the kitchen. If your battery is under 20%, plug in before you start.

A minute after that, all five agents were done. Claude moved into the integration verification step. (17:12)

Another minute later, integration was clean and the testing pass started.

Here is the final report.

The setup is finished.

The agents have shipped their code, but nothing is running yet.

To see the dashboard, just tell Claude this:

“Run the app”

So I told Claude and here:

It launches the frontend on 5173, the FastAPI backend on 8000, and the Prophet service on 8001.

Three services, one command.

Click localhost:5173 to open.

Share

Step 3: Final Review

Let’s click it inside VS Code and open the app like this if you are using it.

You should land on the Overview page first.

Overview

This is the page you check first. Total expenses sit at the top. Average daily spend, transaction count, and date range fill the rest of the row.

Below that, a donut chart breaks down your top categories. On the right, the five largest expense rows so you can spot anything that doesn’t belong.

At the bottom, a weekly spending heat map. It tells you which weeks ran hot and which ones stayed quiet.

Dashboard

The Dashboard page is where the spending pattern shows itself.

A stacked bar chart at the top covers monthly totals by category. Each bar tells you how a month broke down. You can see whether food, transport, or rent drove that month’s number.

Below the bars, two smaller charts. One tracks the weekly trend over the year. The other shows weekday spending intensity, which weekdays are heavy, which are light.

History

The History tab is the raw log. Every transaction, every row.

You can filter by category, date, or amount. The table is sortable and paginated. This is the page you open when you remember spending something and want to find the line.

Predictions

The Forecast page is where the Prophet engine earns its keep.

Pick a forecast window with the slider. The model returns the next period’s total, with confidence intervals plotted underneath. A short summary tells you whether your spending is increasing, decreasing, or holding.

The line chart at the bottom shows the forecast against the actual history, so you can see how the model is reading your pattern.

AI Counselor

The AI Counselor is a chat interface trained on your data. It has your full expense history loaded as context, so you can ask anything specific.

• “Where should I cut back?”

• “Compare this month to last month.”

• “What’s my biggest expense category?”

• “Will I exceed $3,000 this month?”

To make this work, you need to put your API key in.

Use this prompt:

“Save this Claude API Key for AI counselor, here is mine <paste-your-key-here>”

Paste your key in there.

The backend reads from .env automatically when it starts, so you do not have to wire anything up manually.

It can be OpenAI, Claude API, or you can grab a free one from OpenRouter or Ollama.

One last thing. If you plan to push this project to GitHub, make sure your .gitignore file includes .env.

Step 4: Browser Testing with Playwright CLI

Once the dashboard looks right, you can run automated browser tests with Playwright CLI.

If you want to install this, here is the link to it: https://github.com/microsoft/playwright-cli

Use this prompt, so it can install it for you.

“Install Playwright CLI in this project and set up a basic config for testing the React app running on localhost:5173.”

Once installed, use this prompt to run the actual tests:

“Use Playwright CLI to test the app end-to-end:

- Navigate to each of the 5 pages: Overview, Dashboard, History, Forecast, AI Counselor

- Verify charts render on each page

- Submit a chat message to AI Counselor and verify a response comes back

- Screenshot every page and save them to /tests/screenshots

- Report any failures with the relevant trace”

If something breaks, follow up with this:

“Read the Playwright trace from the failed test and dispatch the relevant sub-agent to patch the bug. Re-run the test after.”

That last one closes the loop. Claude reads the trace, sends the fix to whichever sub-agent owns the broken page, and re-tests until it passes.

But if your app doesn’t get errors like mine, you won’t have to. Now let’s check the dashboard.

How Can You Adapt This to Your Use Case?

The expense tracker is an example. The pattern is the point.

Five sub-agents, one orchestrator, one tester. The data changes. The frontend changes. The structure stays.

Some swaps that work right now.

• Client dashboard: swap the CSV for your client’s data, swap “expense categories” for “project status,” keep the five pages.

• Personal CRM: swap the data layer for a contacts JSON, swap Predictions for “next follow-up suggestion,” keep the AI Counselor as your relationship advisor.

• Content tracker: swap the CSV for your post analytics, swap Predictions for “next post topic forecast,” keep everything else.

The sub-agent definitions stay almost identical. You change the prompt’s first paragraph. The five agents handle the rest.

The Bigger Picture

One prompt used to build an app. Now one prompt builds a team.

The shift is from prompter to orchestrator. You stop writing apps. You start running five agents that build, test, and fix without you in the loop.

The data is yours. The agents are yours. The dashboard is yours.

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

I used to think SEO was a separate thing from writing.

I would finish a post, feel good about the argument, then remember there was still another layer I had ignored: the SEO title, subtitle, slug, internal links, tags, and image alt text.

And honestly, I kept avoiding it because most SEO advice made the writing worse.

• The title became flatter.

• The headings became too obvious.

• The intro started sounding like it was answering a search query instead of talking to a real person.

This explains what I’ve been seeing here on Substack, especially with so many great writers who have strong storytelling skills—but when I look at the posts themselves, it’s clear they don’t really care about SEO.

No clear search title. No keyword direction. Weak internal links. Images without useful alt text. Slug URLs that are partially cut off, like they didn’t even bother to look at them.

And I get why this happens.

Most writers do not want to write for SEO. I do not either. I want the post to sound like me first. I want the argument to work for the reader already in front of me.

But once you publish something on the internet, discoverability becomes part of the job whether you care about SEO or not.

That doesn’t mean every writer needs to become an SEO expert. I also don’t think SEO should take over the writing process.

The goal is smaller than that.

I want great writing to be easier to find without losing its soul to keyword-stuffed optimization.

Imagine you have a Substack post that sounds like you. The story is there. The argument works. You are almost ready to publish. But you still want the post to be easier to find, easier to understand from search, and better connected to the rest of your archive.

If that’s you, this post is for you.

Does SEO Still Matter When AI Search Is Growing?

Now, the obvious question is whether SEO still matters now that AI search is growing.

I understand why people question it. If you’ve been in the AI rabbit hole like me, you already know that AI search is growing. Google is adding AI answers. More people are asking Claude, ChatGPT, Perplexity, and Gemini the questions they used to type into Google.

But I don’t think SEO becomes irrelevant. What I understand from this shift is the way people discover writing is getting more complicated.

Graphite looked at search traffic across 40,000 large US sites and found that "SEO traffic is down slightly (-2.5%), not dramatically." Semrush makes a similar point from the AI-search side: "Traditional rankings still matter," but AI visibility is becoming another layer to pay attention to.

So no, SEO is not the whole game anymore, but it’s still part of the game. You still need to help readers, search engines, and AI systems understand what your post is about.

We can talk about GEO (Generative Engine Optimization) separately in a later post. For now, I want to focus on SEO because good SEO is still a useful foundation for everything else.

And in my own newsletter, it is not theoretical.

In April, Google accounted for around 60% of my Substack traffic (over 86,000 visits in total) and roughly 30% of my subscription revenue. That was enough data for me to stop treating Google as a tiny side channel and start treating it as a new priority.

People are still searching. I still search. And for my newsletter, search is still bringing in real paying readers. Ever since I started optimizing my posts for SEO, Google traffic has been increasing.

So the question became:

How do I improve the SEO layer around a finished draft without turning the post into generic search content?

That is why I built an SEO review agent.

Its job is not to write the post for me. It is not allowed to rewrite the essay by default. It only reviews the finished draft and gives me the parts I usually forget or rush: better metadata, image alt text, slug URLs, internal link suggestions, search intent notes, competitive research analysis, and a list of what not to touch.

That last part matters more than I expected.

Because good SEO should help the right reader find the post. It should not sand down the voice that made the post worth finding.

The Mistake I Kept Making With SEO

My mistake was not that I ignored SEO. I knew SEO was important.

The mistake was that I tried to do the important parts manually, usually after I had already spent most of my energy writing the post.

I would finish a draft, then try to think about keywords, titles, slug, headings, internal links, and image alt text in the last mile before publishing.

And honestly, I did not always do enough research.

I might have a rough sense of the topic, but I would not always check what people were actually searching for. I would not always look at the search results to see what kinds of posts already ranked. I would not always compare my angle against the articles I was competing with.

That matters because SEO is not only about adding a keyword somewhere.

It asks questions like:

1. What would someone search before this post becomes useful to them?

2. Which keywords have enough intent to matter?

3. What does the search result page already reward?

4. Are competitors writing tutorials, comparisons, list posts, or opinion pieces?

5. Does my heading structure make the post easy to understand?

Those are valuable questions.

They are also the exact questions I do not want to spend most of my writing time thinking about.

I would rather spend the deep work on the idea, the story, and the argument. But if I leave the research layer until the end, I either rush it or skip parts of it.

That was the real gap.

Instead of asking AI to write the post for me, I’m asking it to handle the research-heavy SEO review I was doing manually.

The Review I Wanted Before Publishing

What I wanted was simple.

After I finished a draft, I wanted one review that could tell me:

1. What search angle actually fits this post.

2. Which keywords are worth caring about.

3. What the current search results seem to reward.

4. Whether my title, subtitle, slug, and headings make the post easier to find.

5. Which internal links and image alt text I should add.

That would give me the part I kept skipping manually.

I would still write the post myself. I would still decide what to apply. But I would not have to do the whole research process from scratch every time.

That’s the agent’s job: handle the research‑heavy review, then give me one ranked report I can apply manually inside Substack

That is the review I wanted.

Now I will show you how I built it.

Subscribe now

What We Are Building: SEO Review Agent

The SEO review process starts from a command, but the command is just the trigger.

The folder is the system.

The folder looks like this:

seo-review-system/
  README.md
  .claude/
    commands/
      seo-review.md
    agents/
      seo-draft-extractor.md
      seo-search-intent-researcher.md
      seo-competitive-researcher.md
      seo-voice-guard.md
      seo-onpage-writer.md
      seo-internal-link-finder.md
      seo-final-synthesizer.md
  seo-reviews/
      writer-context/
        voice-guide.md
        reader-profile.md
        seo-rules.md
      archive-index.csv

From the outside, the workflow still looks simple.

You run one command:

/seo-review [Substack draft link or local draft file]

Behind that command, the folder gives the agent everything it needs:

1. The finished draft.

2. The writer’s voice and reader context.

3. The writer’s SEO rules.

4. The archive for internal links.

5. The seven sub-agents that run review process.

6. The report destination.

This is the process I’ve been optimizing for months. Before I publish a new post, I run this to ensure it follows the right SEO framework without affecting my rhythm and voice. I’ve also been fixing my past posts that didn’t follow the right SEO framework.

If you follow this process, once you finish the SEO agent review, you’ll receive a 15–20 page SEO report that you can use to improve both your existing posts and your drafts.

What You Need Before This Works

This whole process is meant to run inside Claude Code, where the AI agent can read files, use local instructions, deploy sub-agents, call research tools, and save a final report.

I will share the starter folder, the command file, and 7 sub-agents reviewer files separately.

Before continuing, here’s what you need to prepare in advance:

1. Claude Code. The system needs a coding-agent environment that can work inside a folder and read local files.

2. Tavily or another research tool. This handles search intent, competitive research, and current results. Without it, the workflow can still review structure and voice, but the research layer becomes weaker.

3. A finished draft. The workflow starts after the post is written. It can use a Substack share draft link, a published URL, a local markdown file, or pasted draft text. Make sure your draft already includes images so you’ll receive image‑alt‑text suggestions in the report.

4. Writer context files. You need to fill in their voice-guide.md, reader-profile.md, and seo-rules.md so the system knows what to preserve. But if you follow my context-folder guide, you only need seo-rules.md here.

5. An archive index. Readers need a simple map of their existing posts so the internal link finder can recommend useful links.

6. Full post files when possible. The index helps with quick matching, but full posts help the system understand related ideas, voice patterns, and duplicate framing risks.

7. The command and sub-agents. These do not live inside the source-material folder. They live in the coding-agent setup and call into the folder. Read my post on how to structure your Claude Code agent.

8. A reports folder. The system needs a clear place to save the final SEO review before you can apply changes manually.

The command and sub-agents are the reusable parts. The writer context and archive are the personalization layer. We need all of them to make this works.

Let’s dive in so I can explain how to prepare each one to you.

What Each Folder Does

The secret recipe comes from this folder; it’s not from the command, skill, or even sub-agents.

Because the folder holds all of the context together.

When I first started thinking about this, I was tempted to make the command or skill do everything. Give it a draft link, let it search around, let it inspect the post, let it make suggestions, and hope the final report made sense.

That works for one review.

It does not work as well as a repeatable system.

The problem is that SEO review depends on source material the agent cannot guess. It needs to know how you sound, who you write for, what you have already published, what links are real, and what SEO moves you actually want to allow.

If that context only lives in your head, the agent won’t be able to do its job.

So I separated the system into folders. Each folder answers a different question before the agent starts giving advice.

drafts/

This folder answers one simple question:

What post are we reviewing?

If you’re working in a local markdown file, save the finished draft in your writing-drafts folder (or whichever folder you prefer).

Do not put raw notes, half-written ideas, research dumps, or alternate versions in here unless you want the agent to get confused about which thing is the actual post.

In my current setup, the main input is usually a Substack share draft link instead of a local file. Why? Because I want to include all the images for my post so the review system can suggest how to properly improve my image alt text.

That means the drafts/ folder can stay empty for that run.

But I still keep the folder because it gives me a fallback.

The important rule is simple: The draft should already be written.

This system starts after the writing is mostly done. It is reviewing the publishing layer around the post, not helping me think through the blank page.

writer-context/

This is the folder that makes the review feel like it belongs to you.

It answers two questions:

1. What should the agent preserve?

2. Who is the post really for?

This is the most important folder for writers.

Most SEO tools are good at telling you how to become more searchable. They are not as good at knowing which parts of your writing should stay weird, specific, personal, or imperfect.

That is what writer-context/ is for.

In the starter version, I would include three files:

seo-reviews/
  writer-context/
    voice-guide.md
    reader-profile.md
    seo-rules.md

The first two files should be personal to your publication.

The third file can be mostly the same for everyone.

Let me show you what I mean.

1. voice-guide.md

This file tells the agent how your writing should sound and what it should protect.

This does not need to be fancy. In fact, I think it works better when it is plain.

Here is a version I would use for this newsletter:

Read more

I thought Claude Code had become the center of my AI work.

For most of what I do, it still is. My drafts live there. My archive lives there. My writing rules, content ideas, review process, research notes, and performance data are close enough that Claude can read them, reason over them, and create the next thing in the right place.

That already solved a big problem for me. But the more I used it, the more I noticed a different ceiling. Some work should not wait for me to open my laptop.

Every morning, there are already signals I want to see before I start writing or planning. My calendar has changed. Emails have come in. New AI announcements dropped overnight. My Substack Notes have fresh analytics. A few topics might be gaining traction. A few things might look urgent but not actually matter.

Claude Code can help me think through all of that when I ask. But in my current setup, it still depends on me sitting in front of my laptop first. That is the part I have been testing with Perplexity Computer.

Yet, that is where my confusion started.

Because I already use Claude Code. So when I first looked at Perplexity Computer, I kept asking:

“Where does this actually fit? Why do I need another agentic tool? What can Perplexity do compared to Claude Code?”

The answer became clearer only after I stopped comparing them as if they were doing the same job.

💡 A quick related note…

Ruben runs one of the largest AI education newsletters in the world. Two emails a week, each one a step-by-step workflow with screenshots you can use the same day.

How to AI

Stop collecting AI tips. Run practical AI workflows, with exact prompts, screenshots, and steps you can follow. Finish something with AI today. Free.

By Ruben Hassid

Three of his posts I keep coming back to:

• Prompting is the worst way to use Claude

• How to stop hitting Claude usage limits.

• Claude For Dummies

What Perplexity Computer Is

Perplexity Computer is Perplexity’s agentic tool for giving AI a job instead of just asking it a question.

The simple version: you describe what you want done, and Computer can break the task into smaller steps, browse the web, use connected apps, create files, and keep working in the background.

The feature people talk about most is the multi-model part.

Perplexity Computer can route work across different AI models from companies like Anthropic, OpenAI, Google, xAI, and others. One model might be better for research. Another might be better for long-context reasoning. Another might be better for images, video, or critique.

Perplexity also says Computer connects to 400+ applications. This matters if your work lives across tools instead of inside one folder. Connecting to those apps is also easy with a simple click. This opens up access for non‑technical people to start using it right away, without the complexity of configuring MCP servers.

In addition, Perplexity has a workflow template feature which allows user to input their request and let Perplexity runs everything automatically across marketing, creative, research, product, and more.

With all these capabilities, Perplexity Computer makes my work easier by letting an agent run in the background, pull from different sources, and use different models for different parts of the job.

That is where it starts to feel different from a normal chatbot.

When Perplexity Computer Actually Makes Sense

Now you might be thinking: where does Perplexity Computer fit into your workflow if you’ve been using Claude Code or Codex most of the time, right?

That was the exact question I had when I first tried to make sense of it.

If I need deep control over files, drafts, rules, and review loops, I still want Claude Code or Codex. also agreed with me on this, even after his experiment with Manus.

But Perplexity Computer becomes interesting when the task has three ingredients:

1. It needs to run on a schedule, without requiring my laptop to stay awake.

2. It needs to connect to many apps, which is where Perplexity’s large connector library starts to matter.

3. It benefits from more than one kind of AI judgment, especially when different models may notice different risks or tradeoffs.

That is the filter I am using right now. And that is where Perplexity Computer started to click for me.

I realized that the work I tend to avoid isn’t about thinking, it’s about collecting data or doing administrative tasks that could be automated.

Opening the analytics tab. Checking the right spreadsheet. Looking at yesterday’s Notes. Reading AI news without getting distracted. Comparing what happened against what my readers care about. Looking at my calendar and asking what actually needs preparation.

That is the layer I want Perplexity Computer to handle.

That is why the three use cases I am testing are not random automations. They are all versions of the same pattern: measure what changed, decide what matters, and stress-test an important decision.

1. A Substack Notes analytics logger.

2. A daily brief clash agent.

3. An AI model council for deciding between tools I want to use.

So, we’re going to deep dive into how I tested Perplexity Computer with these three use cases to fully understand its capabilities, as well as measure its cost, which is one of the most important aspects when expanding to more AI tools.

Based on my experiment, I think Perplexity Computer is quite an expensive platform to use. Some of my runs can burn through 100 to 300 credits depending on the task, and doing that every day adds up quickly, considering that 100 credits cost $1.

But the direction feels worth testing, because I want an agent that can do the work while I’m sleeping.

Now, let’s dive in.

Subscribe now

Use Case 1: Substack Notes Analytics Logger (Cost: 200 Credits)

The first workflow I tested was not very fancy.

I wanted Perplexity Computer to update my Substack Notes analytics sheet every morning.

That is it.

But this is exactly the kind of work I keep avoiding because it is small, repetitive, and annoying. I post Notes often, but I do not always go back and check which ones are getting impressions, likes, comments, or follow-up energy.

The data exists, but I just don’t want to collect it manually every day.

So I gave Perplexity Computer a simple recurring job: every morning at 9:00 AM, open my Substack profile, find the Notes I posted yesterday, collect up to five of them, check the stats, and update my Google Sheet.

The sheet has a few basic columns:

1. Date

2. Note

3. Impressions

4. Likes

5. Comments

6. Note URL

Here’s the prompt I use:

Collect my Substack Notes analytics and update my Google Sheet.

Substack profile:
https://substack.com/@wyndo

Google Sheet:
[INSERT LINK]

Sheet tab:
[INSERT TAB NAME]

Required columns:
Date, Note, Impressions, Likes, Comments, Note URL

Tasks:
1. Open my Substack profile and go to the Activity tab.
2. Find Notes posted yesterday based on Asia/Jakarta time.
3. Collect up to 5 Notes from yesterday.
4. For each Note, capture:
   - Date posted
   - Full note text
   - Note URL
   - Likes
   - Number of comments
   - Impressions
5. To get impressions, open each Note URL and click “View stats”.
6. If “View stats” is not visible, note that owner login is required.
7. Use the Google Sheets connector to update the sheet.
8. Match existing rows by Note URL first to avoid duplicates.
9. If the Note URL already exists, update Impressions, Likes, and Comments.
10. If the Note URL does not exist, append a new row.
11. Do not use the browser to edit Google Sheets. Use the Google Sheets connector.
12. If Substack only shows fewer than 5 yesterday Notes because of a login wall, collect whatever matching Notes are visible.
13. Do not ask for Substack credentials. If owner-only stats are unavailable, write “Owner login required” in the Impressions column.

Run this every day at 9:00 AM.

It works. I’ve been running this for a few weeks without having to manually update the data in Google Sheets.

But there is also one annoying limitation.

To get impression data, Perplexity needs access to the logged-in Substack view. Public Notes can show likes and comments, but impression data is only visible to the owner. In my setup, that means I need the Perplexity Comet installed so the browser can log in to my Substack account.

When it’s working, Perplexity can browse your Notes, open each one, click “View stats,” collect the impression count, and send the data to Google Sheets through the connector. But the computer needs to stay on, because it requires Comet access.

When it cannot access the owner-only stats, it should just write “Owner login required” in the impressions column and move on.

There’s one more consideration you should know. This process costs me about 200 credits for each run using GPT 5.5. If I have to do it for a month, you can imagine it might cost around 6,000 credits. However, you could reduce the cost by 30–50% if you switch to Sonnet 4.6.

Once the sheet has a few days of Notes data, in addition, you can run another workflow that reviews the week and asks better questions:

1. Which Notes got the most impressions?

2. Which openings seemed to get more attention?

3. Which topics kept showing up in stronger posts?

4. Which Notes are worth expanding into a newsletter?

5. Which ideas looked promising but did not get much response?

But I don’t do this with Perplexity Computer. I use Claude Code to analyze it for me because it has access to my whole newsletter project, and I don’t think I want to add more cost here.

So in this case, I use Perplexity Computer only to gather data, while I use my primary agent, Claude Code, to analyze it and make something out of it.

Perplexity Computer saves me time, while Claude Code saves me money. Both work together.

Use Case 2: Daily Brief Clash Agent (Cost: 300 Credits)

The second workflow is the one I am most excited about.

I already have ways to track AI news. The harder part is deciding what is worth saying about it.

A new model launch, founder post, or AI tool update only matters to me if it connects to something my readers actually feel: tool overwhelm, workflow confusion, a repeated mistake, a decision they need to make, or a small behavior change that makes AI easier to use.

So I built this workflow around four roles.

Here’s the prompt I use:

Every morning, create a social content angle brief for The AI Maker.

The goal is not to write full posts. The goal is to find bite-sized, thought-provoking angles I can turn into:
- Substack Notes
- LinkedIn posts
- Twitter/X posts

Use current AI news, product updates, founder posts, AI creator discussions, and any connected sources that help you understand my current writing priorities.

Run this as four roles:

1. News Scout
Find 5 to 8 important AI events, product updates, or conversations from the last 24 hours.

For each one, include:
- What happened
- Why people are talking about it
- Source links
- Who seems to care about it
- Whether it feels overcovered, undercovered, or misunderstood

2. Audience Fit Critic
Review each item against The AI Maker audience:
- Knowledge workers
- Creators
- Managers and leaders
- Entrepreneurs
- Regular AI users trying to build repeatable workflows

Be strict. Do not recommend something just because it is trending.

For each item, ask:
- Would my readers actually care?
- What practical tension does this reveal?
- What workflow, decision, or repeated frustration does it connect to?
- Is this too technical, too abstract, or too obvious?

3. Social Angle Critic
Turn the best items into small social angles.

I want angles that are:
- Bite-sized
- Thought-provoking
- Easy to understand quickly
- Curious enough to make someone stop scrolling
- Specific enough to avoid generic AI commentary
- Useful for Substack Notes, LinkedIn, or Twitter/X

Avoid:
- Full newsletter outlines
- Generic AI news summaries
- Tool hype
- Big future-of-work claims
- “Here are 5 tools” style content
- Overly polished expert takes

Look for:
- A surprising mistake people are making
- A small behavior change
- A tool-selection rule
- A workflow tension
- A question people are asking wrong
- A useful “I thought X, but now I think Y” realization
- A reason to ignore something everyone is chasing

4. Angle Synthesizer
Find the clash between:
- What is trending
- What my readers actually need
- What I could say from a practical builder point of view
- What would work as a short social post, not a full essay

Return 10 social content angles.

For each angle, include:

1. Angle title  
A short internal title.

2. Best platform  
Choose one:
- Substack Note
- LinkedIn post
- Twitter/X post
- Works across all three

3. Hook draft  
Write one opening line that creates curiosity.

4. Core idea  
Explain the point in 1 to 2 sentences.

5. Why this fits The AI Maker  
Explain why my audience would care.

6. Source or trigger  
Link to the news item, post, launch, or conversation that triggered the angle.

7. Content shape  
Choose one:
- Hot take
- Question flip
- Personal realization
- Mini framework
- Tool-selection rule
- Workflow observation
- Contrarian note
- Short story prompt

8. What to avoid  
Name the obvious version of this angle that would be too generic.

9. Confidence score  
Rate from 1 to 5.

End with:
- The 3 strongest angles for today
- Which platform I should post each one on first
- One sentence explaining why each is worth trying

Do not write the final social posts yet. I only want the angles, hooks, and reasoning.

Allow me to explain the prompt.

The first role is the News Scout

It scans the last 24 hours of AI news, product updates, founder posts, and creator discussions. For each item, it captures what happened, why people are talking about it, who seems to care, and whether the topic feels overcovered, undercovered, or misunderstood.

The second role is the Audience Fit Critic

This is the strict filter. It reviews each item against The AI Maker audience: knowledge workers, creators, managers, entrepreneurs, and regular AI users trying to build repeatable workflows.

It asks:

1. Would my readers actually care?

2. What practical tension does this reveal?

3. What workflow, decision, or repeated frustration does it connect to?

The third role is the Social Angle Critic

This role turns the strongest items into small social angles for Substack Notes, LinkedIn, or Twitter/X. It looks for a surprising mistake, a tool-selection rule, a workflow tension, a question people are asking wrong, or a reason to ignore something everyone is chasing.

The fourth role is the Angle Synthesizer

This is where the clash happens. It compares what is trending against what my readers need, what I can say from a practical builder point of view, and what would work as a short social post.

The final output is 10 social content angles.

For each one, I get:

1. Angle title

2. Best platform

3. Hook draft

4. Core idea

5. Why it fits

6. Source or trigger

7. Content shape

8. What to avoid

9. Confidence score

Then it chooses the three strongest angles for the day.

By default, that output lives inside the Perplexity app, so I still need to open the app and review it there.

But this is where the connected-app side becomes useful. You could also send the result somewhere else: Gmail, Slack, Google Docs, Notion, or wherever you already check your work in the morning.

That might sound like a small detail, but it matters.

Overall, this is the output I actually want in the morning. Not a full post, but a sharper starting point.

I still make the final call, but the workflow gives me angles that already passed through the questions I would normally ask manually.

That is where Perplexity Computer starts to feel useful.

One last thing to be noted this process can cost me about 200–300 credits for each run using GPT 5.5.

So make sure you calculate each cost properly and understand the ROI of this process.

Share

Use Case 3: AI Model Council (Cost: 300 Credits)

The third workflow is different from the first two because sometimes I do not want Perplexity Computer to run a recurring brief. Instead, I want it to help me make a better tool decision.

Recently, I wanted to compare OpenClaw and Hermes Agent from a specific perspective: newsletter creator who wants to boost productivity.

I could have asked one model for a recommendation. But that is not really what I wanted. I wanted to know where different models agreed, where they disagreed, and what each model noticed that the others missed.

So I ran the comparison through an AI model council workflow template using GPT 5.5, Claude Sonnet 4.6, and Gemini 3.1 Pro.

The result was much more useful than a normal “which tool is better?” answer.

All three models agreed on the big picture:

1. OpenClaw is stronger for broad orchestration, messaging channels, browser work, scheduled jobs, webhooks, and tool integrations.

2. Hermes Agent is stronger for long-running knowledge workflows because of memory, repeatable skills, subagents, and learning over time.

3. Neither tool is a dedicated newsletter app. Both are agent frameworks that need setup, permission boundaries, and monitoring.

4. The real tradeoff is integration breadth versus learning depth.

That shared agreement was useful.

But the disagreement was even more useful.

1. GPT 5.5 leaned toward OpenClaw when the job was operating across existing tools, but still saw Hermes as stronger for editorial memory.

2. Claude Sonnet 4.6 leaned more toward Hermes for recurring creator work because it put more weight on reliability, compounding improvement, and operational risk.

3. Gemini 3.1 Pro suggested a possible hybrid: OpenClaw as the integration manager and Hermes as the research and drafting executor.

That is the part I would have missed from a single-model answer.

The final synthesis gave me a cleaner decision rule:

✅ Choose Hermes if the productivity gain depends on research memory, voice consistency, repeatable drafting, and compounding improvement.

✅ Choose OpenClaw if the productivity gain depends on broad tool operation across chat, browser, inbox, calendar, and publishing workflows.

This analysis gave me more confidence in my decisions by offering multiple perspectives I might have missed if I had only run it with a single model. The analysis cost me about 300 credits for one run.

The practical takeaway for you is simple: use the AI model council when the decision has a real switching cost.

For example:

1. Which option gives me the most upside without adding too much maintenance?

2. What hidden cost might show up only after I commit?

3. Which path creates the least regret if my assumptions are wrong?

4. Which option is best if I care about speed, quality, cost, or control?

For a small decision, one model is probably enough.

These three use cases are different on purpose.

The first one is about removing a repetitive task I kept avoiding.

The second one is about turning noisy updates into better content decisions.

But the third one is not about asking more models for more opinions. It is about using disagreement to make a decision sharper.

That is why Perplexity Computer started to make more sense to me. It really helps with tasks that need preparation, context from multiple places, or judgment from more than one AI angle.

Subscribe now

How I Would Think About Perplexity Computer

If you want to try Perplexity Computer, I think you need to be precise about what work actually belongs there.

Because if you already use Claude Code or Codex, a lot of tasks may look similar on the surface. Adding Perplexity Computer can also increase your cost quickly if you use it for work another tool could handle more cheaply.

So the question I would ask is:

What can Perplexity Computer do here that my other agents cannot do as well?

For me, the answer comes back to the three benefits I covered in this post:

1. It can run in the cloud.

2. It has access to many app connectors.

3. It can use multiple AI models in the same workflow.

That is where this kind of tool starts to make sense. My answer showed up in three places.

First, analytics. I had useful Substack Notes data, but I did not want to collect it manually every day.

Second, content angles. I had plenty of AI news, but I needed a stricter way to turn the news into something my readers might actually care about.

Third, tool decisions. I could ask one model whether OpenClaw or Hermes Agent was better, but I wanted to see where several models agreed and disagreed before I chose what to test.

Your version may look different.

Maybe you need a weekly customer-reply review. Maybe you need a daily sales lead scan. Maybe you need a Monday morning project brief from Slack, email, calendar, and documents. Maybe you need a multi-model council for a hiring, buying, or strategy decision.

I would look for three signals:

1. The task repeats often enough that manual effort is annoying.

2. The useful context lives across more than one app, source, or model.

3. The output helps you make a decision, not just collect more information.

If a task does not have those three things, I would probably skip Perplexity Computer. Instead, I use:

• Claude Code or Codex when the work belongs close to your files, repo, rules, and review process.

• Make or n8n when the workflow is simple, predictable, and cheaper to automate there.

I would only use Perplexity Computer when the task needs background execution, connected sources, and judgment across AI models.

And start small:

1. One low-risk workflow.

2. One data source if possible.

3. One output you can review before anything gets sent, posted, or changed.

Then watch the cost.

That is the part I am still figuring out too. Some Perplexity Computer runs are useful, but they can become expensive over time. If a task costs hundreds of credits every time, it needs to save real time, improve a real decision, or create a result you would not have produced otherwise.

That is my current rule.

Perplexity Computer is not where I want all my AI work to live.

But it is becoming useful for the work that should begin before I show up: collecting data, preparing the first draft, and making decisions based on the clash between models.

That feels like the next layer I want to keep testing.

Would you give Perplexity Computer a try after reading this?

Let me know in the comments.

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.

A few months ago, I opened a new Claude Code conversation to think through a product decision.

The answer was reasonable. Useful enough. But disconnected.

It did not know which products I already had. It did not know which audience pain point I had heard from members the week before. It did not know what I was trying to avoid. So it gave me the kind of advice that sounded fine and still missed the actual situation.

That same gap showed up during the first AI Maker monthly Q&A for paid members. Eight people asked eight different questions. One person asked about master prompts for Substack growth. Another asked where the money actually is in AI right now. Someone else asked about prompt libraries versus Claude Skills. Then we got into CLAUDE.md, project setup, my current stack, and what I would set up before starting something new.

If there’s one thing I can conclude across these questions, it’s that they all come from the same problem underneath: Maker Lab members are asking how to give AI enough of their world that the answers stop feeling generic.

I recognized it because I had been doing the same thing.

As some of you might already know, I run my newsletter inside Claude Code. In the beginning, my setup was thin, and that was fine: a few rules, a couple of draft examples, some folder structure. Claude could generate good output because the work was still simple enough.

That stopped being true sometime this year. The newsletter expanded into free posts, paid posts, LinkedIn, Substack Notes, live recaps for One Shot Show, infographics, product decisions, member sessions, survey analysis, and a growing list of business calls I wanted to think through with AI. My work got more specific, and my setup did not catch up fast enough.

The prompt was not the real problem

My first instinct was to fix it inside the prompt. I would paste in the existing products. Then the audience. Then recent member feedback. Then whatever constraint I was thinking about that day. The prompt kept getting longer. The output got better, sure. But I was rebuilding my world from scratch every time I started a new chat.

And honestly, that was my mistake because I kept treating the prompt like the place where everything needed to live.

The real problem was one layer below the prompt. If the agent already knew the important parts of my world before I started typing, I would not need to paste them in every time. The prompt could stay small because the source material was already there.

Andrej Karpathy has been calling this “context engineering,” which I think is the right frame. His point is that serious AI work is less about writing a clever prompt and more about filling the model’s context window with the right information for the next step.

That clicked for me because it named the thing I kept running into. I was trying to fix generic answers at the prompt layer, but the missing piece was the material underneath the prompt.

That is the shift this post is about.

If you have followed my Claude Code work, this sits underneath the last two pieces I wrote. The blank folder setup guide was about giving your project enough material for the agent to read. The agent harness post was about the system around the model: the rules, checks, corrections, and review loops that help the agent improve over time.

This post is about the material those systems read.

The truth about your work. Your audience. Your taste. Your decision rules. Your current products. The things you keep repeating in prompts because the agent does not know them yet.

I have been running my own version for a few months. Some of it is working. Some of it I am still rewriting. You are going to see both.

Subscribe now

The context folder I built

The setup is one folder. Inside your project, next to the instruction file your tool already reads, you add a folder called /foundational.

If you use Claude Code, that instruction file is usually CLAUDE.md. If you use Codex, it is usually AGENTS.md.

/your-project
  CLAUDE.md or AGENTS.md
  /foundational
    operator-profile.md
    audience-profile.md
    creator-style.md
    pov-and-principles.md
    decision-rules.md
    project-context.md
    performance-patterns.md

The instruction file is the router. It tells the agent how to work, which files matter, and when to read each one.

The /foundational folder is the source material. Instead of telling the agent what to do, it tells the agent what is true. That distinction took me longer to understand than I want to admit.

At first, I tried to put everything into CLAUDE.md: audience notes, voice rules, tier decisions, product details, current priorities, and anything else I wanted Claude to remember. It felt convenient until the file started getting heavy.

If I asked Claude to fix a typo in a Substack Note, it still had to carry my LinkedIn rules, my paid post boundaries, my product strategy, and a bunch of other material that had nothing to do with the task.

The file was full of useful information. That was the problem. Useful information in the wrong moment still makes the agent worse.

So I split the truth into separate files: one for audience, one for voice, one for decision rules, one for current project context, one for principles, one for performance patterns, and one for how I like to work.

If I ask for a LinkedIn hook, it reads the audience file and the voice file. If I ask whether a topic should be free or paid, it reads the decision rules. If I ask for product ideas, it reads the audience file, project context, and principles.

That is the whole idea: small files, clear purpose, loaded only when useful.

What this changes

The goal here is more modest than perfect AI: a better starting point.

After this is set up, your agent should know the basic truth before you ask the question. It should know who the work is for, what you are building, how you like to make decisions, what your voice sounds like, and which constraints matter for the task in front of it.

That does not mean the first answer becomes final. It still needs your judgment. But it should start closer to the real situation.

You spend less time rebuilding the same background in every prompt, and more time doing the part only you can do: noticing what feels wrong, sharpening the decision, and updating the source material so the next answer starts stronger.

That matters because most AI work is a loop. You ask, review, correct, sharpen, and ask again.

If the first version starts generic, the whole loop gets heavier. If the first version starts closer to your actual work, the loop gets easier to steer.

What you will build for AI context management

The rest of this post walks through the version I am using right now.

By the end, you will have:

1. The routing block: The exact instructions you can paste into CLAUDE.md or AGENTS.md so your agent knows which foundational file to read for each kind of task.

2. The seven files: What each file is for, what to put inside it, what to keep out, and when the agent should use it.

3. The 60-minute setup process: The order I would build this in if I were starting again, including the question I use to pull beliefs and rules from my existing posts.

4. The maintenance loop: How to update the folder from real friction instead of pretending you will do a perfect monthly review.

If you want a context folder that tells the agent enough truth about your work that it can stop guessing, this post is for you.

This context folder works whether you use Claude Code, Cowork, Codex, Cursor, or any other AI agents.

Let’s build it.

The routing instructions

The first thing I would add is the routing instruction.

This goes in the file your agent already reads before doing work. Here is the version I would start with:

Read more

I want to share something a little more personal today. This is partly a product update, but mostly it is the story behind something I have been building because of a problem I kept running into while growing AI Maker.

When I started this newsletter, I thought the hard part was writing the post.

And that part is still hard. But after doing it for a while, I realized there is another layer of work that quietly piles up around the writing.

You finish the post, then you still need to decide what to call it. You need a subject line people will actually open. You need to turn it into a LinkedIn post or Substack Notes. You need your About page to explain why someone should subscribe. You need your welcome email to make new readers feel like they made the right choice. You need the post to be easier to find later.

None of those tasks are the main newsletter, but they matter.

And because they are not the main newsletter, they are easy to delay.

That was the loop I kept running into. I would write the post, feel like the hard part was finished, then realize I still had a pile of repetitive growth tasks around it. The annoying part was not that those tasks were impossible. The annoying part was that they were mechanical, easy to avoid, and still important.

That is where I started thinking differently about AI.

Maybe the most useful place for AI in newsletter creation is not replacing the main draft. Maybe it is helping with the repeated growth work around a newsletter you are already writing.

That is the idea behind Newsletter Compass, which I built with . Joel is a newsletter creator who writes Leadership In Change. So we have both been looking at this from the same practical question: how do you make the growth work around a newsletter less scattered?

To put it simply, Newsletter Compass is a growth toolset for newsletter creators. It helps with ideas, titles, subject lines, Substack Notes, LinkedIn posts, welcome emails, About pages, and SEO.

The newsletter is still yours. The tool helps you do more with it.

The Problem I Wanted To Solve

Most newsletter creators I know do not only struggle with “writing more.”

Instead, what they struggle are with the work around writing.

You already wrote the post, but now you need to promote it. You already have a good idea, but now you need to package it in a way people understand. You already have readers, but now you need to improve the little things that affect whether more people open, subscribe, share, and stick around.

That work can feel boring because it is not the creative high of writing the essay. But if you care about growing a newsletter, it is part of the job.

This is where I think AI can be useful in a very practical way. It can help turn the mechanical parts of newsletter growth into a system. Not a system that replaces your thinking, but one that helps you reuse the thinking you already did.

That last part matters.

Because if you have been writing for a while, your archive already contains a lot of useful information. It shows what you care about. It shows how you explain things. It shows what topics you return to, what language you use, what promises you make to readers, and what kind of relationship you are building with them.

Newsletter Compass uses that archive as part of the product.

Subscribe now

What Newsletter Compass Does Right Now

Some of you might have received my first announcement about Newsletter Compass back in March. Since then, the product has become more complete. It is still early, and I am still building, but the direction is clearer now:

1. Brand Voice Analyzer: This is the foundation. It looks at your existing writing and turns it into a usable profile, so the assets around your newsletter do not sound disconnected from the newsletter itself. It works best when you already have an archive, because the tool needs real examples of your writing to understand your voice, audience, topics, and positioning.

2. Title Generator: Titles are small, but they can steal a ridiculous amount of time. The Title Generator gives you multiple title and subtitle combinations based on your draft, so you are not staring at the post after finishing it and trying to name it from scratch.

3. Idea Generator & Gap Finder: This helps you find angles worth exploring and gaps in your existing content. Sometimes the problem is not that you have no ideas. It is that you do not know which part of your archive needs a next step, a beginner version, a deeper version, or a different format.

4. Subject Line Analyzer: This helps improve the thing that decides whether people open the email. It scores subject lines across clarity, engagement, emotional appeal, and technical factors, then gives recommendations and alternatives.

5. Substack Notes Generator: This takes an existing newsletter post and turns it into multiple Note angles. The goal is not to create random content. The goal is to make it easier to share the thing you already wrote in a way that can reach new readers.

6. LinkedIn Post Generator: This turns a newsletter post into several LinkedIn-ready versions, including thought leadership, story-driven, tactical listicle, contrarian take, and engagement hook formats. Repurposing is one of those things everyone knows they should do, but it often feels like another writing task. This makes it more mechanical.

7. About Page Generator: Your About page is often where a new reader decides whether your newsletter is for them. This tool uses your brand profile and lets you choose a framework, like mission-driven, story-driven, credibility-driven, or conversion-driven.

8. Welcome Email Generator: The welcome email is one of the first real moments a reader has with your newsletter. This tool creates a welcome email based on your brand voice and a framework like personal story, authority welcome, quick win, or community builder.

9. SEO Optimizer: This focuses on the SEO basics you can actually edit in Substack: title, description, slug, keyword placement, heading structure, and image alt text. If you add a target keyword, it can also look at competitor results and suggest content gaps or keyword opportunities.

I am careful with SEO because I do not want newsletter writing to become search-engine-shaped writing. Discoverability still matters, though. So the goal is practical: improve the pieces you can edit without turning the post into something lifeless.

Who This Is For

This is the part I want to be clear about.

Newsletter Compass is not for first-time writers who want AI to write their first post.

If you have never written before, there is no real archive for the tool to learn from. There is no clear voice to analyze yet. There are no patterns in your topics, audience, or positioning. At that stage, the better move is probably to write more and build a small body of work first.

Newsletter Compass becomes more useful once you already have some writing behind you.

• It is for the creator who has been publishing for a while and wants to grow further or faster.

• It is for the person who writes the newsletter, then avoids the promotion layer because turning the post into Notes or LinkedIn posts feels like extra homework.

• It is for the writer who knows the About page and welcome email matter, but keeps postponing them because they feel like mechanical setup tasks.

That distinction is important to me.

Newsletter Compass is not trying to replace the writer. It is software for the growth layer around the writing.

The taste still has to come from you.

The archive still has to come from you.

The point of view still has to come from you.

Newsletter Compass helps you use those things better.

Why I Am Sharing This With You

I am sharing this here because AI Maker is the reason the product exists. Writing this newsletter taught me where the friction actually lives: choosing the idea, naming the post, sending the email, sharing the post, welcoming new readers, and keeping your voice consistent across all of it.

That whole chain is the work.

For a long time, I treated each part as a separate task. Now I think the better version is a connected growth system around the newsletter. A system that remembers enough about your work to help you move through the repeated parts with less friction.

That is what I am trying to build with Newsletter Compass.

It is early. Some features are already useful. Some still need more testing. Some parts will probably change after more creators use it and tell me what feels clunky. I am okay with that. I would rather build this with people who are in the weekly reality of newsletter creation than polish it quietly and guess what matters.

If You Want To Try It

You can try Newsletter Compass here:

Get FREE 7-Day Trial Newsletter Compass

There is a 7-day free trial, and plans start at $20/month or $120/year after the trial.

If you try it, I would genuinely love feedback. What worked? What felt clunky? What did you expect it to do that it does not do yet? What would make it useful enough to become part of your weekly growth process?

You can use the contact form in the footer of the site. Right now that feedback is more useful than almost anything else.

I am still building this in public. I am saying this is the most direct version of what I keep writing about in AI Maker: build systems around the work you actually do. Newsletter Compass is my attempt to do that for newsletter creators who are already writing and want the rest of the growth work to feel less scattered.

Best,
Wyndo

P.S. You do not have to buy anything to be helpful. Even trying the free trial and telling me, “this part confused me,” or “I expected this feature to work differently,” would genuinely help.

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.

I’ve written about Claude Code a few times now, and each post came from a different stage of my own learning curve.

The first big one was my complete Claude Code guide. That post was mostly about showing what Claude Code can actually do: read files, run commands, work with MCPs, use Skills, create agents, manage projects, and turn one folder into something closer to a personal AI operating system.

That post did well because it answered the first question most people had: why should I care about Claude Code at all?

Once people saw what was possible, the next question showed up almost immediately.

How do I actually set this up for myself?

That was the blank folder problem. You open Claude Code, point it at a project, and suddenly you have to decide what goes inside the folder:

• What goes in CLAUDE.md?

• Which files should Claude read first?

• What should become a command?

• What should become an agent?

• How do you build enough structure without creating some overcomplicated setup you never use?

So I wrote the blank folder setup guide. That post moved from “here is what Claude Code can do” to “here is how to give it a useful project to work inside.”

But after using this kind of setup every day, I ran into the next problem: the setup worked, then it plateaued.

The next ceiling after running your first Claude Code setup

At first, the improvement was obvious. Claude knew where my newsletter drafts lived. It knew my LinkedIn posts had a different style than my long-form essays. It knew I had free versus paid rules. It knew I cared about voice, not just clean writing.

That alone made the output much better. But after a few weeks, the same little problems kept coming back:

1. Drafts got close, but still sounded a little too polished.

2. I kept correcting the same voice issues in different sessions.

3. Repurposing sessions blurred together, so LinkedIn, Notes, and Twitter started sounding like versions of the same essay.

4. Research and drafting sessions carried too much of the wrong context into each other.

5. Claude could create a draft, but I was still the quality gate every time.

That was frustrating because I had already done the setup work. I had CLAUDE.md. I had rules. I had commands. I had agents.

So I did what I usually do when something feels almost right: I tried to make the instruction files better. I added more rules, made the wording stricter, and explained the voice more clearly.

That helped a little, but it did not fix the deeper issue. The starter setup gave Claude instructions. What I needed next was a system around those instructions.

That system is what I mean by agent harness.

What agent harness means in plain English

Agent harness sounds more technical than it needs to. The simple version: it is everything around the model that decides what it remembers, what it checks, which task gets which context, and who reviews the output.

For my newsletter work, that means:

1. Repeated corrections should stick across sessions.

2. Mechanical style checks should run even when Claude forgets.

3. Different writing jobs should not bleed into each other.

4. A draft should get reviewed before I spend my attention on it.

That last part is the big shift. Most people stop once Claude can create the first version. But the first version is only the first layer.

If you care about quality, voice, and repeatability, the better question is: what happens after Claude writes the first version?

Does the system remember what went wrong last time? Does it check for obvious violations? Does it keep each task in its own lane? Does another agent review the output before you do?

That is the level I wish I had built earlier.

What this makes possible

My newsletter repo is the clearest example because this is where the harness has to do more than generate text.

1. Drafting paid posts without losing the voice

When I draft a paid post, Claude does not just read one generic instruction file and start writing. It needs to know the newsletter voice, the free versus paid boundary, the topic history, the reader survey, and the repeated corrections I have made over time. If the draft starts sounding too polished, I want that caught. If I mention metrics without caveats, I want that flagged. If a paid post has strategy but not enough implementation, I want the system to notice before I do.

That is where memory and hooks matter. Memory keeps the repeated corrections from disappearing between sessions. Hooks catch the obvious violations that Claude might forget when the task gets complex.

2. Repurposing one newsletter without blending every platform

When I repurpose a finished newsletter, the problem is different. One command can run three agents in parallel: one turns the newsletter into LinkedIn, one turns it into a Twitter thread, and one extracts Substack Notes. But those agents cannot all think the same way. LinkedIn needs a rawer, sharper cadence. Notes need short, but inspiring thinking. Twitter needs one tight thread arc instead of a compressed version of the whole essay.

That is where agent is important. Each platform gets its own context instead of one long conversation where every format starts sounding the same.

Then there is the review layer. A draft agent can create the first version, but another agent should check whether it sounds like me. Another can check whether the paid boundary is clear. Another can flag weak claims, missing caveats, or sections that feel too abstract.

That is the evaluation loop. Claude is not only generating the work. It is helping inspect the work before I spend my own attention on it.

3. Turning scattered notes into a weekly review I can trust

The same pattern shows up in project management. My /weekly-review command does not just ask Claude to summarize my Obsidian notes. It pulls decisions from the week, checks annual goals, compares quarterly priorities against the current sprint, drafts next week’s plan, then runs a review pass before I use it.

The harness matters because each part has a different job. Memory keeps my planning rules alive: do not create too many priorities, separate decisions from ideas, and flag anything with clear action and deadline. Hooks can catch missing dates, empty next steps, or tasks with no project. The command coordinates the inputs. A reviewer pass asks whether the plan actually matches the goals or whether Claude ranked something confidently for the wrong reason.

That review used to take around an hour on Sunday. Now it takes a few minutes, with the caveat that I still sanity check the priorities myself. But the starting point is much better because Claude is not only summarizing notes. It is checking the plan against the rules that matter.

None of this came from one magical prompt. It came from four layers I skipped at the beginning.

Subscribe now

What you will be able to build

By the end of this post, you should be able to take a normal Claude Code project and turn it into a more reliable working system.

Not perfect. Not fully autonomous. But meaningfully better than a folder with instructions.

You will have a way to:

1. Turn repeated corrections into memory, so Claude stops making the same mistakes across sessions.

2. Add mechanical checks with hooks, so predictable issues get caught while the work is happening.

3. Connect agents with one command, so multi-step workflows stop depending on you as the operator.

4. Add evaluation loops, so outputs get reviewed, repaired, and checked again before they reach your final judgment.

The examples are built around my newsletter workflow because that is where I have the clearest scar tissue. But the pattern applies beyond writing.

If you use Claude Code for research, product work, project management, coding, or content operations, the same problem shows up eventually: Claude knows enough to help, but not enough to reliably manage the process around the work.

That is where the harness begins.

Layer 1: Memory that turns corrections into system rules

Here is what made memory click for me: not every instruction I put in CLAUDE.md changed Claude’s behavior reliably.

I had rules in there like no em dashes, no contrived rhetorical patterns, and no generic AI endings. Claude would follow them sometimes. Then the same mistake would come back in another draft.

At first I thought the rule just needed stronger wording. So I made the instruction clearer. Then stricter. Then more detailed.

That helped a little, but it did not fully solve the problem.

The bigger shift happened when I started turning repeated corrections into memory. When a mistake kept showing up during real work, I saved the correction there instead of only rewriting the project rules.

That changed the feel of the system. Claude did not stop making every mistake forever, but it repeated fewer of the same ones. The correction started carrying across sessions in a way that felt more durable.

That is when I realized CLAUDE.md and memory are not the same tool.

CLAUDE.md is for stable project rules:

1. What the project is.

2. Where files live.

3. What voice rules apply everywhere.

4. What the main workflows are.

Memory is for the corrections you only discover after Claude has worked with you for a while:

1. “When a LinkedIn post ends by restating the thesis, replace the recap with a sharper final punch or a direct question.”

2. “When reviewing voice, compare against recent daily LinkedIn posts before suggesting rewrites. Do not judge from the generic brand rules alone.”

3. “If a newsletter draft sounds too polished, look for the missing messy part: what failed, what I changed, or what I am still unsure about.”

4. “When a paid post explains the strategy but skips the setup details, flag the missing blueprint pieces: steps, templates, failure modes, and checks.”

Those are not abstract principles. They are bruises. They come from moments where the setup almost worked, but missed something important.

That is why memory is powerful.

There are two ways I create memories

The manual way is simple. Whenever I notice friction during the work, I ask Claude to save the correction into memory.

The second way is auto memory. Claude Code can notice corrections during the conversation and save them automatically.

That does not mean I blindly trust whatever gets saved.

Every so often, I open /memory, look at what Claude stored, and clean it up. Some memories need sharper wording. Some are temporary and should be deleted. Some are useful, but belong in a different file.

That’s why this review process is important. You need to be detailed here and make sure every memory serves its purpose, does not contradict the others, and is supported by really specific instructions.

Where Claude Code stores memory

One thing that confused me at first: this memory folder does not live inside your project by default.

Claude Code stores project memory in its own project-specific folder. For this newsletter, mine lives here:

/Users/wyndomb/.claude/projects/-Users-wyndomb-Downloads-AI-Maker-Newsletter/memory/

The long folder name comes from the project path. If your project is somewhere else, your folder name will be different. The easiest way to find it is to open:

~/.claude/projects/

Then look for the folder that matches your project path. In my case, /Users/wyndomb/Downloads/AI Maker Newsletter becomes:

-Users-wyndomb-Downloads-AI-Maker-Newsletter

Inside that memory/ folder, Claude keeps the memory index and the individual memory files.

The four memory types

I would not treat memory as one big bucket. There are four types of memory. They matters because it tells Claude how stable the information is and how to apply it:

Read more

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.

There will be more of these, but I want to be honest about this first one because I am still figuring out the format.

One of the things I want to offer paid members this year is more access to how I think through real questions in real time. The polished tutorials and finished frameworks in my regular newsletter posts are still useful, but I also want to share more of the messy middle where someone asks a question, I share what I am currently seeing, and we use that as a way to uncover what is actually useful.

This first session was mostly Q&A. I answered submitted questions, shared my screen, walked through parts of my AI stack, and talked through decisions that usually stay behind the scenes.

Future sessions might look different. They could become live demos, tool reviews, workflow teardowns, or sessions where I review what members are building.

I am treating this first session as a starting point and a way to gather feedback on what actually helps you learn and apply AI.

And to be honest, I already like this Q&A session.

The questions pushed me into places I do not always cover in a normal newsletter post. How I think about making money in AI. What is inside my current AI stack. How I maintain my own CLAUDE.md file when using Claude Code. Why I think prompt libraries are useful, but limited. What I would tell someone trying to grow on Substack without depending on one giant master prompt.

But if I had to boil it down to a single most important thing for this month’s session, it would be the idea of building your own context management with an AI agent. AI is already so good at understanding intent; what it doesn’t have is everything related to your work, how you think, and the constraints you operate under.

That realization came from the questions paid members asked:

1. Hema’s question about Substack growth pointed to the need for better audience and positioning files.

2. Tom’s question about Claude Skills pointed to the workflows Claude should remember.

3. James’s question about CLAUDE.md pointed to the instruction file that keeps evolving as your work changes.

4. Raj’s question about starting a new project pointed to the folders and source material you need before AI can help well.

5. Simon brought the business side into the same conversation.

6. And Ben asked about my current AI stack, where I showed all the AI tools I’m currently subscribed to.

So the direction is less about finding the perfect prompt and more about building the context files around your work.

That might mean a small folder of past work. It might mean a file that explains your audience. It might mean a simple instruction file that tells Claude how you make decisions. It might mean turning one repeatable process into a Skill so you do not have to remember the steps every time.

I hope you can learn even more from the questions other members are asking and adapt those insights to your own situation.

At the end, I also included a short survey because I want your feedback on what this monthly member format should become.

Now, let’s dive into each of the questions here

Subscribe now

Hema: What should a master prompt for Substack growth include?

This month’s session started with Hema’s question about a master prompt for Substack growth.

The context matters here.

Hema is a coach building across Instagram, LinkedIn, and Substack. She wants to understand what kind of content lands with her audience, and eventually she wants to add a paywall.

So the surface-level question was about a master prompt.

But the deeper question was really about how to help AI understand her business well enough to give useful content advice.

My first instinct was to show the prompt side of it. I have a paid post on turning Claude into your brain’s most valuable co-worker, and that post includes a master prompt people can adapt.

But as I talked through the answer live, I kept coming back to the part that matters more now:

The prompt is only the steering wheel. The files are the engine. But this doesn’t mean that prompt is no longer important. I still use prompts. I still think a clear prompt matters.

But if your entire AI setup depends on one giant prompt, the model has to relearn your world every time you ask for help.

That becomes fragile fast.

So for Hema, I would not start by trying to perfect one master prompt for Substack growth. I would start by building a small folder of source material that tells Claude what is true about her work.

For a coach building across multiple platforms, I would create a few simple files:

Read more

A few months ago, I built a Claude skill that turns newsletter posts into LinkedIn carousels. I wrote about the whole process here, and the honest truth is that it worked. For the first time, I could make carousels without opening Canva or spending an hour fixing tiny alignment issues.

That mattered because I had avoided carousels for months. They always felt like one of those content formats I knew I should use, but never wanted to touch because the effort-to-output ratio felt broken. The old skill changed that. Claude could:

1. Read my newsletter or raw idea.

2. Break the content into a hook, body slides, and CTA.

3. Generate HTML and CSS using my brand config.

4. Run a script that embedded my profile photo and exported slide images.

This was a good architecture for version one. HTML is predictable, Claude is good at writing it, and the output is reproducible. If I used the same brand config, I could generate slides that felt consistent every time.

But every time I uploaded one, I had this small, uncomfortable feeling: this is useful, but it still does not look as good as I want.

The old workflow helped me stay more consistent, but it capped the design. The slides all started to share the same rhythm: big headline, body text, footer, dots. The exports were technically 1080x1350, but they looked softer after LinkedIn compressed them. And if one slide felt slightly off, I couldn’t open it like a normal design file and fix it. I had to prompt Claude again and hope it got closer to what I wanted the next time, and this is definitely not a reliable way to work.

That was the part that bothered me most.

A lot of design quality comes from tiny human edits: moving a headline two pixels left, giving one word more weight, tightening the spacing, or adding more breathing room. These are not always prompt problems. Sometimes they are taste problems.

And taste is much easier to apply when you can touch the design directly.

So I built a new Claude skill that does the job really well, and it ended up performing strongly on my LinkedIn account, especially considering I have 6,000 followers.

One of the biggest improvements in my new LinkedIn carousel skill is that it takes me from idea to an editable output, with design that is 10x better. You really notice the difference when you actually feel it.

The reframe that changed the workflow

I realized I was giving Claude the wrong final job. I was asking it to write the carousel, design the carousel, and produce the final pixels. That worked, but it trapped the result inside a flat image.

The better process is:

1. Let Claude handle the content structure.

2. Let Claude apply the brand rules.

3. Let Claude build the first version of the design.

4. Let a real design canvas render the final output.

5. Let me manually polish anything that still feels off.

That is where Paper Design comes in. Paper is a design tool that feels closer to Figma than Canva, but its MCP (Model Context Protocol) changes the workflow. Paper Desktop runs a local MCP server, and tools like Claude Code or Codex can read and write to the open design file.

To put it simply, Claude Code can create and edit designs directly inside Paper. Instead of asking Claude to generate a finished HTML file and export flat images, I can ask Claude Code to create 1080x1350 artboards inside Paper. Each slide still uses my saved brand details and carousel structure, but the visual style comes from the template I choose. The output lives on a canvas with editable layers.

The first time I ran it, I watched the slides appear one by one inside Paper, then clicked into a slide and moved a headline myself. That was the moment the workflow clicked for me. With the old skill, every small imperfection became another prompt. With Paper, every small imperfection became a small edit.

Why Paper Design instead of Figma

This is the comparison I had to take seriously because Figma is the obvious default answer. If you ask any designer where an editable carousel should live, most of them will probably say Figma. I understand why. Figma is mature, collaborative, and excellent for product design systems.

Figma’s MCP is also much stronger than I first assumed. Its use_figma tool can create and edit native Figma objects like frames, components, variants, variables, styles, text, and auto layout. If I were building product screens from an existing design system, Figma would probably be the better tool because the agent can reuse components, variables, and libraries that already exist.

But a LinkedIn carousel is a different job. I do not need Claude to search a component library and instantiate the right button variant. I need it to create strong editorial layouts, preserve my profile photo, use my brand font, keep footer alignment stable across slides, and let me polish the final design myself.

That is where Paper fits better. Paper describes itself as a real HTML and CSS canvas, and its MCP exposes tools that map almost directly to carousel production: create_artboard, write_html, duplicate_nodes, set_text_content, update_styles, get_screenshot, get_font_family_info, and get_fill_image.

That matters because Claude is already good at HTML and CSS. Paper keeps that same strength, but changes the destination. Instead of HTML becoming a flat image, HTML becomes the way Claude writes editable design objects onto the canvas.

So the workflow is simple: create a 1080x1350 artboard, write the slide into Paper, duplicate the artboard, swap the text, update styles, screenshot the result, and export at 2x. That feels close to how I would build a carousel manually, just faster.

Figma can write to canvas too, but it has more friction for this specific use case right now. Figma’s own docs currently list no asset image support yet, no custom font support yet, a 20kb output response limit per call, and Full seat requirements for agent write access. For a carousel that depends on my profile photo, custom typography, and quick visual iteration, those details matter.

That is my actual reason for choosing Paper. Figma is probably the more powerful tool overall. Paper is better aligned with the job I need done: turn my writing into editable, polished carousel slides without making me manage a full product design system.

And yes, this might change fast. Figma is moving quickly, Paper is moving quickly, and agent-to-canvas design is still early. But I do not write these Lab posts for some imaginary perfect future. I write them around what I can build and use right now.

Subscribe now

What to know before building

This workflow is better, but it is not an instant process. You need to install Paper Desktop, connect the MCP server to Claude Code, and run the skill from a folder where Claude can access your saved brand setup and profile photo.

There is also a cost to consider. As I am writing this, Paper’s free plan includes 100 MCP tool calls per week. That is enough to test the workflow, but probably not enough if you want to make this part of your regular content process.

Paper Pro is currently listed at $20 per user/month, or $16 per user/month with yearly billing. For me, that price makes sense because Paper is not only useful for LinkedIn carousels. You can use the same agent-to-canvas setup for landing pages, lead magnets, Instagram carousels, visual explainers, and other design assets that need both speed and editability.

I do not think everyone needs another monthly tool. But if Paper helps you create several reusable assets each month, the cost starts to feel reasonable compared with the time you would spend fighting design tools, prompting around tiny layout issues, or rebuilding the same visuals from scratch.

One more thing to keep in mind, sometimes Claude creates a slide that is visually close but not quite right. The heading might be too large, the accent shape might feel random, or a body slide might need tighter spacing. The difference is that these problems no longer kill the workflow. They become normal design edits.

That is the trade I am making. The old skill was faster. The new skill has a higher ceiling. For me, that is worth it.

What you get in the Lab

The goal is simple: take one strong idea from your newsletter, turn it into a carousel that looks good enough to publish, then still have full control to polish it like a real design file.

That is the outcome I wanted from the beginning. Not another AI image generator. Not another rigid template. A system where Claude gets me to a strong first draft, Paper keeps everything editable, and I can use my own taste to finish the last few details.

The other thing I added to the shareable skill is templates. The current version comes with 9 carousel templates, so you are not locked into one visual rhythm. You can use brutalist-mono for a manifesto, data-card for a stat-forward post, terminal-readme for a technical workflow, or sticky-notes for a warmer essay-style carousel.

I also included the publishing layer in the walkthrough. After the carousel is exported, I show how I use Typefully’s agent skill so Claude Code can generate the LinkedIn caption, attach the carousel file, and schedule the post.

That part requires a Typefully account, either a paid plan or their 14-day trial. But I wanted to include it because it changes the shape of the system. The workflow does not stop at “here are some nice slides.” It can go all the way from idea to editable carousel to scheduled LinkedIn post.

Inside the Lab, you get:

1. The /paper-linkedin-carousel skill I built for this workflow.

2. 9 ready-to-use carousel templates, each with its own palette and layout style.

3. Video walkthroughs showing the setup, first run, manual edits, and export flow.

4. The Paper MCP setup process for Claude Code.

5. A one-time brand setup for name, publication, positioning, profile photo, and default template.

6. Editable 1080x1350 Paper artboards instead of flat HTML exports.

7. A 2x export process for sharper LinkedIn and Instagram uploads.

8. A manual polish loop so you can fix the final details yourself.

9. A Typefully scheduling flow for turning the finished carousel into a drafted or scheduled LinkedIn post

This is not for someone who posts one carousel every few months. The old HTML skill might be enough for that. This is for you who want their ideas to travel farther on LinkedIn and Instagram without spending every post fighting layout, compression, and tiny design fixes.

Step 1: Install Paper Desktop

Download Paper Desktop from Paper’s site:

https://paper.design/downloads

Quick note: Paper MCP can work across multiple AI agents, including Claude Code CLI, Claude Code Desktop, Codex, and Cursor. In this walkthrough, I am using Claude Code CLI so the setup stays focused. If you use another agent, the Paper MCP idea is the same, but the connection screen will look different.

Open the app and create a new file. Paper’s MCP server runs locally through the desktop app, so the app needs to be open while Claude Code is working with the design.

If Claude Code cannot see Paper later, restart both Paper Desktop and Claude Code before debugging anything else.

Step 2: Connect Paper MCP to Claude Code

Follow these two steps to install Paper MCP.

First, you need to add custom marketplace:

/plugin marketplace add paper-design/agent-plugins

Then install the plugin:

/plugin install paper-desktop@paper

Just ask Claude Code to do this and you’ll be done in no time.

After installing, run:

/mcp

You should see the Paper MCP server in the available MCP list.

But later on, you’ll likely run into a problem where Claude can’t access the Paper app, even though you have it open. In these cases, open /MCP again and reconnect it to Paper Design. That’s it.

To test the connection, ask Claude Code:

“Create a red rectangle in Paper.”

If everything is connected, Paper should ask for permission and then create the shape on the canvas.

Do this tiny test before trying the carousel skill.

It saves you from debugging the wrong layer.

Step 3: Install the Paper carousel skill

Read more

I have a bias when it comes to AI agents.

I like control. Give me Claude Code, a few markdown files, MCP connections, and a clear folder structure, and I feel at home. If an agent breaks, I want to see where it broke. If the output feels off, I want to edit the prompt, change the model, tighten the instructions, and run it again.

But that bias has a blind spot.

Most people do not want to maintain AI agents like tiny software projects. They want to send a message, attach a few files, and get useful work back. They want the agent to remember enough context to be helpful inside the same thread. They want it to run again tomorrow without setting up cron jobs, servers, or configuration files.

I think this is where AI is heading right now.

Why AI Agents Are Moving Into Chat

We are moving from “build an AI agent” to “build an agentic workspace.” The agent is no longer just a chatbot or a script sitting in one app. It is becoming a layer that can reach across Google Workspace, Notion, your email, your files, your analytics, your content calendar, and whatever else you already use to run your life or business.

And if that layer is going to become useful for normal people, it cannot only live in a terminal.

It has to be available where people already communicate. Telegram. WhatsApp. Slack. Maybe email.

That is why Manus is interesting to me.

Claude Code and OpenClaw are powerful, but they ask you to think like a builder. Manus, Perplexity Computer, and Notion AI agent point in a different direction. They ask you to think like an operator. Tell the system what you want, connect the tools it needs, and let it handle the messy middle.

I do not think one direction replaces the other. I think both will exist.

Some people will want the control layer. Some people will want the chat layer. Most of us will probably use both depending on the job.

That is why I asked Dheeraj to test Manus.

writes GenAI Unplugged, where he documents practical AI systems for solopreneurs, creators, and small business owners. His thing is the unglamorous but useful part of AI: what breaks after the demo, how to connect tools, how to turn Claude Code, n8n, MCP servers, agents, prompts, and templates into systems that actually run.

Previously, he also wrote about how you can repurpose your newsletter content using n8n, which I think you should check out.

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

If you are new to his work, I’d start with these three:

1. How to Set Up MCP Servers and Hooks in Claude Code

2. I Built a 3-Agent Content Team in Claude Code

3. I Spent 2 Weeks Reverse-Engineering Substack’s API. Now Claude Runs My Analytics.

That made him the right person for this Manus test.

He already had a strong Claude Code benchmark. He had built research agents, SEO agents, competitive analyzers, and content systems with actual business context behind them. So I wanted him to pressure test Manus from the perspective that matters most to AI Maker readers: can this actually help a creator build repeatable systems, or is it just another shiny AI tool that looks good in a demo?

What follows is his full breakdown. The setup, the credit costs, the Telegram flow, the scheduling, the weak spots, and the honest comparison against Claude Code.

Over to Dheeraj.

Hello 👋🏻

I’ve been building AI agents in Claude Code for months. Research agents, SEO agents, competitive analyzers. All markdown files with YAML frontmatter, MCP tool connections, and business context profiles.

So when Wyndo suggested I test Manus for our comparison, I had a clear benchmark: my research agent that I built in 27 minutes using Claude Code. Could Manus match it? Beat it? And at what cost?

Here’s what happened when I spent a full day testing Manus, building two agents from scratch, and pushing the free tier to its limits.

🚨 A quick note from sponsor…

Most AI tools help you brainstorm. Atoms helps you build and grow. Turn ideas into real, usable products faster with AI, then get traffic and real customers with built-in SEO and Ads agents. A workflow designed for builders and founders who want to ship, not just chat.

Start building with Atoms

Setting Up: 2 Minutes to “Connected”

Manus gives you 1,300 free credits to start. 1,000 one-time bonus plus 300 daily refresh credits that reset at midnight. No credit card required.

The setup is straightforward. You go to manus.im, sign up, and you’re in. But here’s where it gets interesting.

The real Manus isn’t the web app. It’s Telegram.

The Agent page has a QR code. You scan it with your phone, open Telegram, tap “Start,” click “Link Account,” confirm in the browser, and you’re connected. 208,000+ monthly users already on this bot.

Total time: about 2 minutes. And here’s the thing that blew me away.

Zero technical work. No bot creation (like Claude Code’s BotFather flow). No token generation. No config files. No webhook setup. No Docker containers (like OpenClaw). I scanned a QR code and it worked.

Compare that to what it takes to set up a Claude Code agent:

1. Install Claude Code CLI

2. Configure MCP servers (Perplexity, Firecrawl)

3. Create folder structure

4. Write business context files

5. Write the agent definition in markdown with YAML frontmatter

6. Test and debug

Claude Code’s setup takes 30 minutes if you follow my article. Manus takes 2. The trade-off? Claude Code gives you full control. Manus gives you full simplicity.

The Calibration Run: When “Keep It Brief” Costs 123 Credits

Before building any agents, I ran a simple test to understand credit costs.

Prompt:

Search the web for the top 3 AI agent tools released in 2026 so far.
For each, give me: name, what it does, launch date, pricing.
Keep it brief.

I used Manus 1.6 Lite (the free tier default). Three minutes later, I had my results.

Here’s what surprised me: Manus didn’t just give me a text summary. It generated an interactive webpage with radar charts comparing the three tools, a pricing bar chart, and formatted cards for each tool.

Impressive? Yes. But I asked for “brief.” This is Manus’s personality: it over-delivers on format, even when you explicitly ask it not to. For a simple “search and summarize” task, it spent 123 credits and built a full research report with interactive visualizations.

That’s roughly 10% of my starting credits. For something I could have asked any chatbot to do in 30 seconds.

First lesson: Manus doesn’t do “simple.” Every task gets the full treatment, whether you want it or not.

Subscribe now

Agent #1: The SEO Research Agent

Now for the real test. I wanted to build an SEO research agent, the same kind of thing I built in Claude Code using my content researcher agent.

How Claude Code Does It

In Claude Code, building an SEO agent means:

1. Create 3 business context files (business identity, content strategy, competitor watchlist)

2. Write the agent definition in .claude/agents/content-researcher.md with YAML frontmatter specifying tools and model

3. Run it with /research 95 (where 95 is your post ID)

It takes 27 minutes the first time, 45 seconds per run after that. You get structured JSON output. You control everything: the model, the tools, the output format, the system prompt.

How Manus Does It

In Manus, I did this:

1. Opened Telegram (already connected from setup)

2. Sent 3 files directly in the chat (the same business-context.md, content-strategy.md, and competitor-watchlist.md I use in Claude Code)

3. Sent a prompt telling Manus what to do with those files

That’s it. No YAML. No folder structure. No tool configuration. Just files and a message in a chat app.

Here’s the prompt I sent:

You are an SEO research agent for the blog "Discover With Dheeraj."

I have uploaded 3 context files:
1. business-context.md - Our blog identity, mission, what we cover
2. content-strategy.md - Content pillars, brand voice, keyword approach
3. competitor-watchlist.md - Direct competitors and adjacent players

Please do the following in two parts:

Part 1 - SEO Knowledge Base
Read all 3 files and create a structured SEO knowledge base document.
Include: business identity, target audience, brand voice rules,
competitor analysis, content pillars, and E-E-A-T advantages.

Part 2 - Keyword Research & Content Brief for "Manali to Leh Road Trip 2026"
Using the knowledge base, research this topic and deliver:
- Top 10 keyword opportunities with volume/competition/intent
- Top 5 competitor articles currently ranking (with URLs and word counts)
- Content gaps and underrepresented subtopics
- "People Also Ask" questions for AEO
- 3 recommended article titles matching our brand voice
- Suggested H2 structure (6-8 sections)

Manus acknowledged the files, read them, and got to work. I could watch it thinking in the web app while the task ran in the background on Telegram.

The Results: Two Professional PDFs

Five minutes later, two PDFs landed in my Telegram chat.

PDF 1: SEO Knowledge Base (5 pages)

Manus synthesized all three context files into a clean reference document. It correctly extracted:

• Blog identity (14+ years, 562 posts, Indian Himalayan travel)

• Both target avatars (first-time road tripper and returning adventure traveler)

• Brand voice rules, including local terms like dhaba, chai, maggi, rajma chawal

• Competitor table with strengths and weaknesses for Vargis Khan, Devil On Wheels, Thrillophilia, and IndiaHikes

• Content pillars with correct percentages (Route Guides 40%, How-To 25%, Road Status 15%)

• E-E-A-T advantages (17+ years first-hand experience, 562-post archive)

It even had numbered citations referencing each source file: [1] business-context.md, [2] content-strategy.md, [3] competitor-watchlist.md.

PDF 2: SEO Keyword Research & Content Brief (6 pages)

This is where it got genuinely useful:

• 10 keyword opportunities with volume estimates, competition levels, and search intent

• 5 competitor articles analyzed with real URLs, word counts, and specific angle analysis (e.g., Thrillophilia described as “commercial tour booking disguised as a guide”)

• Content gaps identified: EV charging availability, Zojila/Shinku La tunnel construction updates, Atal Tunnel traffic patterns, 2026 online permit process

• 8 People Also Ask questions mapped for AEO optimization

• 3 article titles matching the brand voice (”Manali to Leh Road Trip 2026: The Honest, Budget-Friendly Guide (From 15 Years of Driving It)”)

• 7-section H2 structure with content direction per section

• 9 cited references including competitor URLs and external sources

Cost: 148 credits. Time: 5 minutes.

Quality Assessment: 4 out of 5

The context files made all the difference. Without them, this would have been generic SEO advice. With them, Manus produced competitor-aware, brand-voice-aligned research that a content creator could act on immediately.

The main weakness: keyword volume data uses estimated ranges (High/Medium/Low) instead of actual numbers. Manus doesn’t have access to Google Keyword Planner or Ahrefs, so the volume ratings are LLM-estimated. For serious SEO work, you’d want hard data. But for planning a content calendar? This is more than enough.

The Memory Test: “Do You Remember My Files?”

After the SEO agent delivered, I wanted to test something. Our research said Manus has no persistent memory across tasks. Each task starts from zero.

So I typed, in the same Telegram thread:

Wait, can you do another SEO research for me on the topic of 
Lahaul Valley travel guide based on my knowledge base you have?

No files re-uploaded. No context repeated. Just a casual question.

Manus replied: “On it! I’ll run the same style of SEO keyword research and content brief for ‘Lahaul Valley travel guide’ using your existing knowledge base.”

Five minutes later, another PDF arrived. And it was better than the first one.

The Lahaul Valley brief:

• Referenced all 4 competitors by name (Vargis Khan, Devil On Wheels, Thrillophilia, TripAdvisor)

• Analyzed Discover With Dheeraj’s own existing article as a competitor, noting it “needs continuous updating for 2026 specifics”

• Used brand voice terms throughout (dhaba, rajma chawal, maggi)

• Included a Practical Info Box template (the exact format from our content strategy)

• Named specific restaurants: Snow View Restaurant in Jispa for Thukpa, Legendz Kitchen & Coffee House

• Added content gaps the first brief didn’t catch: winter travel via Atal Tunnel, Jio/Airtel 4G coverage expansion, Miyar Valley offbeat villages

Cost: 125 credits. Quality: 4.5 out of 5.

The finding: Manus retains file context within a Telegram conversation thread. Upload files once, and every subsequent request in that same thread can reference them. The thread IS the agent’s memory.

This changes the agent pattern completely. A single Telegram thread becomes your agent workspace. Upload your context files once at the start, then run as many tasks as you want against them. Each run is cheaper and faster because the context is already loaded.

Share

Agent #2: The Daily AI News Brief

For the second agent, I tested something completely different: pure web research with no context files, plus scheduling.

Prompt:

You are my Daily AI News Brief agent.

Every morning, scan these 5 AI news sources:
1. The Batch (deeplearning.ai)
2. Import AI (Jack Clark's newsletter)
3. Ben's Bites
4. TLDR AI
5. Superhuman Newsletter

Summarize the top 5 stories from today. For each story include:
- Headline (keep it short)
- One paragraph summary (3-4 sentences max)
- One-line "why it matters" for content creators and knowledge workers

Format as a clean briefing document. Number the stories 1-5.

At the end, add a "Content Opportunity" section: pick the 1 story 
that has the most potential for a newsletter post or YouTube video, 
and explain why in 2 sentences.

Three minutes later, a PDF with 5 stories arrived. Stories about Claude Mythos (Anthropic’s vulnerability-finding model), AI cyberwar capabilities, startup AI adoption data, OpenAI’s $100 Pro plan, and Alibaba’s Happy Horse text-to-video model.

Cost: 89 credits. But the quality was lower than the SEO agent: 3 out of 5.

Why? Only 2 of the 5 requested newsletters were clearly cited (Ben’s Bites and Import AI). No evidence it actually scanned The Batch, TLDR AI, or Superhuman specifically. The “why it matters” lines were generic. And there were no URLs in the references.

This confirms a pattern: context files are what make Manus agents valuable. The SEO agent (with files) scored 4/5. The news brief (no files) scored 3/5. Without grounding context, Manus output is competent but not differentiated from any LLM with web access.

The Scheduling Magic

Here’s where Manus pulled ahead of everything else I’ve tested.

After the news brief ran successfully, I typed:

Schedule this to run every morning at 7am. 
Deliver the briefing here in Telegram.

Manus replied: “I’ll set that up now. You’ll get your AI News Brief delivered here every morning at 7am.”

That’s it. No cron syntax. No n8n workflow builder. No GitHub Actions YAML. No server to maintain. I asked in plain English and it scheduled an autonomous, recurring agent.

Cost to set up the schedule: 12 credits.

And the next morning, at 7am, a fresh news briefing landed in my Telegram. Five new stories (MirrorCode benchmark, Google DeepMind’s attack taxonomy, AI lobbying spend). Different from yesterday. The agent actually re-scanned sources.

This is the single biggest differentiator. Claude Code can’t do this. No coding-focused AI tool offers recurring, autonomous task execution delivered to your messaging app. Manus can schedule an agent to work while you sleep and deliver results to your Telegram when you wake up.

The Full Credit Ledger

Here’s every credit I spent across two days of testing:

• Starting balance

  • Credits Used: -

  • Running Total: 1,300

• Calibration (simple web search)

  • Credits Used: 123

  • Running Total: 1,177

• SEO Agent (Manali-Leh brief)

  • Credits Used: 148

  • Running Total: ~1,029

• News Brief (manual run)

  • Credits Used: 89

  • Running Total: ~940

• Schedule setup

  • Credits Used: 12

  • Running Total: 849

• Lahaul Valley SEO (memory test)

  • Credits Used: 125

  • Running Total: 724

• Daily refresh (Day 2)

  • Credits Used: +300

  • Running Total: 1,024

• Scheduled news brief (auto)

  • Credits Used: 125

  • Running Total: 899

Total consumed: 701 credits across 6 tasks + 1 scheduled run.

The daily refresh of 300 credits is key. At 125 credits per run, the free tier’s daily refresh covers one automated task per day with room to spare. You don’t need to pay anything for a single daily agent.

But the moment you want two agents running, or a complex multi-step workflow, the free tier gets tight fast.

Manus Pricing: What Does It Actually Cost?

• Monthly credits

  • Free: 1,000 (one-time)

  • $20/month: 4,000

  • $40/month (7-day free trial): 8,000

  • $200/month: 40,000

• Daily refresh

  • Free: 300

  • $20/month: 300

  • $40/month (7-day free trial): 300

  • $200/month: 300

• Concurrent tasks

  • Free: 1

  • $20/month: 20

  • $40/month (7-day free trial): 20

  • $200/month: 20

• Scheduled tasks

  • Free: 1

  • $20/month: 20

  • $40/month (7-day free trial): 20

  • $200/month: 20

• Research depth

  • Free: Basic

  • $20/month: Everyday

  • $40/month (7-day free trial): Self-set usage

  • $200/month: Large-scale

Key pricing insight: Monthly credits do NOT roll over. Use them or lose them. But add-on credit packs don’t expire.

Based on my testing, here’s what different workflows actually cost:

• Simple web search: ~123 credits (you’d get ~32 per month on free tier daily refresh alone)

• SEO research with context files: 125-148 credits (~2 per day on daily refresh)

• Daily news brief: 89-125 credits (~2-3 per day on daily refresh)

• One agent scheduled daily: Sustainable on free tier (300 daily refresh covers 125/run)

• Two agents daily: Needs $20/month tier

Manus vs. Claude Code: The Honest Comparison

I built functionally similar agents on both platforms. Here’s how they compare.

Setup Time

• Initial platform setup

  • Claude Code: 30 min (CLI + MCP servers)

  • Manus: 2 min (QR code + Telegram)

• Business context files

  • Claude Code: 15 min (create 3 markdown files)

  • Manus: 0 min (same files, just upload in chat)

• Agent definition

  • Claude Code: 17 min (write YAML + system prompt)

  • Manus: 0 min (describe what you want in plain English)

• First test run

  • Claude Code: 5 min

  • Manus: 5 min

• Total first agent

  • Claude Code: ~67 min

  • Manus: ~7 min

• Subsequent agents

  • Claude Code: 20 min each

  • Manus: 2 min each (same thread, files retained)

Manus wins on speed. By a lot. But that speed comes with a trade-off.

Control

• Model selection

  • Claude Code: Full control (Sonnet, Opus, Haiku)

  • Manus: Lite on free; paid can pick 1.6/Max (4-8x credit cost)

• Tool access

  • Claude Code: Configure any MCP server

  • Manus: Pre-built connectors only

• Output format

  • Claude Code: You define it (JSON, markdown, etc.)

  • Manus: Manus decides (usually PDF)

• System prompt

  • Claude Code: You write every word

  • Manus: Implicit from your prompt

• Error handling

  • Claude Code: You define retry logic

  • Manus: Black box

• Local file access

  • Claude Code: Full filesystem

  • Manus: Desktop app only (with approval per command)

• Scheduling

  • Claude Code: Not available

  • Manus: Built-in, natural language

• Cost transparency

  • Claude Code: You see API costs in real-time

  • Manus: No preview. Find out after the task runs.

Claude Code gives you full control. Manus gives you zero control but makes it so easy you might not care.

Output Quality

• SEO research with context

  • Claude Code: 4.5/5 (structured JSON, competitor gaps, angles)

  • Manus: 4/5 (professional PDF, competitor analysis, cited sources)

• Research without context

  • Claude Code: 3/5 (depends on prompt quality)

  • Manus: 3/5 (competent but generic)

• Keyword data accuracy

  • Claude Code: Real data via Perplexity + Firecrawl scraping

  • Manus: Estimated ranges (High/Medium/Low), no source

• Competitor analysis

  • Claude Code: Scrapes actual pages, extracts word counts

  • Manus: Finds URLs and estimates, may not scrape

• Source citations

  • Claude Code: Full URLs from Perplexity

  • Manus: Mixed (some cited, some missing)

Cost Comparison

• Platform cost

  • Claude Code: $20/month (Claude Pro)

  • Manus: Free tier available

• Per-research cost

  • Claude Code: ~$0.05-0.15 (API tokens)

  • Manus: 125-148 credits (~$0.75-0.90 on $20 plan)

• 30 research runs/month

  • Claude Code: ~$3-5 in API costs

  • Manus: 3,750-4,440 credits (needs $20+ plan)

• Daily scheduled agent

  • Claude Code: Not possible

  • Manus: Free tier covers it

• MCP tools

  • Claude Code: Perplexity free tier + Firecrawl free tier

  • Manus: Built into credit cost

• Total monthly (light use)

  • Claude Code: ~$20-25

  • Manus: $0 (free tier) to $20

• Total monthly (heavy use)

  • Claude Code: ~$20-30

  • Manus: $40-200

For light use (a few research tasks per week), Manus free tier wins. For heavy use (daily research, multiple agents), Claude Code is more cost-effective because API tokens are cheaper than Manus credits.

What Manus Gets Right

1. The Telegram integration is the best AI agent onboarding I’ve seen.

QR code. Tap. Confirm. Done. No bots to create, no tokens to copy, no config files. Compare to Claude Code Channels (BotFather, token, CLAUDE.md, permissions) or OpenClaw (Docker, API keys, webhooks). Manus is consumer-grade simplicity.

2. File-based context in chat threads is brilliant.

Upload your business context files once in a Telegram thread. Every subsequent task in that thread uses them. No folder structure. No file paths. Just drag and drop into a chat. This is the most accessible way to give an AI agent “memory” I’ve tested.

3. Natural language scheduling is a killer feature.

“Schedule this every morning at 7am.” Done. No cron, no n8n, no infrastructure. This alone justifies testing Manus if you need recurring automated tasks.

4. PDF output is polished and professional.

Every output came as a well-formatted PDF with headers, tables, citations, and clean typography. If you’re delivering research to clients or team members, this matters.

5. The abstraction is the product.

Both agents worked within the same Telegram conversation. Behind the scenes, Manus handled model selection, tool orchestration, web scraping, PDF generation, and file delivery. I didn’t configure any of it. The complexity is hidden, and that’s the point.

Subscribe now

What Manus Gets Wrong

1. No cost preview. Ever.

You find out what a task costs after it runs. My “keep it brief” calibration task cost 123 credits. My SEO research cost 148. There’s no way to estimate before committing. This is the biggest friction point for anyone on a budget.

2. Limited model control.

Free tier locks you to Manus 1.6 Lite. Paid tiers unlock 1.6 and 1.6 Max, and you CAN select your preferred model when creating tasks. You can even set a default model per scheduled task under Settings > Scheduled Tasks > Advanced Settings. But the Max model costs 4-8x more credits than standard. So “model control” really means “pay more credits for better output.” Claude Code lets you specify Sonnet, Opus, or Haiku per agent with no additional cost beyond the API tokens.

3. Credit system is opaque.

Credits don’t map to any intuitive unit. Is 125 credits a lot? A little? Without knowing what a “credit” translates to in compute terms, it’s impossible to plan. Monthly credits don’t roll over, which creates a use-it-or-lose-it pressure.

4. Source reliability is inconsistent.

The SEO agent cited 9 sources with real URLs. The news brief cited only 3 sources for 5 stories. You can’t verify what Manus actually scanned vs. what it inferred. For content that needs fact-checking, this is a problem.

5. The “overkill” tendency wastes credits.

When I asked for “brief,” I got interactive charts. When I asked for keyword research, I got a 6-page PDF with a Practical Info Box template. Manus doesn’t do minimal. Every task gets the deluxe treatment, and you pay for it in credits whether you wanted it or not.

6. No version control or iteration.

In Claude Code, my agent definition lives in a markdown file I can edit, version, and share. In Manus, the “agent” is just a conversation thread. If I want to tweak the prompt, I start a new task and burn more credits. There’s no way to refine without paying.

The Connectors Advantage

One thing Manus has that I haven’t fully explored yet: connectors. These are OAuth integrations with external services.

Available connectors include:

• Google Drive / Workspace

• Gmail

• Firecrawl

• Meta Ads Manager

• Instagram

These are essentially built-in MCP-style tool connections. In Claude Code, you’d configure each of these as an MCP server manually. In Manus, you click “Connect” and authorize via OAuth.

The potential here is significant. Imagine an agent that reads your Google Analytics, pulls your top-performing content, identifies gaps, and delivers a content brief to Telegram every Monday. The connectors make this possible without any technical setup.

Who Should Use What?

Use Manus if:

• You’re a non-technical creator who wants AI agents without any setup

• You need recurring scheduled tasks (daily briefings, weekly reports)

• You want results delivered to Telegram/Slack without opening a terminal

• You’re OK with “good enough” output that you can’t deeply customize

• You value simplicity over control

Use Claude Code if:

• You want full control over models, tools, and output formats

• You need structured output (JSON) that feeds into other systems

• You want to iterate on agent definitions without burning credits

• You need real keyword data from Perplexity/Ahrefs, not estimates

• You’re building a content pipeline, not just running one-off research

• You’re comfortable with a terminal (or learning one)

Use both if:

• Manus for daily automated briefings delivered to Telegram

• Claude Code for deep, structured research when you need precision

My Bottom Line

I spent 576 credits building two agents and running 6 tasks. The SEO agent (with context files) genuinely impressed me. The news brief was useful but not remarkable. The scheduling feature is something nothing else in this space offers.

But here’s what stuck with me most.

In Claude Code, I spent 27 minutes building my research agent. I control every aspect of it. I can share the agent file, version it, customize the output, and run it for pennies per query. It’s a power tool.

In Manus, I spent 7 minutes. I uploaded files to a chat app and typed what I wanted. The output was professional, well-formatted, and delivered as a PDF to my phone. I controlled nothing, and it didn’t matter.

These aren’t competing products. They’re different philosophies.

Claude Code says: “Here are the building blocks. Build exactly what you need.”

Manus says: “Tell me what you want. I’ll figure out the rest.”

The agentic AI race isn’t about which platform is “better.” It’s about which abstraction level matches your workflow. And right now, Manus is the only one that lets a non-technical creator schedule an autonomous AI agent using nothing but a chat message.

That’s worth paying attention to.

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

I’ll be honest with you. My LinkedIn carousels don’t match my website.

Different accent color. Slightly off fonts. Spacing that’s close but not quite right. If you lined up my Substack, my LinkedIn, and my pitch deck side by side, you’d see three things that look related but aren’t the same.

It’s not that I didn’t notice. I noticed every time. The problem is that aligning everything takes real effort, and that effort kept losing to the next AI Maker post deadline.

Then Claude Design launched with one feature that caught my attention: upload your brand assets once and every project after that inherits them automatically. One folder and Claude knows your colors, your fonts, your components — forever.

The catch is that you still have to build that folder.

Claude Design does give you a few shortcuts. You can import directly from GitHub or Figma if you already have your design system living there. But most of us don’t have either. No Figma file. No organized codebase. That means you’re back to scaffolding everything yourself — pulling colors, exporting fonts, documenting components, putting it all into the structure Claude expects. Which is a lot of work.

And here’s what I realized: most of us do have the brand. We just don’t have it in a folder.

It’s already on your website. Your colors are there. Your fonts are loaded. Your components are in the navbar and the cards and the pricing section. You already made every brand decision when you built those pages.

So I built a Claude skill that extracts it. You run it inside Claude Cowork or Claude Code: point it at your URL, it reads what’s already there and generates the output folder. Then you take that folder and upload it into Claude Design during onboarding. From that point forward, every project you generate in Claude Design — LinkedIn carousels, pitch decks, Instagram carousels — comes back consistent with your website.

But I know some of you might be thinking after reading this: “I don’t have a website yet. Does that mean I can’t use this?”

No. The skill handles that too.

Here’s an example from when I ran the skill, and it asked me whether I have a website.

If you have a website, the skill extracts your brand from it. If you don’t, it runs an expanded interview instead. You tell it your colors (or name a few brands you admire and it pulls their palettes so you have something to react to), share some of your writing, and describe your visual preferences. Same output either way: a complete brand folder that Claude can use forever.

This skill will run for 10–20 minutes, but you only need to run it once, and it will apply to your future sessions indefinitely.

I called the skill Design System Builder. That’s what this post walks through.

What Claude Design actually does

If you haven’t tried it yet, here’s the quick version:

Claude Design is a feature inside Claude that generates visual assets from prompts. Landing pages, websites, app designs, carousels, pitch decks, slide decks, infographics. You describe what you want, Claude builds it. No Figma, no starting from scratch.

The way I think about it, Claude Design has four core features, and each one matters for a different part of the workflow:

1. A brand design system

This is the piece we’re talking about in this post. You give Claude your brand once and everything it generates inherits it.

2. Clean export to PDF, PPTX, and Canva

Claude is already strong at coding, so you can have it build anything in HTML first and then convert into whatever format you need. A PDF for a client, a PPTX for a sponsor deck, or a Canva file you want to tweak by hand. The format stops being a constraint.

And you can also hand off to Claude Code to start building and make it live.

3. A built-in questionnaire

Before Claude generates anything, whether it’s a pitch deck, a LinkedIn carousel, or a website layout, it asks you a batch of questions first. Who’s the audience, what’s the goal, what tone, what length. You answer once and the output comes back way more aligned than if you just typed a one-line prompt.

4. Tweak Mode

Once Claude generates a design, you can ask it to enter Tweak Mode. From there you can experiment with different color palettes, gradients, or visual styles without starting over. Select the element you want to adjust and see the change right away. It turns the output into something you can iterate on visually, not just through prompts.

That third one is easy to miss, but it’s the feature that made me stop fighting with prompts. Instead of rewriting the same brief five times, I answer six questions and let Claude drive.

It’s still in research preview, so the output quality isn’t always perfect. But the direction is clear, and it’s already useful for a lot of what I ship. I’ve hit the weekly usage limit already :)

Here’s where it falls short, though. Claude Design does have a basic brand extraction. You point it at your URL and it pulls some colors, copy, and font names. But it misses the stuff that actually matters for consistency. How your gradients work. What your spacing rhythm looks like. Your voice. Your logo variants. The hard rules that keep everything tight.

You get something close. Not something accurate.

That’s the gap the skill closes.

Subscribe now

What the skill actually builds

Before getting into how it works, it helps to know what you’re getting out of it.

The output is a folder. Not a PDF brand guide. A folder of files that Claude can read and act on directly.

At the center is one file called brand.json. Think of it as the single source of truth for your entire brand. Your exact hex colors, your fonts, your spacing, your gradient rules, your voice patterns. Everything in one place. Every other file in the folder pulls from it. If you want to change your accent color six months from now, you update one line in brand.json and it updates everywhere else automatically.

Around that file, the skill generates templates for LinkedIn carousels, Instagram carousels, slide decks, reports, and email. It also generates hard rules that Claude follows as constraints, not suggestions. Not “the site uses dark colors.” Instead: “Background is always #0D0D0D.” Not “usually use Inter.” Instead: “Always use Inter, never any other font.” That specificity is what makes the output actually consistent.

And it’s not just visual rules. The folder also carries your voice. Headline length. Tone. Phrases you actually use. Phrases to avoid. A design system without copy rules produces work that looks right but sounds wrong. This one carries both.

When this folder is in Claude’s context, every design it generates respects all of it. Same colors. Same fonts. Same voice. Without you mentioning any of it.

Here’s the part I like most. The folder also installs as its own Claude Skill. So the next time you want a LinkedIn carousel, you just invoke /{your-brand}-design, describe what you need, and it comes back on-brand.

Here’s a recent LinkedIn carousel I created by extracting my brand from my consulting website:

That’s the meta-skill part. The design-system-builder skill runs once on your website and produces a brand-specific skill that lives in your skills folder permanently. One extraction. Every future session knows who you are.

How it builds your brand (two paths)

The skill starts with one question: “Do you have a live website that represents your brand?”

Your answer determines which path it takes. Both paths produce the same output folder.

Path A: You have a website

The skill extracts your brand in two separate ways, because visual tokens and copy require completely different tools.

Track 1: Visuals via Claude for Chrome

This track captures everything you can see: hex colors as actually rendered on the page, font families and weights, gradients, border radii, shadows, spacing rhythm, logo at real resolution. For this to work accurately, the page needs to be rendered in a real browser. Claude for Chrome handles this. You run the skill in Claude CoWork, it invokes Claude for Chrome, and runs the visual extraction prompt. The skill provides that prompt verbatim; all you need to do is paste it in and run it.

Make sure you’ve installed Claude for Chrome in your browser and that you’re logged in to your Claude account.

Track 2: Copy via Tavily or WebFetch

This track captures your written brand: homepage headlines, body paragraphs, tagline, positioning, named concepts, proof numerals. Plain text that doesn’t need a browser to extract accurately. The skill runs this track in-session automatically using Tavily. You don’t need to do anything for Track 2.

Both tracks run in parallel and merge into one brand.json. While you’re opening Chrome for Track 1, the skill is already pulling your copy in the background. By the time you paste the visual results back, Track 2 is done and everything gets combined into a single source of truth.

After extraction, the skill asks 6-8 short questions about things your site can’t reveal on its own: phrases to avoid, emoji policy, gradient rules, which format you ship most often. You answer once, and the manifest is complete.

Path B: You don’t have a website

I have a feeling that many of my readers don’t have a website yet. Maybe they’re just starting out. Maybe their brand lives in their head and in their social posts, but not on a domain yet.

Instead of extracting, the skill interviews you. It runs in three stages:

Stage 1: Identity

Your brand name, positioning, who you’re for, what makes you different.

Stage 2: Visual identity

This is where it gets interesting. Instead of asking you for hex codes (most people don’t think in hex codes), the skill asks you to name 2-3 brands you admire visually. It pulls those brands’ palettes using Tavily and presents them side by side. “Here’s what I found. What resonates? What doesn’t?” Your reactions build the palette. “I like that one’s darkness but the other one’s accent color” gives the skill a concrete starting point that’s way better than guessing.

You also describe your preferences: dark or light canvas, sharp corners or rounded, serif or sans-serif, gradient or no gradient.

Stage 3: Voice and rules

You share 3 headlines from your own writing (newsletter, social posts, emails, anything) and a paragraph or two. The skill analyzes your patterns and builds voice rules from them. Then the standard questions: banned phrases, emoji policy, proof numeral style, priority format.

The whole interview takes about 15 minutes. After that, the skill has enough to fill the same brand.json manifest and scaffold the same folder. The output is identical. A brand built from interview is not a lesser brand. If anything, it forces you to be more intentional about choices that website creators sometimes make by accident.

The principles that make this work

To be honest, I didn’t get all of these right the first time. Most of them got added after the skill produced something that looked correct but then fell apart in the next session. These are the rules that stuck after testing:

1. Be specific, not vague. This is the biggest one. If you tell Claude “usually use Inter for headings,” it forgets within a few sessions. If you tell Claude “always use Inter for headings, never use any other font,” it sticks. The skill builds these kinds of hard rules into every brand folder it generates. No “usually.” No “try to.” Just clear yes-or-no instructions that Claude can follow every time.

2. Voice matters as much as visuals. I had an early version that nailed the colors and fonts but completely ignored how I write. The carousels looked like my brand but sounded like someone else. A brand system has to carry both. How your headlines sound, what phrases you avoid, your tone. Otherwise you get visually correct work in the wrong voice.

3. Fill everything with real content. No “[INSERT HEADLINE HERE]” placeholders anywhere. Every slot in every template gets filled with your actual words during setup. I learned this one the hard way: if you leave placeholder text in the templates, Claude keeps producing placeholder-style output in future sessions. It picks up the pattern.

4. Keep fonts local. The skill downloads your font files and stores them inside the folder instead of loading them from the internet every time. External font sources can fail without warning, and then your whole design breaks silently. Local copies just work.

5. One file controls everything. All your brand decisions live in a single file called brand.json. Every template in the folder pulls from that one file. If you want to change your accent color six months from now, you change it in one place and it updates everywhere. Without this, you’d be hunting through dozens of files to find every place a color was hardcoded.

6. Each format gets its own layout. A LinkedIn carousel is 1080x1350 portrait. An Instagram carousel is 1080x1080 square. A pitch deck is 1920x1080 landscape. These are completely different shapes, and they need completely different layouts. The skill builds each one from scratch instead of shrinking a landscape slide to fit a portrait frame. That shortcut is what produces those awkward carousels with too much empty space in the middle.

These six rules are what separate a brand folder that works once from one that holds up over months of use. I learned most of them by watching the output break and figuring out why.

That said, there are real limitations here. I’d rather you know them going in than discover them halfway through.

Honest limitations

• Claude for Chrome is the one step you can’t skip. I listed it in the prerequisites for a reason. Without it, the skill falls back to text-based guessing and you lose the whole point of accurate extraction.

• You’ll probably need to provide some assets yourself. The skill pulls what it can from your website, but if your logo isn’t on the page, or you have a wordmark or icon variant that only lives on your hard drive, Claude can’t find it. You’ll need to drop those files into the assets folder manually after the skill runs. Same goes for any brand elements that aren’t publicly visible on your site.

• This isn’t a one-shot process. I want to be transparent about that. The skill does a lot of the heavy lifting, but expect to go back and forth with Claude a few times. Maybe the colors are right but the voice rules need adjusting. Maybe the carousel layout needs another pass. You’re having a conversation with Claude until the output matches what you want. Think of it more like a working session than a magic button.

• Sites with inconsistent design produce inconsistent extractions. If your brand has drifted over time and your homepage doesn’t match your about page, the skill will pick up on that inconsistency. Review brand.json after extraction and clean up anything that looks off before you upload.

• Claude Design is still in research preview, as I mentioned. Output quality varies by complexity. Simple carousels and decks come out well. More complex layouts can be hit or miss.

• The brand kit is a snapshot. If you redesign your site later, you’ll want to re-run the skill to pick up the changes.

• I’m still refining this. I’ve re-run the skill on my own site twice already to improve what the portrait carousel layout produces. It keeps getting better, but I’m not going to pretend it’s perfect yet.

None of these are dealbreakers. They’re just the honest reality of where the skill is right now. I’d rather ship something that works with known rough edges than wait for perfect.

How the skill runs (four phases)

Read more