I get why. That is where most of us started.

You open ChatGPT, Claude, Gemini, or whatever tool you like. You ask a better question, add more background, paste in a few examples, and try to explain what good output looks like.

Sometimes it works really well.

But then the next chat starts from zero again.

You re-explain the project, re-upload the files, paste the same rules, correct the same mistakes, move the output into Google Docs, Notion, email, Substack, Slack, or wherever the real work happens.

At some point, the problem is no longer the prompt.

The problem is that the AI has no real connection with your work.

That was the main idea I tried to show in a past session with the Cozora Community. I walked through how I run AI Maker from inside Claude Code, including my newsletter folder, my project structure, my CLAUDE.md, my skills, my slash commands, my memory rules, and the way I use agents to help with research, writing, planning, and operations.

This was a live tour of the system I actually use, and now I’m sharing it with you.

When people hear “Claude Code,” they often assume this is for programmers. Margaret, one of the people in the session, asked the obvious question right away:

“So is Claude Code like about coding?”

That is the question most normal people have.

And the answer is: it started there, but that is not where it ends.

Claude Code is useful because it lets an AI agent work inside a real project folder. It can read files, follow rules, create outputs, run repeatable workflows, store a large amount of information, use tools, remember corrections through files and instructions, and help you move from “answer this question” to “help me run this part of my work.”

That is a different relationship with AI.

Subscribe now

The Shift I Was Trying To Show

For the last few years, most AI work has looked like chat.

You are the middleman.

You ask a question, get an answer, copy the answer, paste it somewhere else, open another app, bring back more context, ask again. Then you rinse and repeat.

That is still useful. I still use normal chat sometimes, especially on mobile.

But for my day-to-day work, the center of gravity has moved.

My newsletter now lives in a folder Claude Code can read, including the drafts, archive, writing rules, audience notes, paid-versus-free rules, and performance data.

So when I ask for new post ideas, Claude does not have to guess from the prompt alone. It can inspect the actual project, read the files that matter, see what I have already published, and follow the rules I wrote for the newsletter.

That’s the transformation you can expect when you go full AI‑agent mode.

💡 Quick note: This is also the shift and I are teaching in Agentic Academy for Knowledge Work.

AI chat has a ceiling. You re-explain the project, re-upload the files, repeat the same corrections. Agentic Academy is 10 live weeks where you build one AI system that runs your real work. No coding. Starts June 22. Enroll now.

Learn more about Agentic Academy

Watch’s Inside of The Video

This replay is a walkthrough of the system behind my newsletter and project management setup.

I would not watch it like a normal webinar where you try to remember every tool name. I would watch it with one question in mind:

What would my first agent folder need to understand about my work?

That is the useful lens.

Because the specific tools will change. But the underlying pattern is going to matter for a while:

1. Give the agent a folder.

2. Put the right source material inside.

3. Write the rules it should follow.

4. Create repeatable workflows.

5. Add guardrails.

6. Improve the setup every time the agent gets something wrong.

That is the pattern I kept coming back to during the session.

What We Covered

The session started with a question from Julia about managing multiple systems together.

She was already deep in the work, cleaning up a bunch of Claude projects, trying to build a better master project, and thinking through how memory and project status could work across different kinds of work.

That was useful because it surfaced one of the real problems with AI agents:

They can do a lot, but they can also do too much.

Julia mentioned that Claude Code can sometimes “go nuts” and do far more than she asked for. I have felt that too. Sometimes the agent understands the intent and runs with it in a useful way. Sometimes it does a long chain of work and gives you something that is technically impressive but not what you wanted.

That is why the folder matters.

You need a place where the agent can learn:

1. What this project is

2. What counts as good work

3. Which files matter for which tasks

4. What actions are allowed

5. What mistakes it should not repeat

6. When it should ask before moving

That is the job of the system around the agent.

In my setup, the most important file is CLAUDE.md.

I described it in the session as the brain of the project. It is the file Claude reads first. It tells Claude what the project is, what folders exist, what rules matter, what reference files to use, and what standards to follow.

For AI Maker, that means Claude knows things like:

1. Newsletter drafts live in one place.

2. LinkedIn posts have a different style than newsletter posts.

3. Paid posts need implementation detail.

4. Free posts should be complete on their own.

5. My writing should avoid polished corporate language.

6. If a task involves audience data, it should read the audience files first.

The more I use it, the more I think most people should start with the file that teaches the agent how to understand the project. The complicated automation can come later.

The Six Pieces I Walked Through

During the replay, I broke Claude Code into six pieces.

You do not need all of them on day one. I definitely did not build all of this at once.

But once you see the pieces, the whole thing feels less mysterious.

1. CLAUDE.md

This is the main instruction file for the project.

It tells the agent:

Read more

A few weeks ago, I had a business question sitting in my head that I kept circling:

“How do I grow revenue over the next six months without making the business heavier?”

That sounds like a simple question until you actually have to answer it.

The easy AI version is to paste the question into one chat and ask for a plan. I did that too. The answer was reasonable. It gave me a few options, named the upside, mentioned some risks, and made every path sound possible.

That was the problem.

When every option sounds reasonable, I don’t actually feel closer to a decision; I just end up with a cleaner-looking version of something I’m still unsure about.

Around the same time, I asked my paid readers what they wanted me to write next. One reader asked if they could build an AI advisory board for business decisions. Something that could help them understand risk, spot opportunities, and decide what to do next.

I liked the question because I already had a rough version of that.

Whenever I have a business idea I’m not sure about, I run it through my AI board. I still make the final decision, but the board helps because I make better choices when the question gets pulled apart from a few different directions before I choose.

These are some of the questions I often ask:

1. How do I improve my paid subscriber rate by 50% over the next six months with a limited budget?

2. How do I increase revenue without adding a lot of new cost or recurring work?

3. If I want to grow, what should I build from the assets I already have?

The revenue question is the one that stuck with me.

Because one of the board’s recommendations was to build a cohort.

That is basically what I have been building.

💡 A quick note from me…

AI chat has a ceiling. You re-explain the project, re-upload the files, repeat the same corrections. Agentic Academy is 10 live weeks where you build one AI system that runs your real work. No coding. Starts June 22. Enroll now.

Learn more about Agentic Academy

I do not want to overstate this. The board did not magically invent the cohort for me. The idea was already floating around, and there were still a lot of human decisions after that.

But the board helped me see why the cohort fit better than a few other options:

• The CEO lens liked it because it built from the audience and trust I already had.

• The CFO lens liked that it could create meaningful revenue without requiring a large ad budget.

• The operator lens pushed back because live delivery could become heavy if I designed it badly.

• The critic asked whether I was building a real business asset or just creating another weekly obligation for myself.

That last question was important to think about deeply.

Because I work mostly alone, a good revenue idea cannot only look good on paper. It has to fit the way I actually work. It has to build from what I already have: my subscribers, my writing, my paid archive, my agent-building skill, and the problems readers already ask me about.

That is where a normal AI answer often breaks for me.

If I ask a generic chat how to grow revenue, it might suggest ads, more products, sales calls, partnerships, posts, and more everything.

Some of that advice might be useful. But a lot of it ignores the actual shape of my business.

The Problem With One Polished Answer

Most people use AI for business decisions by asking one general chat for advice.

I do this too.

You paste in the question, add a little background, and ask something like, “What should I do?”

The answer usually sounds helpful. It names the upside and the risk, and it gives you a plan. Sometimes it even says, “Here is the balanced recommendation.”

But one chat is trying to be the strategist, finance person, technical person, operator, and skeptical reviewer at the same time.

The roles start blending together.

The finance view drifts into brand strategy. The operator creates a plan before the tradeoff is clear. The critic gives generic warnings. The final answer feels complete, but it may never force the decision through the lens that actually matters.

How To Give Each AI Advisor A Specific Job

The useful shift was giving each advisor a specific job.

For the revenue question, instead of hearing five different voices telling me to chase growth at all costs, I needed each lens to ask a different kind of question:

1. CEO: Which bet compounds from the audience I already have?

2. CFO: What is the upside, and what cash or time does it risk?

3. CTO: What needs to be tracked before this becomes guesswork?

4. Operator: What is the smallest first-week version?

5. Critic: What assumption would make this whole plan wrong?

That is the board model.

If the CEO and CFO both give the same broad strategy advice, the board fails. If the critic only says “be careful,” the board fails. If the operator starts making a 90-day plan before the decision is clear, the board fails.

Each role needs a job.

The CEO helps choose the bet. The CFO makes the cost and risk visible. The CTO checks whether the idea can be built or tracked without becoming fragile. The operator turns the decision into a real sequence. The critic finds the assumption I am most likely to skip.

Then I decide.

The board supports judgment. It does not replace it.

Subscribe now

Why Context Matters More Than The Persona

After running this a few times, my honest take is that the AI advisor can work.

You can make the model act like a CEO, CFO, CTO, operator, or critic. That part is relatively easy.

The harder part is giving those advisors enough real context to judge anything well.

Without that, the board becomes five polished generic answers. The CEO gives business-school strategy. The CFO talks about margins with no actual numbers. The operator proposes work that assumes a team you do not have. The critic warns about risk without knowing which risks actually matter to your business.

This is where context changes everything.

For AI Maker, that means the board knows things like:

1. I mostly work alone.

2. My business runs through the newsletter, paid posts, consulting, and occasional digital products.

3. My strongest asset is the audience I already have.

4. I care about personal brand, content systems, agent builds, and practical AI workflows.

5. I do not want growth that breaks trust with readers.

Those facts give each advisor something to push against.

The advice becomes more conditional and more useful.

It can say: this idea fits because it builds from the audience you already have. Or, this might work financially because it does not require a large upfront ad budget.

That is very different from a generic growth plan.

It helps me make better decisions based on my current business conditions and priorities. That’s the most important part.

When I Would Use This

I would use this for any decision where the answer sounds simple until you have to live with it.

For example:

1. Should I launch this product now or wait?

2. Should I change pricing?

3. Should I spend money on ads?

4. Should I hire help or stay solo?

5. Should I build a new offer from scratch or use the audience and skills I already have?

The board will not make the decision easy. Trust me, you will still need to make hard decisions after the agent analysis. But at least it can make the decision cleaner so you understand the real trade-offs and what you can expect from each decision you make.

That is what I wanted from it.

What This Gives You

If you build this for your own work, you can turn hard decisions easier to process.

You give the agent enough business context to understand your situation. You define the criteria that matter before the advice starts. You ask separate advisors to look at the same decision from different angles. Then you turn the result into a saved decision log, so the reasoning does not disappear three days later.

That is the productivity gain I care about here.

By the end, you should have a board that can help you:

1. Understand the business context behind the decision.

2. Make the decision criteria explicit before the answer arrives.

3. Separate strategy, money, feasibility, execution, and risk.

4. Pressure-test the recommendation against your real constraints.

5. Save the decision record so you can review it later.

6. Turn a messy business question into a cleaner next step.

What We Are Building: AI Advisory Board

The thing we are building is a small decision system. It starts with one messy business question.

Something like:

How do I grow revenue over the next six months without making the business heavier?

Then it turns that question into a process.

First, the board creates a decision intake. This is where the vague question becomes more specific: what decision are we actually making, what options are on the table, what constraints matter, what evidence do we have, and what would make the decision wrong?

Then the board sends that same decision to separate advisors.

The CEO looks at direction and focus. The CFO looks at money, risk, and upside. The CTO looks at feasibility and tracking. The operator looks at sequence and capacity. The critic comes in after the first round and asks what everyone might be missing.

After that, the chair pulls the views together, completes a scorecard, and saves the decision log.

The flow looks like this:

1. Question in

2. Decision intake created

3. CEO, CFO, CTO, and operator review the decision separately

4. Critic reviews the first four memos

5. Chair synthesizes the board

6. Scorecard completed

7. Decision log saved

8. Next actions listed

If you run this often enough, it becomes a useful habit: one place to think through hard decisions, one process for separating the angles, and one saved record you can review instead of rebuilding the same context every time.

Now, let’s dive in.

1. The Project Files

Same as my other agent guides, we are building this in a local computer folder that you can use within your Claude Code setup.

Here is the folder we are going to build.

Do not worry if this looks like a lot at first. We will have an interview process that can help you fill all these files easily.

But the whole structure is doing a simple job:

1. context/ tells the board what your business is.

2. criteria/ tells the board how to judge the decision.

3. templates/ gives the board a consistent shape for intake, review, and logging.

4. .claude/agents/ holds the advisor instructions.

5. .claude/commands/ gives you one command to run the whole process.

6. decisions/ and runs/ save what happened so the decision does not disappear.

Read more

Lately, I’ve been thinking less about which AI model is “best” and more about what the AI is connected to.

I wrote an in-depth post about it yesterday:

That sounds like a small shift, but it changes the whole conversation.

A better model can help you write, summarize, or reason a little better. But a better connection can change what the AI can actually do with your real work.

• Can it read the right notes?

• Can it pull from the tools you already use?

• Can it help with the messy middle of the project instead of only responding to whatever you paste into the chat box?

That is why I was interested when the Cozora team put together their Q2 report, The Connector Edition.

Cozora is an AI creator community I’m part of, and one of the things I like about their approach is that they focus on people showing how they actually use AI in their work. Not just the clean theory version. The real setup. The parts that are useful, weird, opinionated, and sometimes still unfinished.

For this report, they asked seven creators a simple question:

“What is the single connector, MCP, CLI, or API, that quietly changed how you work?”

The answers turned into a 17-page report covering many of the tools these creators use in their main AI stacks.

The useful part, at least to me, is that the report does not pretend there is one perfect setup.

Some people are using simple connectors.

Some are building their own MCPs.

One person pushes back on the MCP hype and explains why a hybrid setup makes more sense for them.

That is the part I like.

Because this is where I think a lot of AI advice gets too clean. It talks about the “future of work” when the real question is much smaller:

“What do you need your AI to be able to reach?”

For most people, the answer probably is not “everything.”

• It might be your notes

• It might be your research

• It might be one database

Or, it might be your newsletter archive, client docs, sales calls, saved examples, or the project files you keep explaining over and over again.

📘 The Connector Edition: Q2 2026

The report is available at the link below👇

Read more

Most of what I write here goes deep on one thing.

One workflow, one system, one way of using AI that I have actually tested and can walk you through step by step. This post is different, and I held off on writing it for a while because of that.

What I wanted to share is the set of tools I use to build and grow AI Maker. The problem is that almost every “AI tools I use” post reads the same way. Ten apps, a line of hype on each, a promise that they will change how you work. You read it, you nod, and you have forgotten all of it by the next morning. I did not want to add another one of those to the pile.

But, in my experience, what makes a tools post worth reading is everything the list leaves out:

• How the person actually uses each tool

• Why they picked it over the alternatives

• How they decide whether it earns a place at all

So here is the deal for this one. I will show you the tools I use to run the newsletter, a real example of how I use each, and the reason it stuck. Underneath all of it is the framework I use to decide whether a tool fits the way I work.

My hope is not that you copy my stack. It is that you can see the decision-making, and walk away with a few new possibilities to explore in your own workflow.

The harder part of all this, by the way, was never finding tools. It was deciding where each one belongs.

Because when I’m building and growing my newsletter, the job is not just writing. There’s idea capture, research, drafting, visual packaging, social repurposing, guest prep, reader replies, weekly trend watching, and the pile of messy notes that might turn into something later. The problem is that each of these steps lives in a different app—Notion, Granola, Google Docs/Slides, Slack, Gmail, etc. This makes the real work harder, because I spend my energy moving between tools instead of moving the work forward.

So I stopped asking which AI tools are best and started asking a more useful question: which tools can my agent reach, so I am not the one carrying the work between apps?

The loop looks simple from the outside:

1. A rough idea becomes a note.

2. A note becomes a researched angle.

3. The angle becomes a newsletter.

4. The newsletter becomes a thumbnail, an infographic, or a carousel.

5. The carousel becomes a LinkedIn post.

6. The post gets scheduled.

7. Then reader replies, client conversations, and the newsletters I read turn into source material for the next round.

And I want all this work to run seamlessly without me being the bottleneck, so my agent can handle it for me. That’s the friction I’m trying to remove.

So the real question is not just whether a tool is good. It is whether the tool can become part of the agent flow, so the work keeps moving without me carrying every piece by hand.

Subscribe now

How I decide whether a tool gets in

Before I walk through the actual tools, I want to explain the filter I use.

Every tool in my setup has to answer three questions:

1. What part of the work does this make easier?

For me, the work is not just writing. It is capturing ideas, researching angles, drafting, turning drafts into visuals, sharing them, scheduling them, replying to readers, and noticing what should become the next post.

So before I keep a tool, I ask where it helps that loop move.

• Does it help me find better source material?

• Does it turn something private into something shareable?

• Does it help me package an idea visually?

• Does it help a finished piece get out the door?

If I cannot point to a real step in the work, I probably do not need it yet.

2. What judgment do I still want to keep?

This is where the filter gets more personal.

Some tools are useful because they take repeated work off my plate. Others are useful because they give me a better place to make decisions.

For research, scheduling, and moving files around, I usually want less friction.

For visuals, learning, and raw ideas, I still want to stay close to the work. I want to choose the direction, fix the awkward part, and decide whether the result actually feels right.

That is the line I try not to cross. I do not want tools that remove me from the work. I want tools that remove the repeated friction around it.

3. Should this tool be connected to my agent, or kept separate?

This is the last question, not the first.

If a tool helps move work from one step to another, I usually want my agent to reach it using MCP and CLI. That way I do not have to keep opening apps just to move the same piece of work forward.

If a tool helps me think, learn, or make creative decisions, I am more willing to keep it separate.

That distinction has made my setup much clearer. Some tools are part of the agent flow. Some tools are places I still go myself. Both can be useful, as long as I know why they are there.

So in the sections below, I am not going to rank the tools by how impressive they are. I am going to show you the job each one does in the newsletter loop, and why it earned its place.

🚨 A quick note from me…

I got tired of staring at a blank screen every time I sat down to write newsletter.

So I built Newsletter Compass, the AI co-pilot I wished I had when I started. It helps you to generate titles, ideas, subject lines, repurposing without making your newsletter sound like a robot wrote it. The work that used to eat my weekends now takes an afternoon.

Use Code: WELCOME for 50% Off

The center: Codex and Claude Code

The main tool in my setup is the agent I work through every day.

Both of my agents, Claude Code and Codex, know how I write the newsletter, how I write LinkedIn posts and Substack Notes, the recurring topics, the files, the rules, and the kind of answers I usually care about. So when I ask them to help with a product idea, revise a welcome email, review a why-upgrade page, or plan a post, I am not starting from a blank chat and re-explaining who I am every time.

That removed a huge amount of mental overhead.

For context, I’ve been shifting between Claude Code and Codex lately. I move between the two for planning, coding, designing, and agent work. Lately, I lean on Codex more for writing and day-to-day work, because since GPT-5.5 the app feels more complete for how I operate. It can help with files, documents, slides, sheets, visuals, and browser tasks, so more of my work can happen in one place instead of feeling like a terminal sitting off to the side.

I am still on the $20 Codex plan while also keeping Claude Max for Claude Code. That is not the cleanest setup, and I am not going to pretend I have a tidy rule for which one I open. I am still testing which fits which job.

But what I want you to take away from this isn’t which agent is better between Claude Code and Codex. It’s understanding which agent becomes far more useful when it truly understands your actual work, so every task moves you closer to your goals, faster.

One small note: I use VS Code to access Claude Code via its extension. I used to use Cursor, but it consumed my computer’s memory so quickly that I had to find a lighter alternative.

VS Code is what I use when I want to see files clearly, review changes, and edit directly.

Another alternative I’ve been using to access Claude Code from the terminal is Cmux. I use it when I want to run several agent sessions at once, let them work, and get pinged when they finish.

Because I have so many agent folders to work on, running them in Cmux lets me run multiple projects at the same time with a single interface where I can easily monitor their progress.

This opens up even more possibilities for what I can do with agents.

The connected tools

These are the tools wired into my agents so the work keeps moving without me leaving my folder. For each one, the thing worth paying attention to is the handoff it removes.

1. Tavily, for research my agent can actually use

Tavily runs web search, fetches pages, extracts content, crawls multiple pages, and maps the links on a site.

I used to lean on Perplexity, and it is still useful, but I kept hitting the same issue. Perplexity does the synthesis before my main agent ever sees the material, so by the time I get an answer I have lost the raw source my own system could have worked from with the rest of my project context.

I want fewer agents in the middle.

Tavily feels more like handing my agent research access than asking a separate assistant to make the judgment for me. The pricing fits too, since my research is uneven. Some weeks I need a lot. Most weeks I barely need any. Paying for usage suits that better than a subscription I do not fully use.

If you want to learn how to use Tavily to run research, you might want to check out my full in-depth post on building an AI agent for research below:

That is the same reason I no longer be using Firecrawl because it charged me with subscription. Good tool, but Tavily fits on-demand research better for how I work.

2. Google Workspace, for turning private work into shared work.

This might be the most useful tools in my whole setup, and it sounds boring until you feel how big friction it removes.

Most of my work starts locally as a markdown file, a brief, a research note, or a draft. That is fine when I am alone. It breaks the moment I need to share something.

When I prep a One Shot Show episode, the brief comes out as a markdown file on my laptop, and a guest cannot open a file sitting in a local folder. So I ask my agent to turn it into a Google Doc with proper headings and bullets, and now it is something I can send.

Same with Sheets and Slides.

I use Google CLI (Command Line Interface) workspace to connect my agent to Google products.

Additionally, Gmail adds another layer, since my agent can read the newsletters I subscribe to and pull out the week’s patterns, the tools worth checking, and ideas based on what keeps showing up.

Calendar makes it practical too. When I have a meeting and do not know much about the person, I can have the agent check the calendar, run Tavily on them, and hand me context before the call. I wrote about this in my post on building an AI Chief of Staff.

By giving my agent access to Google Workspace, I realized how much time I used to spend reading emails, setting up calendars for meetings, creating documents, preparing slides, and entering and analyzing data in Sheets. Now I just ask my agent to do it so I can focus more on the things that need my fullest attention.

3. Paper Design, for visuals I can still edit

I have written about building LinkedIn and Instagram carousels with Claude Code and Paper Design before.

The short version is that Paper gives my agent a place to create visual assets that stay editable afterward, and that editability is the whole reason I use it.

I used to do this in Canva by hand. Open the app, choose the format, nudge spacing, export, check, fix, export again. I am not good at design, so that process was pure friction.

Now I ask my agent to build a banner or carousel from the post I am writing. Paper generates it, and I review and make small edits where my taste actually matters.

That keeps me in the loop.

If I build a banner or LinkedIn/IG carousel using Nano Banana or GPT Image 2.0, even though it can generate beautiful designs, it feels like I’m playing Russian roulette every time.

I don’t want a tool that gives me probabilistic, high-variance output. I want something more reliable that I can count on every time, while still giving me control to tweak the final result.

4. Typefully, for moving a finished idea out the door

Typefully schedules my posts for X and LinkedIn, and the reason I like it is that it connects to the way I already work rather than becoming one more app to visit.

When a newsletter section becomes a LinkedIn post, I write it as a local markdown file, build the carousel with Paper Design, then tell Typefully to schedule the caption, the carousel, and the first comment for 6pm.

I never open the app.

Distribution is usually where good ideas get stuck. Writing the post is one thing. Getting it into the world consistently is another.

Not a promotion, but Typefully offers a CLI connection, and they also have Skill so the agent knows exactly how to publish and schedule a post, on which channels, and when it will be published.

The tools I still open myself, on purpose

This is the part most “my AI stack” posts skip.

My default preference is still to connect my agents directly to the tools I use every day. If my agent can operate a tool for me, I usually want that, because I don’t want to keep visiting different apps just to move the same work forward.

That is where I think a lot of software is going. The app still exists, but the agent does more of the operating. I describe the goal, the agent handles the steps, and I only come back in when judgment or review matters.

But there are still cases where the app itself gives me a better loop than the outside agent. Sometimes the interface makes the result easier to see, it has built-in editing tools that make the process faster, and sometimes the app has its own agent that is better suited to that specific job.

So these are not tools I keep separate because I am against connecting them. They are tools I still open because, right now, their own working environment helps me review, tweak, or navigate the work better.

1. Glif, for creative work that needs a conversation

I use Glif for One Shot Show thumbnails, newsletter thumbnails, and infographics, and I have been on it for almost ten months.

The reason it stayed is that it keeps things simple to use and I do not need a perfect prompt to start.

With a lot of image generation tools, getting started often becomes the real work. You have to know the model, the prompt style, the aspect ratio, and all the little details before anything useful happens.

Glif has a creative agent built into the chat, so I can explain what I am trying to make and the visual style I want, and it picks from different AI models based on my request. It can generate both images and videos.

I use Glif by directly accessing their website and prompting the agent. During the image generation process, I still make the final call on whether the visual fits the post. If I don’t like something, I can ask it to change the image directly. Glif also has built-in editing features that make small adjustments easier.

This is also why I stopped running Nano Banana through an MCP for this job. It can make good visuals, but Glif gives me a better refinement process inside the website. For generating thumbnails and infographics, I care less about raw model access and more about how fast I can talk my way to the right result.

When the work needs visual judgment, I want the tool that makes refinement a conversation.

2. Obsidian, for seeing the work clearly

A lot of my ideas still start in Obsidian, not as clean outlines but as messy notes.

A thought from a conversation. A reader question. Something I noticed while reading.

But Obsidian is not only a thinking app for me. It is also where I can see my files, projects, and markdown notes in a way that feels clean enough to manage.

Obsidian is super useful as part of my second brain workflow:

When I brainstorm with my agent, the result can show up in Obsidian afterward. That means I still get the agent doing the actual work, but I can review the output in a place where my projects are visible and easier to navigate.

Obsidian also has small things that matter more than they sound like they should. Markdown files look better there. It is easier to access related notes. It works as a kind of IDE for the non-code parts of my work, especially project management, drafts, and planning.

I also keep it for mobile sync, which costs around five or six dollars a month and lets me capture an idea when it shows up while I am walking or talking with a friend, then process it later when I am back at my laptop.

You could do some of this in VS Code or Cursor. I still use Obsidian because it feels better for seeing the work clearly, and ideas rarely arrive when I am ready to write them.

3. Notion, for the backlog I still want to browse

Notion used to play a much bigger role in my setup.

For a while, I used it for project management and connected it with my agents so they could update pages, move things around, and help me manage the work. Over time, that job moved to Obsidian, because Obsidian feels better for the way I now manage projects, drafts, and local notes.

But I did not drop Notion completely. I narrowed its job.

Right now, Notion is mainly where I keep my content backlog. When I want to decide what to write next, I still like opening the Notion website and seeing the topics in front of me. It gives me a clean table of ideas, statuses, and possible angles without making my local notes feel heavier.

The part I do not do manually is the preparation work around that backlog.

I use the Notion CLI through my agent to update content status, clean up tables, prepare pages, and add research or outlines to a topic page. So if I find an idea worth pursuing, I can ask my agent to research it using Tavily, create an outline inside the Notion page, and leave it there for the next writing session.

Then later, when I am ready to write, I can open Notion, see which topics are prepared, pick one, and ask my agent to expand from the outline that is already sitting there.

By doing this, I can save on the additional cost of adding another Notion AI agent, which would be $25 per month.

That is the small but important difference for me. I still visit Notion to choose from the backlog, but I do not want to maintain the backlog by hand.

4. NotebookLM, for learning before I have an opinion

NotebookLM used to be a bigger part of my system, and some of my most popular posts have been about it.

I use it more narrowly now, and that smaller job made it more useful, not less.

Tavily and my agents handle the lighter research, so NotebookLM is where I go when I need to understand something deeply before I have a take, like a dense paper, a long report, or a set of materials I have to sit with.

Anything that requires me to learn as a beginner, I’d use NotebookLM to help me with that.

But since I’ve connected the NotebookLM MCP to my agent, I sometimes use it directly from Claude Code or Codex, because the agent can run multiple queries at once instead of forcing you to ask question after question manually.

That changes the role a bit. I can give the agent the learning goal, and it can figure out what needs to be understood from the NotebookLM sources.

What I would copy from this

If there is one thing I would copy from my setup, it is not the exact list of tools.

It is the habit of giving every tool a narrow job.

For me:

• Notion holds the backlog.

• Obsidian helps me see the work.

• Tavily brings source material into my agent.

• Google Docs turns private notes into something I can share.

• Paper and glif help with visuals.

• Typefully gets finished ideas out the door.

Those tools might change. The jobs probably will not.

That was the thing I got wrong for a long time. I kept adding tools because they looked useful or cool, but I had not decided what part of the work was actually stuck. So every new tool became another tab, another place to check, another small decision I had to make later.

Now I try to start with the friction:

1. Where am I repeating myself?

2. Where am I carrying work from one place to another?

3. Where do I need a better thinking surface?

4. Where do I still want my own judgment close to the work?

That last one matters most to me.

I do not want AI tools to remove me from the newsletter. I want them to remove the repeated friction around it, so I can spend more time on the parts that actually need me: choosing the angle, noticing what feels off, deciding what is worth saying, and making the work feel like mine.

So my stack is less permanent than it probably looks from the outside.

Some tools will stay. Some will get replaced. Some will shrink into one narrow use case, like Notion did for me.

But the underlying question stays the same:

Where does this tool help the work move?

If I can answer that clearly, it probably deserves a place.

If I cannot, it is probably just another thing I am collecting.

Now, what are your favorite AI tools for getting work done?

Share them in the comments.

Best,
Wyndo

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

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

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

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

GenAI Unplugged

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

By Dheeraj Sharma

Why This Comparison Matters Now

Most AI tool comparisons push you toward a decision.

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

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

Dheeraj framed this well at the beginning of the session:

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

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

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

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

The Demo Was Really About Handoff

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

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

The useful part was the shared handoff system behind it.

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

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

1. What changed?

2. Which agent changed it?

3. Which files were touched?

4. What should the next agent know before continuing?

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

That is the actual insight for me.

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

Subscribe now

Where They Felt Different And Where They Felt The Same

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

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

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

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

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

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

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

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

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

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

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

The Handoff Became The Review Process

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

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

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

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

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

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

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

That judgment needs a few simple pieces:

1. What changed?

2. Why did it change?

3. Which files matter?

4. What is unfinished?

5. What should it be careful not to undo?

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

That was the part I found real useful.

Share

What I Would Try First

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

I would start with the smallest true version:

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

2. Add a changes.log file.

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

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

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

That is enough to feel the difference.

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

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

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

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

That is a much more useful decision.

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

Calculator Demo and Handoff File

Show Details

• Show: One Shot Show

• Season: Season 2

• Episode: Episode 5

• Topic: Claude Code and Codex handoff workflow

• Hosts: Wyndo and Dheeraj

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

Timestamp Notes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Resources Mentioned

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Figma: Mentioned as an example creative production app.

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

• Terminal: Used by Dheeraj to run Claude Code.

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

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

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

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

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

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

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

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

• Slack: Mentioned as a connector/app example.

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

• Google Calendar: Mentioned as an app connector.

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

• GitHub pull requests: Mentioned as a shared capability.

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

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

• Reddit: Mentioned by Dheeraj as a research integration.

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

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

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

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

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

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

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

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

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

• Apps: Discussed as Codex naming for integrations.

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

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

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

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

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

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

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

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

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

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

Last Friday, I shared that and I are building something new together. That post was mostly about the shift I have been feeling in my own work.

AI chat is still useful. I use it every day. But the more useful it became, the more obvious the ceiling became too.

Every new conversation still needed setup. Every project still needed the same background. Every strong prompt, example, preference, and correction still had to be saved somewhere else and brought back later.

At some point, the real challenge was building the right setup around my work so agents could actually use it.

That is the shift Agentic Academy is built around.

And today, enrollment is open.

Learn More About Agentic Academy

Agentic Academy for Knowledge Work is a 10-week live cohort for people who want to move from AI chat into agentic AI work.

The goal is simple

By the end, you will have one real AI process built around your actual work. I can promise you it won’t be just a demo or another pile of prompts you never use, but a working setup where Claude can read the right files, follow your standards, use your examples, remember your corrections, and help you run a repeatable workflow you actually want to keep using.

We start in Claude Code because it is one of the clearest places to learn the pattern: project folders, source files, rules, skills, workflows, permissions, and review. Claude Code is the starting place. We also teach the transfer pattern into Codex, so the structure you build in Claude Code can move with you: the project files, rules, examples, skills, workflows, and review habits.

The point of this cohort isn’t to teach you how to master a single tool—it’s bigger than that. The deeper goal is to learn how agentic work actually works, so you can understand what to build, what to ignore, what to trust, and how to keep improving the system as the tools change.

Michael brings the business and education side of this. He has spent his career as an education entrepreneur and has taught 1,000+ classes over the years, which matters because Agentic Academy has to be more than a tool demo. It has to be taught in a way busy professionals can actually follow.

I bring the systems side. Together, we are trying to make the shift from chat to agents feel less like something you have to figure out alone from scattered tutorials, and more like a guided build on your real work.

How the timing works

The full cohort starts Monday, June 22. But we are also holding an optional setup session on Monday, June 15 at 11am ET.

That June 15 session is there to make the start easier. I do not want people showing up to the first full cohort session with an empty folder, a half-installed tool, and no idea what project to use.

I have done that version before. It is stressful. It makes the first week feel heavier than it needs to feel. And it usually means people spend the first real session catching up instead of building something real.

So June 15 is an optional onboarding and setup session.

We will help you:

1. Get clear on the project you should bring into the cohort.

2. Understand what files, examples, and past work are useful starting material.

3. Get oriented around Claude Code Desktop and the basic setup.

4. Prepare for Chat X-Ray, which helps turn your existing ChatGPT or Claude chat history into a starting point.

5. Arrive on June 22 ready to build on real material instead of starting from a blank page.

The actual 10-week build begins the following Monday.

If you can join the setup session live, great. If you cannot, that is okay too. The point is to give you a cleaner runway into the cohort, not to add another thing to your calendar that makes the whole program feel heavier.

What you build during the cohort

Every week has a practical outcome.

This is important because I do not think most people need another AI lecture. They need help turning the work they already do into something an agent can help with repeatedly.

During the cohort, you will build:

1. A starter project based on your current AI use and real work.

2. A project home base that tells Claude what you are building, what good work looks like, and what to avoid.

3. A source library so Claude can find the right files, examples, and references for the task.

4. A correction system so you stop giving the same feedback over and over.

5. A Skill Library for the kind of work you actually do.

6. A way to orchestrate subagents so bigger pieces of work can be handled by clear roles instead of one overloaded chat.

7. A repeatable workflow that turns one real input into one useful output.

8. A trust layer with permissions, review steps, and quality checks.

9. A tool connection to the apps where your work already happens.

10. A final workflow you can keep using after the cohort ends.

The first build is the proof. The bigger win is that you learn how to build the next one yourself.

Learn more

We also created a full page that walks through the offer in more detail.

Agentic Academy for Knowledge Work

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

By Michael Simmons

If you are trying to figure out whether this is the right fit, that page is where I would start. It covers:

1. The week-by-week curriculum

2. The setup support before the full cohort begins

3. The White Glove Migration Suit

4. Testimonials

5. Pricing, enrollment, and the 30-day guarantee

Who this is for

This is for people who already use AI enough to feel both sides of it. You can see the potential. You can also feel the drag.

You have prompts saved somewhere. You have useful chats buried in your history. You have examples, drafts, notes, client context, research, meetings, or project files scattered around. You know AI could help more, but it still feels like you are doing too much of the setup work around it.

That is the person I think this helps most.

It is especially built for:

1. Creators who want AI to understand their voice, audience, archive, and publishing standards.

2. Consultants and coaches who want client prep, notes, follow-ups, and deliverables to stop starting from zero.

3. Operators and knowledge workers who turn scattered information into briefs, updates, reports, and decisions.

4. Entrepreneurs who need help connecting research, customer language, strategy, and execution without holding all of it in their head.

You do not need to know how to code. You do need real work to point this at.

But, if you only want a pack of prompts to copy, this is probably the wrong room. If you want something that works perfectly the second you open it, this may frustrate you too.

The first few weeks are about setup. They take some effort. They may feel slower than chat at first. But that is also the point. You are building the structure that makes the later work easier.

What is included

Every plan includes:

1. The optional June 15 setup session

2. The full 10-week live cohort starting June 22.

3. Monday live build sessions at 11am ET.

4. Recordings you can keep.

5. WhatsApp support during the cohort.

6. Chat X-Ray.

7. Starter project setup.

8. A curated Skill Library.

9. Build templates and improvement tools.

10. A 30-day guarantee from the June 22 start date.

There are three ways to join:

1. 10-Week: The full cohort experience.

2. Ongoing: The full cohort plus support after the first 10 weeks, a second seat, monthly mastermind sessions, quarterly Skill Library refreshes, and unlimited course retakes.

3. Custom: Built for teams that want private support, private workshops, custom modules, and a build path shaped around their actual work.

Because this is the first cohort, founding members of AI Maker get $500 off any plan.

Find out more about our pricing plans.

The 30-Day Money-Back Guarantee

You can try the full program for 30 days from the June 22 start date. Attend the sessions. Do the work. Build on your real project.

If you have put in the effort and the system is not delivering, email us within 30 days and we will refund your tuition. No hoops. No argument.

We can offer that because the cohort is built around your real work, not hypothetical exercises.

Why I am doing this now

The honest reason is that I keep seeing the same gap.

People are using AI more than ever, but a lot of the work still feels manual. They ask better questions. They save better prompts. They try better tools. But they are still re-explaining the same project, re-uploading the same files, re-pasting the same instructions, and manually moving output from one place to another.

I do not think the next jump comes from another clever prompt. I think it comes from building the setup around your work so agents can actually help with more of it. That is what we are going to build together.

If Friday’s post made you think, “Yes, this is the shift I need to make,” this is the next step.

Enrollment is open now. The optional setup session is Monday, June 15. The full cohort starts Monday, June 22.

Learn More About Agentic Academy

See you in the optional setup workshop,
Wyndo

On a recent One Shot Show session with Mark Miller, Mark opened a blank folder, talked Claude Code through what he wanted, and had a working RSS reader running by the end of the livestream.

That part was impressive.

The app pulled in feeds. It showed recent posts from the sources he cared about. It gave him a real place to read the blogs and newsletters that usually get scattered across tabs, email, and apps.

That is already useful, but as I watched it, I kept thinking about the next problem. An RSS feed reader can show you what is new. It does not automatically tell you what is important.

It cannot tell you which update connects to the project you are building, which question your readers are starting to ask, which product change is worth testing, or which headline is just loud for 24 hours and safe to ignore.

That is the gap I want to work on here.

A while ago, I built a Make.com automation to fix the first half of that problem.

I was subscribed to too many newsletters, blogs, and AI update feeds. I wanted to stay informed, but the reality was a mess. Some updates landed in my inbox. Some lived in Substack. Some were buried in bookmarks. Some were product blogs I kept meaning to check and never did.

So I built a system that pulled those sources into one AI-generated digest.

And honestly, it helped.

I stopped opening 30 tabs just to feel caught up. I had one place to check. The system pulled the sources together, summarized them, surfaced patterns, and sent me something I would actually read.

For my setup, that was already a big improvement. I was no longer relying on things I need to remember or a random Sunday catch-up session to know what was happening in the AI space.

But after using it for a while, I noticed the next problem.

The digest helped me stay updated. The harder part was figuring out what each update meant for the work I was already doing.

So the system solved the intake problem.

But it left the judgment problem mostly untouched.

And it started to affect me a lot as someone who writes for a living. I would read the summary, see a few interesting AI updates, maybe save one or two links, and then still have to do the harder part myself. I still had to figure out which updates connected to my current projects, which ones were useful for my readers, which ones were just noise, and which ones could become a real post.

For example, if an AI tool keeps showing up in newsletters I trust, I want to know whether it should change anything about my own setup. This is a very important part of my research process when deciding which posts to write next.

Why I Am Moving This Into Agentic Workflow

The Make.com version was great at moving information around. That was the right first step.

But as you probably know, I’ve been using agentic AI a lot with Claude Code and Codex. My drafts live here, along with my notes, including rules, post archive, and paid vs. free criteria. The agent can see all the source material I already use to make decisions.

This makes a huge difference when I’m trying to build a research process with my agent.

Instead of sending me a digest and making me synthesizing everything manually, I can ask the agent to compare new updates against my own work.

That is the upgrade I am building in this post.

What Changes When The Agent Can See The Work

Here’s my first Make.com version that worked:

1. Pull updates from sources I follow.

2. Summarize them.

3. Send me a digest.

Here’s how the new version works:

1. Pull updates from sources I follow.

2. Find the recurring signals.

3. Compare those signals against my own archive, notes, projects, and criteria.

4. Tell me what might be worth acting on.

This is where the new version becomes more personalized to my work and moves me closer to turning the research into productive output for writing my next posts.

This Works Beyond Newsletter Writing

Before you assume this only applies to newsletter writers, I want you to know it can work far beyond writing newsletter posts.

For example, of course, if you write online, it might mean finding a better angle for your next essay or newsletter. If you run a business, it might mean noticing a shift in your market before it becomes obvious. If you work in a specific field, it might mean turning scattered updates into a short weekly brief you can actually use.

The same system can serve different jobs because the core loop is the same: monitor the field, extract the signal, compare it against your own context, then decide what deserves attention.

For me, the writing use case is the one I feel most directly.

Instead of asking, “What should I write about?”, I can ask: “What is my field already paying attention to, and what have I not said about it yet?”

That question is more useful because it has pressure from both sides. It looks outward at what is happening, then inward at what I have already covered.

This is why the new version offers more value: the output is no longer just “here’s what happened this week,” but a short list of possible decisions:

1. Write about it if you publish in that field.

2. Bring it into a meeting if it affects your team.

3. Add it to a project if it changes what you are building.

4. Turn it into a client brief if people you advise need to understand it.

5. Save it as a research note if the signal is interesting but early.

6. Test it if the claim sounds useful but unproven.

7. Ignore it for now if it is loud but not relevant.

That last one matters more than I expected.

One of the hidden benefits of a system like this is that it gives you permission to ignore more things. When every update arrives in your inbox by itself, everything can feel equally important. When the agent reviews the week as a whole, patterns start to separate from noise.

In the rest of this guide, I will show you how I am building the working version: the source list, the Tavily scan, the optional email path, the archive check, the scoring rules, and the weekly output that turns a pile of updates into something I can actually use.

The System We Are Building

What we are building in this post is a Newsletter-based Industry Radar Agent.

The simplest version is a weekly research agent that monitors the sources you care about, pulls out the useful signals, compares those signals against your own work, and gives you a short list of decisions to make.

And this system also focuses on what happens after the information comes in.

By building this, you will learn how to:

1. Choose sources that are worth monitoring instead of dumping every feed into one list you don’t care about.

2. Use Tavily, RSS feeds, and optional email sources as inputs.

3. Give the agent your own archive, current projects, and decision rules so it has something to compare against.

4. Turn a weekly pile of updates into a ranked set of signals.

5. Decide whether each signal deserves writing, research, testing, discussion, project work, or nothing.

After setting this up, You should be able to open one daily/weekly file and see:

1. What changed in the field you are tracking.

2. Which topics or questions are showing up repeatedly.

3. Which updates connect to your current work.

4. Which ideas you have already covered.

5. Which signals may deserve a post, brief, project, meeting, experiment, or follow-up.

6. Which updates are probably safe to ignore.

For writers, this can become a grounded idea system. For founders, it can become a market radar. For consultants, it can become a client brief generator. For researchers, it can become a weekly field scan. For team leads, it can become a way to bring useful outside signals into planning without asking everyone to read the same pile of links.

The weekly flow looks like this:

1. Pulls recent updates from selected RSS feeds, Substack feeds, public URLs, and optional email newsletters.

2. Uses Tavily to fetch or research sources when RSS is not enough.

3. Extracts titles, topics, claims, reader problems, formats, and recurring themes.

4. Compares those patterns against your archive, current projects, and decision criteria.

5. Returns 5 to 7 ranked signals or ideas.

6. Labels each item as write, build, research, discuss, save, or skip.

7. Optional: For Substack writers, adds a free vs paid post recommendation when relevant.

Now, let’s dive in!

The Agent Folder Setup For The Newsletter-Based Industry Radar Agent

Before we get into the details, here is the folder we are going to use. Download them below:

Read more

I have been getting a lot of sales emails and DMs lately that technically mention the right things.

They reference my newsletter, even the number of my subscribers. They mention AI. Sometimes they even name a specific post.

But most of them still do not feel like a human actually read anything.

And maybe that bothers me more because I use AI so much. I know the shape of an AI-assisted message. I can feel when someone asked a tool to “personalize” something without actually doing the thinking underneath it.

That is the part that feels annoying. The message is trying to sound researched, but it still feels performative. Like someone wanted the credit for doing their homework without actually caring about the person on the other side.

So when David sent me this piece, the frame clicked for me.

Most people are asking, “How do I use AI to do more sales work?”

David is asking a better question: “How do I use AI to remove the admin drag so I can show up more human in the moments that matter?”

That feels much closer to the AI Maker way of thinking about this stuff. AI should help with the notes, the prep, the first draft, and the messy follow-up work. But the judgment still has to come from you.

writes Eng Sales, a newsletter for technical founders who have become their own first sales rep.

ENG Sales

Defaulted into head of sales? ENG Sales helps founders turn sales chaos into repeatable revenue. Weekly I share what I learned building $100M in B2B revenue, giving you one action step you can take. Subscribe for FREE & get Revenue Flywheel Diagnostic.

By David Roy

If you want to explore more of his thinking, here are three places to start:

1. TFT:You Hit $500K ARR So Why Did Growth Suddenly Stall?

2. TFT: I was Rejected by My Buyer’s AI Agent

3. The Revenue Flywheel System

In this post, he breaks down a simple rule for using AI in sales without burning trust:

AI drafts. Humans decide. Trust is the asset.

Here’s David.

Hello 👋🏻

Most founders ruin AI in sales the same way.

They slap an AI bot on top of a broken system then act surprised when it doesn’t work.

Of course it doesn’t work.

AI cannot fix a broken sales system (more on that here)

Sales is about problem solving with another human. You need trust to do that. AI used correctly helps you build trust.

I’ve seen AI destroy trust with a customer, because I was trying to implement AI tools too fast.

So here’s the mantra I now run my sales process by:

AI drafts. Humans decide. Trust is the asset.

I like this because my focus with founders is to help them reframe sales as problem solving with another human. This mantra keeps the human in the loop working with another human, which is key in a world of increasing AI.

Today I want to share what I’ve learned as I’ve implemented more AI into my own sales workflow. These examples are from working with technical founders with a great product who are building momentum but don’t love sales and small service businesses like HVAC (Heating, Ventilation, and Air Conditioning) companies implementing their first CRM and sales process where customers still want a human.

My AI Sales Stack

Here’s the simple version of my AI stack today:

• Call notes + summaries: transcript → summary → action items (busywork)

• Research + prep: industry/ICP context, account notes, stakeholder mapping (busywork)

• Writing support: tighten your drafts for follow-ups and proposals (busywork)

• Process hygiene: turn insights into next steps and reminders (busywork)

Notice what’s missing: nothing here replaces human-to-human engagement. Because sales is just problem solving with another human. AI is great at removing the admin drag.

Step 1: Don’t Automate Until You Can Name Your Process

Before you build a single AI workflow, ask yourself one question:

Do you have a sales process that actually works today?

Not “we follow up when we remember.” A real, repeatable sequence.

If you can’t write down the steps you take for every deal, AI won’t help you.

Here’s what I want founders to do first: write out the 8–10 steps of your process, then identify which steps are:

• Busywork: admin and pattern work (safe to automate)

• Trust moments: anything that changes the relationship (keep human-led)

This is the first step to your AI implementation. The items marked “Trust” will stay human-led. The “Busywork” can be automated with AI.

Look at your last 5 closed deals to get a clear picture of what those steps actually are. If you want more on building out the sales process I talked in detail about that here.

Step 2: Start With What AI Is Actually Good At

For me, AI became immediately useful in two places.

Getting Clarity on My ICP in Unfamiliar Industries

I came from energy and industrial manufacturing. But I’ve sold into industries I’m less familiar with: HR companies, virtual assistant companies, HVAC, website design, and business consulting.

That’s where AI became a cheat code. It didn’t magically know the customer. But it helped me rapidly understand what’s happening in their industry right now, the common pain points and trends, and the language buyers actually use when they describe their problems.

AI shortened the learning curve. I still had to decide what mattered.

Here’s the exact research sequence I use to get up to speed on a new account:

The ICP Research Prompt Sequence:

Real example — DFW HVAC Company (HVAC/plumbing):

I ran this sequence on a 65-year-old, highly-rated independent contractor. The research surfaced three things I wouldn’t have found in a 30-minute call: their own customers didn’t know they did plumbing (a cross-sell blind spot), they had no maintenance or membership program (a recurring revenue gap), and an underused referral engine all quantified against industry benchmarks before I walked in the door.

AI got me to the conversation faster. I still had to ask the right questions.

Other prompts I’ve used with Deep Research:

Subscribe now

Step 3: Treat AI-Generated Communication Like a First Draft. Not the Final Word.

Here’s where AI has burned me and probably burned you too.

When I give AI an email and say “respond using my framework,” it often produces generic wording, makes things up, or misses the nuance of where the customer actually is.

When that happens, the outcome is predictable: best case, the message gets ignored. Sometimes, the customer replies confused. Worst case, you lose trust and the opportunity quietly dies.

I once used AI to draft a follow-up email after a call. It sounded polished, but it included one confident detail that wasn’t true. The buyer replied politely and corrected it. I didn’t lose the deal on the spot, but I could feel the trust drop. Everything got harder.

That’s the danger zone: when AI sounds certain, but you haven’t verified the facts.

The Better Workflow I Use Today

Instead of asking AI to “write the email,” here’s what I actually do:

Step 1 — I write my rough draft first:

“Hi Marcus, Great call today. Wanted to follow up on the service-to-sales handoff issue you mentioned. Your service techs are walking past replacement opportunities every day. We can help capture those signals automatically and route them to your sales team so nothing falls through. Worth a quick 30-min call to map it out?”

Step 2 — I add context and keywords only I know, then ask AI to tighten it:

What AI gives back:

“Hi Marcus, Following up on our conversation. Your service team is walking past real revenue every day, units due for replacement, accounts ready for an upgrade. We can help flag those signals automatically and route them to sales before they go cold. Would a 30-minute call this week help us map out exactly where those handoffs are breaking down?”

The difference: The first version was mine and not bad, but the second version is tighter and cleaner. I just ensured that every fact in it came from me. AI refined the words. I owned the substance.

Because in sales, the details are where trust is built.

Step 4: Automate the Busywork First

If you want the fastest safest wins with AI, start with what steals time from you, but doesn’t require trust.

Here are the first automations I’ve gotten real value from with specific tools and outputs:

AI note-taking on customer calls (my biggest ROI)

Tools: Notion AI, Granola, Firefly, or your CRM’s built-in transcript.

What I do: Record every customer call with Notion AI. After the call, I get the transcript as well as a summary with action items.

If you just have your transcript use this prompt:

This gives me a clean brief I can action in 2 minutes instead of trying to remember the call 9 days later. I love that Notion autogenerates the actions and summary. That way I don’t have to go back and run the prompt myself.

Proposal refinement

What I do: Write the proposal myself first. Then paste it into AI and ask:

The output shows me the gaps before the buyer finds them. Which is helpful with new buyers. I also like to combine this with my transcript after the call. While it’s not perfect. The AI helps me pick up on questions the customer asked that can help refine the proposal. For that I like to use a prompt similar to the one above, it looks like:

Yes, you were listening during the call so you should already know this. But what I’ve seen is the AI will pick up on at least one item I did not in the call. Which means when I go to draft my follow-up e-mail, I’m hitting on all of their concerns, not just the 2 or 3 that I picked up on.

How this looked with the HVAC company I’m working with was I knew they needed a sales process and to connect their service and new installs teams, but I missed a small opportunity with their follow-ups. When I ran my call through AI with a similar prompt to the one above I got this back as the first action:

Turn their existing customer data into a proactive CapEx pipeline. They described a gold mine: they already track equipment lists, repair spend per unit, and customer budget cycles (January, April, even July starts). They’re already having consultative conversations about repair-vs-replace and planned expenditures. But it sounds informal, it happens when they remember or when the customer’s unit fails. The Upsell Driver’s expansion fit diagnosis maps directly here.

I might have gotten to this action step eventually, but it for sure would not have been as fast.

Draft recaps after meetings

I do this a little different now since Notion actually gives me the full summary. But if you are working with a tool that just gives you the transcript use a prompt like this:

The consistent principle: AI handles the admin drag so human energy goes where it actually matters.

Share

Step 5: Keep Humans in the Trust Moments

There are parts of sales you should not automate, because they are the high trust moment. The trust moment filter I use: if it changes the relationship, a human goes first.

That means discovery calls and asking the real questions. Objection handling, especially on pricing, timing, or “do we need this?” Negotiation and terms language. Pushback emails when the buyer is tense, confused, or skeptical.

Really anything emotional or high-stakes needs a human in the loop. I know that may sound obvious but you might be surprised what people will try to automate.

I’ve seen AI Agents conducting interviews. And even when they call the prospect on the wrong day, they continue with the interview. Interviews in my mind are still a human to human interaction.

Where AI can help without replacing you: prep (likely objections, agenda, questions to ask), after-call recap drafts, risks and next-step options, and tightening your own wording after you’ve written the truth. I’ve used the prompt:

This prompt gave me 5 key topics/questions that I needed to make sure I covered on the call. Which meant I focused our time on their challenges and not my framework, or just basic questions. I was able to tailor the call to the key insights that would help them the most.

AI can support these moments. But the human should handle the human.

Sales is problem-solving with another human. Founders forget this because they think sales means persuasion, which it doesn’t. It means understanding a problem clearly enough that the customer feels seen.

The Real AI Sales Stack Summary

Don’t overcomplicate it.

1. Audit your sales motion

2. Automate low-stakes friction

3. Keep humans in trust moments

4. Iterate one step at a time

And remember the rule:

AI drafts. Humans decide. Trust is the asset.

Action Step

If you do one thing this week, do this:

The “AI Notes → Insights → Follow-up” Workflow:

Pick your note-taking tool (Notion AI, Granola, Firefly, or built-in CRM transcript).

Record your next 3 customer calls.

After each one, have AI summarize what they care about, their objections, their decision criteria, and the confirmed next steps.

You do a human review.

Then schedule follow-ups based on those insights.

This is a high-leverage workflow because the customer interaction stays completely human while AI handles the entire admin layer.

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

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

GenAI Unplugged

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

By Dheeraj Sharma

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

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

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

Mark said it plainly near the end:

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

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

Why This One Is Worth Your Time

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

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

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

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

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

That is where it started for him.

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

The One Habit That Made the Build Work

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

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

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

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

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

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

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

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

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

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

• The headlines are too small, fix them.

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

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

Subscribe now

Steal the Whole Build as One Prompt

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

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

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

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

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

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

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

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

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

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

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

It Was Never Really About RSS

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

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

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

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

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

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

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

Mark’s Rules of Thumb

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

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

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

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

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

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

What I’d Tell You to Do With This

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

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

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

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

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

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

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

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

See you in the next one!

Share

Watch the Full Session

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

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

Timestamp:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Resources Mentioned

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

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

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

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

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

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

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

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

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

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

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