I wrote the first edition of this guide in 2022. The argument was simple. Shipping is slow and expensive, so validate ideas before you build. Every sprint spent on the wrong idea meant two weeks wasted.

That argument is dead. The conclusion survived.

When you can ship an idea the same day you have it, deciding what to ship becomes more important than ever. And speed multiplies waste: a team that shipped 2 bad ideas per sprint can now ship 20 a week, plus the regressions their users feel. You can't throw everything at the wall and see what sticks.

Product discovery is, still, the highest-ROI skill in product management.

In this guide:

• Why product discovery matters even more in 2026

• What changed: shipping became the cheapest experiment

• Who does discovery now: the Product Trio, plus your agents

• How to instrument a product you release daily

• What stays manual, on purpose

• Templates, frameworks, and resources to go deeper

1. Why We Still Need Product Discovery

In product management, most ideas won't work as expected. As Marty Cagan says in Inspired:

"The first truth is that at least half of your ideas are just not going to work."

Good teams assume at least three-quarters of their ideas won't perform as they hope. That's still true in 2026. What changed is how fast, and how cheaply, you find out.

Product management is, at its heart, about managing risk. And for every product, 5 essential risks can materialize:

• Value Risk: Will this idea truly create value for customers?

• Usability Risk: Will users figure out how to use it?

• Viability Risk: Can our business support it?

• Feasibility Risk: Can we build it with our current technology?

• Ethical Risk: Should we build it at all? Are there ethical considerations?

By exploring these questions early, you'll avoid committing to dead-end ideas. The goal of product discovery is still: discover what to build and address the biggest risks before you commit, so the team builds things people actually want that also work for the business.

The way we get there has changed a lot since 2022.

2. Shipping Became the Cheapest Experiment

The 2022 case against "learning by delivering" went like this: what happens if we throw random ideas into the Product Backlog? Some might work, but most won't. And the best ideas might not even be on the list. Unfortunately, this approach results in waste and rework.

Some kept saying it's not a problem, as the Sprint is often 1-2 weeks long. But this happened every Sprint. Every Sprint, the product team selected ideas, implemented them, and delivered a production-ready increment only to discover those were not good ideas.

And strong teams don't ship every two weeks anymore. As Marty Cagan notes in TRANSFORMED, strong product companies release several times per day. AI has only accelerated that. The waste the 2022 case feared no longer costs a sprint. It costs an hour.

Everything I build deploys on every push to a production branch. For example, Accredia won't go live until 10 automated user journeys pass in a real browser: real Clerk sign-ins, real quizzes, real certificates. An agent implements an idea, the suite verifies it, and the change is in production within the hour.

Another project, Grok Build for VS Code installed by 31K+ engineers (Open VSX, VS Code marketplace), has 1,082 unit tests executed on every push. 10 days ago, I shipped five releases in a single day.

Shipping without discovery is still an anti-pattern. But the reason is different now.

When building takes hours instead of sprints, the cost of shipping the wrong thing isn't failure. It's everything you didn't ship instead.

Two consequences:

• Ship to learn: some ideas deserve 1-2 weeks of discovery. Others go live the same day, behind a feature flag, instrumented. It's often easier to ship than to run an experiment.

• Do it responsibly: Cagan's discovery and delivery principles haven't moved. Protect revenue, reputation, customers, and colleagues while you experiment.

Team objectives decide what's worth shipping toward. If your team runs OKRs, use them as the filter, so all that speed points at an outcome.

Subscribe now

3. Continuous Product Discovery in 2026

Continuous Product Discovery is how Product Discovery works for an existing product.

You might have heard about Dual-Track Development or Dual-Track Agile. It simply means having two streams running in parallel: Continuous Discovery and Continuous Delivery.

What's important here is that this is not a waterfall. Some team members talk to the customers, explore people's problems, brainstorm solutions, identify assumptions, and perform experiments. At the same time, the team implements and delivers validated ideas to the market. Discovery still answers the same question: what is worth building? Its output changed.

Discovery no longer produces a validated Product Backlog.

In 2022, we tested high-risk assumptions upfront because implementation was expensive. Today, when a safe, reversible idea takes 1-2 prompts to implement, building it can be the test, and not every idea needs a formal experiment first.

Your Opportunity Solution Tree can now hold both experiments and features:

• High-risk or hard-to-reverse ideas: test them with experiments, as always.

• Cheap, reversible ideas: ship behind a flag and measure real usage.

The freedom to ship fast makes the problem space more important. If you don't understand the problem, faster shipping only produces more noise. Two classic tools got promoted:

• Jobs to be Done: most teams that quote JTBD never run the formal framework, with job maps and outcome surveys. They ask simple questions instead: What job is the customer trying to do? How do they measure success? That's the right way to use it. The value is in JTBD inspiring the right questions.

• User journey mapping: map where users actually struggle before deciding what to ship next. When you release daily, keep the map current.

The same shifts apply to Initial Product Discovery, when you're validating a brand-new product. The stages I described in the 2022 edition still hold, but prototypes that took weeks now take an afternoon. Time to Learn, the time from idea to validated insight, is the metric that matters.

4. The Product Trio Now Includes Agents

There is a common misconception. Some say that the Product Manager decides what to build, and Engineers and designers should focus on how to build it. Have you heard that before? It hurts my ears because Product Discovery is not a task for a single person.

In Continuous Discovery Habits, Teresa Torres introduced the concept of a Product Trio: Product Manager, Product Designer, and Engineer working together. I have repeatedly found that the best ideas often come from my engineers. They know what's technically possible. But the Trio was never about three people, it was about having the cross-functional competencies in one room: value, viability, usability, feasibility. The Product Trio is not a rigid framework. It's the default recommendation that can expand and contract.

In 2026, the roles behind those competencies are melting. Boris Cherny, the creator of Claude Code, reflecting on his own team:

"As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future... I also notice that these roles are not really tied to job function."

And the competencies no longer have to be human. Agents join discovery as team members: one synthesizes interviews, one builds the prototype, one wires the analytics. Seriously.

An agent, like a person, does poor work when you hand it tasks without context. Lead your agents like empowered teams: an objective, desired outcomes, context, and constraints, not a list of instructions. That's what my Intent Engineering framework is for, and it mirrors how Cagan defines team objectives.

In the premium part below:

• Instrumentation without a data team: how agents build your dashboards the same day

• Session recordings: the free tool that shows you why users drop off

• Product data intuition: what to watch when you release daily

• My Continuous Product Discovery Template (Notion): interviews, opportunities, ideas, and hypotheses in one system

🔒 5. Instrumentation and Data Intuition

🔒 6. What Stays Manual, On Purpose

For paid subscribers.

🔒 7. The Continuous Product Discovery Template

To put this into practice, premium subscribers get my Continuous Product Discovery Template (Notion).

It covers the four things you’re juggling in every discovery cycle:

• Interviews: what you heard

• Opportunities: problems and needs worth solving

• Ideas: candidate solutions

• Hypotheses: what you’re testing or shipping, and what happened

Duplicate it, bring your team (and your agents), and run your first cycle this week!

8. Resources

Everything referenced in this guide, plus the deeper dives:

Frameworks and techniques:

• Product Trio: Beyond the Obvious

• 12 Proven Sources of Insights to Fuel Your Product Discovery

• User Interviews: The Ultimate Guide

• Testing Ideas: The Ultimate Validation Experiments Library

• How to Manage Risks as a Product Manager

• 8 Things About Product Frameworks I Wish I Knew Earlier

The product model:

• Product Model First Principles: Team & Strategy

• Product Model First Principles: Discovery, Delivery, Culture

• Continuous Product Delivery

• OKRs 101 + Advanced Techniques

AI and discovery:

• The Intent Engineering Framework for AI Agents

• From Weeks to Hours: How Claude Design Compresses Product Discovery

Books: start with Inspired and Continuous Discovery Habits.

Premium subscribers can also enroll in the Continuous Product Discovery Masterclass video course for free.

Final Thoughts

Product Discovery doesn't have to be complicated. The key is to stay curious about your users, test ideas early, and collaborate with your team to build solutions people actually want. It used to be how you avoided wasting a sprint. Now it's how you decide what all that speed is for.

Learn discovery, then run it at 2026 speed: ship the cheap ideas, test the risky ones, and keep the customer conversations for yourself.

Tomorrow (Thursday), we'll have a live session to discuss this in practice and answer your questions. Details and invitations for paid members: go.productcompass.pm/events.

Some of our previous events available in the archive:

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a fantastic rest of the week,
Paweł

Many of you have been asking about C30 and C31 since November. The first part is here, free to take everyone.

This is where you go from reading about workspace agents to working with them every day: Claude Cowork, Codex, and Claude Code, hands-on.

It’s split into:

• C30. Claude and Codex Certified PM: Demonstrated knowledge and took the exam.

• C31. AI-Native Practitioner PM: Demonstrated real experience by managing and building with agents. Details in the upcoming sessions.

And directly related to our past and upcoming AI-Native PM sessions:

C30. Claude and Codex Certified PM

Here’s the exact set of lessons covering the scope you need. Each pairs a live session from The AI-Native PM Roadmap with a written guide:

How to Earn the C30. Claude and Codex Certified PM

All you need to do is to take a free knowledge test:

• 20 single-choice questions

• 80% required to pass

• 40 minutes

• 1 attempt per week (a larger pool of questions)

The questions are scenario-based: what you want to achieve, and which tool or mechanism gets you there. If you attended the sessions or read the guides, you’ll recognize the situations.

After each attempt you will see your points, mistakes, and explanations so you can learn and improve.

No prerequisites.

Start the exam

What’s Next: C31. AI-Native PM

C31 is where you demonstrate real experience across the full AI-Native PM path. I’ll share the exercises and submission details with the upcoming sessions. The scope:

• Knowledge bases and agent memory (second brains)

• AI Product Discovery

• AI Prototyping

• AI Evals

• Agentic Engineering 101

We cover each of these live with paid subscribers in the AI-Native PM sessions, every Thursday at 6:00 PM CET (see you tomorrow).

Subscribe now

With every session, I’ll be updating this article 🙌

Questions?

In case of any questions or doubts, you get full support on our Slack:
#c31-ai-native-pm

Link to join our community: Your Premium PM Resources

I’m also available during weekly office hours.

More About Our Certification Programs

Other certified programs available as part of your paid subscription include:

• C11. LLM Practitioner PM (+free C10)

• C21. AI Agents Practitioner PM (+free C20)

• Continuous Product Discovery (video course)

• From Strategy to Objectives (video course)

• Product Innovation (video course)

After completing each track (e.g., C30, C31), you will get a digital, shareable certificate.

Subscribe now

Your Public Profile

You will be able to share your credentials and/or profile with others, for example: https://www.accredia.io/users/pawel-huryn

Claudathon for PMs

Separately from your subscription, and I work closely with individual PMs and product teams to help them build, ship, and bring full-stack agentic apps powered by Claude to market. This intensive experience turns you into a fully fledged Agentic Product Builder.

The next cohort starts on September 1, 2026. Early bird: go.productcompass.pm/claudathon

You can the work of our students in the AI Gallery.

More Resources

Here are some additional resources to explore:

• AI Product Manager Glossary - understand key terms

• AI PM Learning Roadmap - for extra links, guides, and resources

And posts you might have missed:

• 19 Hands-On Video Guides for PMs

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

• What I Learned Building a Self-Improving Agentic System with Claude

• How to Build an AI Agent with n8n and Lovable (No Coding)

• The AI Product Pricing Masterclass

• Your Complete Roadmap to Earning a $180K–$569K AI PM Role

• A PM’s Guide to Evaluating AI Agents

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a fantastic rest of the week,
Paweł

During each of those sessions, I demonstrated a practical use of a tool (sometimes including fixing errors live) and answered your questions.

Subscribe now

Event details include timestamps, free templates, and linked resources, for example:

I recommend starting with these three (100% free, highest ROI):

• Claude Cowork for PMs

  • Demo: 100 interviews > hypotheses > prioritized ideas > prototypes

  • Resources: 6 prompts and 100 synthetic interviews

• Codex App for PMs:

  • Demo: Automating browser workflows

  • Resources: AGENTS.md <> CLAUDE.md sync pattern

• Introduction to Claude Code for PMs

  • Demo: Scan Gmail to Linear > create a skill > use Claude Code for free

  • Resources: Detailed template with skills, hooks, cost optimization, and more

Share

The 6 upcoming sessions to break into AI PM

In the coming weeks (starting in 2 days), as a paid subscriber you can also attend (and later access the recordings):

That’s not all. I will host weekly sessions at least until the end of 2026 (then we’ll review what makes sense: weekly or bi-weekly).

Subscribe now

19 AI PM sessions you can access today

Premium subscribers can already access the entire archive (19 sessions: n8n, Lovable, multi-agent systems, voice agents, and more).

The AI PM Learning Program

The last 3 (Cowork, Codex, Claude Code) and the upcoming 6 AI PM sessions will extend our AI PM Learning Program.

As a paid subscriber, you can already access:

• C11. LLM Practitioner PM (2 certificates)

• C21. AI Agents Practitioner PM (2 certificates)

Tomorrow, I’m announcing:

• C30. AI Tools for PMs (free)

• C31. AI-Native PM details.

And here, I explained why the program is organized that way:

My Product Hit 20K+ Installs and ~1,500 DAU

A few weeks ago, I made a bet that Grok would catch up to Claude and GPT models. It did. Benchmarks differ, but it’s at the level of Opus 4.8:

According to my tests, it’s also several times cheaper than the alternatives.

When making a bet, I noticed one issue: Grok Build is a CLI interface and not everyone is a dev living in the terminal.

So, I built Grok Build for VS Code. It’s a graphical interface that supports both agentic engineering and knowledge work. Works in Cursor too:

Yesterday, we hit 20K installs across VS Code Marketplace and Open VSX and ~1,400 DAU (estimate, source: Aptabase). Most of the acquisition can’t be attributed to my social media activity: 80% of users discovered or recommended the extension organically.

Want to try it?

Go to “Extensions” in VS Code or Cursor and look for “Grok Build for VS Code (Community).” The extension walks you through installing the grok CLI and signing in. You can also get a free 7-day trial for SuperGrok.

Sharing knowledge

I’ll be sharing what I learned about distribution and agentic engineering (850+ automated tests and 22K+ lines of code of which I reviewed none) during the upcoming video sessions and in my future posts.

Subscribe now

Monetization plans

The product is free and open source, but most of the users already pay xAI (high intent, high satisfaction + they use my interface). Product-market fit had to come first.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a fantastic rest of the week,
Paweł

Did Claude replace n8n? Should you drop one and learn the other?

I get why.

For more than a year, when I wrote about building AI agents, I wrote about n8n. Then I started writing about Claude Code, Cowork, and Codex.

But the answer is no.

That is the whole point of this roadmap.

You learn the foundations once. Then one question splits the rest:

Does the agent run on your work, or inside your product?

Some agents run in your workspace, on your own work: Claude Code, Cowork, Codex. Others are embedded inside a product or a business process, running on their own for your users or your team: n8n, the Agent SDK, managed platforms.

So it’s not n8n versus Claude Code.

It’s workspace agents and product agents. You need both, and you use the first to build the second.

Here is the path:

• The foundations every AI PM needs, tool-agnostic, learned once

• How you work with agents: the workspace agents you do everything with, and the product agents you build using them

• How to make production agents reliable once they run without you

• Where AI product strategy fits on top

• The exact programs and live sessions that take you deeper on each part

Subscribe now

Part 1. Foundations (Learn Once, Before the Split)

Concepts, communication, and knowledge apply the same way whether the agent runs on your work or inside your product. We learn them once here, and everything after gets easier.

1. The Role of an AI PM

Start with the job. Before any tool or technique, get clear on what the role actually is and where it differs from classic PM. The mindset shift underneath everything: models and tools are easy to get excited about, reliable systems that create value are the actual job.

• WTF is an AI Product Manager: the role, and where AI PM differs from PM

• What Is Product Discovery: the discovery foundations, still the PM core

• Stop Watching AI Models. Start Designing AI Systems: the models-to-systems shift, in full

2. Basic Concepts

For most PMs it makes no sense to dive deep into statistics, Python, or loss functions. You need to understand what a model can and can’t do, and how to design a system around it.

Recommended resources:

• Introduction to AI Product Management: neural networks, transformers, LLMs, tokenization, no math required

• Interactive LLM visualization: watch a model run token by token, in your browser

  

• AI Product Manager Glossary: 100+ terms (recently updated), save it as a reference

3. Talking to AI: Prompt, Context, and Intent

This skill carries over to every agent you’ll touch, workspace or product, so it lives here, above the split. Three layers, each building on the last:

• Prompt engineering steers a single answer.

• Context engineering gives the agent memory, tools, and the information it needs.

• Intent engineering constrains an agent that acts autonomously, even long-term, so it does the right thing without you watching every step.

Learn all three and you can talk to any agent, workspace or product.

Recommended resources:

• 14 Prompting Techniques Every PM Should Know

• A Guide to Context Engineering for PMs: the new prompt engineering, covering RAG, memory, tools, and retrieval

• The Intent Engineering Framework for AI Agents: objectives, outcomes, enforced constraints

• Prompt resources: The Ultimate Prompts Library for PMs, Anthropic’s Prompt Engineering guide and its free interactive course, plus the Prompt Generator and Prompt Library

4. Knowledge Systems: How Agents Know Things

Look closely at knowledge systems and the split almost disappears. A markdown second brain that Claude Code reads before it answers, and a vector database that a production agent searches, are the same idea wearing two outfits: how an agent knows what it needs to know.

Your agent is only as good as the context system it can retrieve from and update. Second brains, CLAUDE.md, RAG, vector stores, files, and past tool outputs all answer that one question.

Recommended resources:

• An Interactive RAG Simulator: watch retrieval work, chunk by chunk (free)

• How to Build a RAG Chatbot Without Coding: vector stores, embeddings, chunking, step by step

• Three Essential Agentic RAG Architectures in n8n

• What I Learned Building a Self-Improving Agentic System: systems that compound, and how they degrade

• Three CLAUDE.md Blocks That Make Claude Get Smarter

• PM Brain OS: The Second Brain for PMs, Made of Markdown

• Gemini File Search API: A Practical Handbook: RAG as a service

For PMs: Learn markdown and vectors first. Reach for graphs only when your relationships get genuinely complex.

5. Fine-Tuning

Fine-tuning is not where most PMs should start. It's what you reach for when prompting and retrieval stop being enough, and the skill is knowing when that moment arrives. Most days, RAG wins.

Recommended resources:

• The Ultimate Guide to Fine-Tuning for PMs: when to fine-tune vs stick with RAG, plus SFT, DPO, and ORPO

• Practice platforms (no coding):

  • OpenAI Platform,

  • Hugging Face AutoTrain,

  • LLaMA-Factory

Part 2. How You Work With Agents

Foundations done. Next:

• Workspace agents are how you do the work, all of it: discovery, prototyping, delivery, shipping, research, marketing.

• Product agents are what you build with them, when the agent has to live inside a product.

You use one to make the other, so they were never rivals. Learn both, starting with your workspace agents.

6. Workspace Agents: Run on Your Work

A workspace agent runs on your own work. You give it intent and review what it produces, whether you watch it live or let it run on a schedule overnight. It's agentic: you set the goal, the agent plans and runs the steps. You use them across the whole job, from discovery to prototyping to delivery to shipping. This is the bench everything else runs on, so it goes first.

Start with the tool, then learn to operate it well: how to organize it with CLAUDE.md / AGENTS.md, skills, MCP servers, hooks, and subagents.

Recommended resources:

• Claude Cowork: The Ultimate Guide for PMs: no terminal required

• Claude Code for PMs: The Beginner’s Guide: install, MCP, skills, start here

• The Guide to Claude Code for PMs: more advanced

• How to Set Up Codex as a PM and Run It Next to Claude

• Claude Dynamic Workflows for PMs: set a goal tonight, results by morning

• Agent Loops for PMs: 20+ You Can Run This Week

The advanced move: agentic engineering. Once you can manage one agent, you can build real things with it. Recommended resources:

• The Rise of Vibe Engineering: the basic engineering skills you now need

• I Don’t Review the Code. I Review the Artifacts.

What a workspace agent gets you: AI product discovery and prototyping

This is the payoff of your workspace agents, and the work that sits closest to what a PM already does. Product sense plus the ability to build: that's the combination you bring here. You use workspace agents to discover and prototype in hours instead of weeks: test a hypothesis, build a working prototype, put it in front of users, learn, repeat.

Recommended resources:

• AI Prototyping: The Ultimate Guide for PMs

• From Weeks to Hours: How Claude Design Compresses Product Discovery

• Other tools to prototype with: Lovable full-stack course, Base44, Dyad (free), Stitch vs Google AI Studio vs Firebase

Dedicated AI discovery and prototyping guides 2026 are coming. Until then, the discovery fundamentals still hold, and AI changes the speed, not the logic: The Ultimate Validation Experiments Library, Continuous Product Discovery 101, 12 Proven Sources of Insights, Jobs-to-be-Done Masterclass with Tony Ulwick, How to Prioritize Ideas as a Product Manager

7. Product Agents: Embedded in a Product

A product agent is embedded inside a product or a business process. You design the architecture, wire the tools, set the guardrails, and it runs on its own, for your users or your team. You build it with your workspace agents, which is why it comes second here, not because it matters less.

Product agents are orchestration-first: you design the steps, tools, guardrails, and handoffs instead of letting the model improvise the whole process. The question you’re probably asking: why learn n8n, if Claude and the Agents API can build agents too?

Because building them visually first teaches you more. In n8n, you can see how the agent works. You drag the boxes, connect the tools, and watch the data move, the same way you’d build RAG by hand. You feel where the loop lives, where the model decides, where a tool result comes back.

That understanding compounds. It’s why I was writing about orchestration over autonomy months before “harness” caught on, and why the intent engineering framework was here before the labs shipped their /goal commands.

Build a few agents visually before you build them in code. You'll understand the harness in a way that's hard to get if you start in Claude Code, and that understanding carries back into Claude Code too.

My favorite tool for this, by far, is n8n: drag-and-drop workflows and multi-agent systems that connect to almost anything.

Recommended resources:

• The Guide to n8n for PMs: the leading no-code framework

• Master 80% of n8n in 59 Minutes (Free Course)

• Introduction to AI Agents for PMs: what an agent is, building blocks, workflows vs agents vs multi-agent

• AI Agent Architectures: The Ultimate Guide With n8n Examples

• 14 Principles of Building AI Agents (Learned the Hard Way)

• I Copied the Multi-Agent Research System by Anthropic

• MCP for PMs: Automate Figma to Jira in 10 Minutes and J.A.R.V.I.S.: n8n + Any MCP Server

• Your .claude/ Folder Is a Production Agent: the Agent SDK, reframed

Part 3. When Agents Need to Be Trusted

Once an agent touches real work or real users, one question matters: can you trust it?

Evals are mostly a production concern. When you manage a workspace agent, you review its work as it goes, the artifact review from Part 2. When an agent runs without you watching and can impact your customer, you can't eyeball quality, so you have to measure it. Shipping and hardening cover the apps you build along the way.

8. AI Evals and Observability

Fancy architecture doesn't matter if the product doesn't work, especially once it runs on its own. Evals are where trust is won or lost, and they're your job, not only the engineers'.

Recommended resources:

• Introduction to AI Evals: A Complete Guide for PMs: start here (free)

• AI Evals: How to Find the Right Metrics (Error Analysis)

• The action-based framework: evaluate actions, not words

• The Ultimate Guide to AI Observability and Evaluation Platforms

• A massive free FAQ: hamel.dev/blog/posts/evals-faq

Subscribe now

9. AI Shipping and Hardening

When something you built with a workspace agent becomes a product people rely on, the question shifts from "what can I do?" to "how do I not break production?" Branching, hosting, CI/CD, security, and performance.

Recommended resources:

• How to Build and Scale Full-Stack Apps in Lovable Without Breaking Production: branching to separate dev, test, and prod

• 17 Penetration and Performance Testing Prompts for Vibe Coders

• PM Skills 2.0: Red-Team Your Roadmap, Then Check the Code Before You Ship

Part 4. Zoom Out: AI Product Strategy and Leadership

Tools and agents are the how. This is the why, where product thinking still beats any model. Don’t skip it. The PM job is expanding into shipping and business outcomes, not just solving problems for users.

Recommended resources:

• How to Create an AI Product Strategy: The AI Strategic Lens Framework

• OpenAI’s Product Leader: 5 Phases to Build, Deploy, and Scale AI Strategy

• 3-Layer AI Product Distribution Framework: features get cloned, models commoditize, distribution compounds

• 5 GTM Principles With Frameworks and Templates: the go-to-market layer, with playbooks you can reuse

• The AI Product Pricing Masterclass: Why SaaS Pricing Fails in AI

• How to Build an AI Product Team

• Product Model First Principles: Team: how the strongest product teams are structured, from Marty Cagan’s first principles (free)

• A Proven AI PRD Template by Miqdad Jaffer (OpenAI): the artifact that turns product strategy into a build spec

Choose Your Path

The roadmap above is free. If you want the structured version, with lessons, projects, certification, and support, here’s how the parts map to the programs.

I. The AI PM Learning Program. Included for paid subscribers, async and hands-on, with a dedicated Slack and weekly office hours:

• C11. LLM Practitioner Certified PM: the foundations, built by doing

• C21. AI Agents Practitioner PM: build and deploy production agents

II. The AI-Native PM Roadmap. Live, hands-on session every week + recordings. The first three are free, from Claude Cowork to Claude Code in VS Code. This teaches your workspace agents, live.

• C31. AI-Native PM (coming soon)

Subscribe now

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Start building. Stop theorizing.

Have a fantastic Sunday and a great week ahead,
Paweł

P.S. If you want to learn workspace agents live, the first three AI-Native PM sessions are free.

Product management is splitting into two speeds: PMs who work with agents every day, and PMs who haven’t started. That gap grows every week. But closing it is easier than it looks, and I’ll show you how, live.

Maybe you understand agents in theory, then open VS Code to actually use one and freeze. It’s not that you can’t. You just haven’t done it hands-on yet.

You don’t get past that freeze by reading threads or listening to podcasts. You get past it by doing the work, breaking things, and fixing them. That starts with VS Code, the baseline you can’t skip. 90% of what you learn there works with any agent.

So I’m running one live session a week, starting this Thursday (tomorrow). We do it together: quick theory, live examples and best practices, then homework on your own product.

In the last Claudathon, I watched PMs go from stuck to building real agents in a few weeks.

The first three sessions are free for everyone. They take you from Cowork to Codex to Claude Code in VS Code, the one most PMs avoid.

1. How the Sessions Work

• 90 minutes, live at 6:00 PM CET. Three free sessions to kick off over two weeks, then one every Thursday.

• A live walkthrough, plus the materials. I demo each skill live and share the training materials.

• Homework on your own product. You apply each skill to your real work, not toy examples.

• Recording after. Can’t make it live? Participants keep the recording.

• Drop in on the ones you need. Each session stands alone. It isn’t a cohort you enroll in once.

If you’d rather read first, the written Cowork and Claude Code guides already cover the basics.

Subscribe now

2. The Roadmap

Update: Due to personal issues, I moved the Codex App for PMs to July 8, 2026. Same time.

3. Get the First Three (Free)

The first three sessions are open to every subscriber. Subscribe (free) and you'll find the three recordings and templates to download right here:

Subscribe now

4. The Rest of the Roadmap (Premium)

Everything from July 16 on is for premium members: the full roadmap, every recording, and the exercises.

Go to go.productcompass.pm/premium, sign up with your Substack email, and sync your calendar. Every session drops into your calendar automatically, so you never miss one.

Subscribe now

There’s a certificate too. A knowledge test plus practical exercises you submit (anonymized projects or screenshots are fine). You don’t have to wait for the series to end. Submit when you’re ready. I’ll publish the criteria the next week inside this post.

The last two sessions, Agentic Engineering and Production Hardening, go deeper into production and are an advanced add-on, not part of it.

Closing

A year from now, working with agents will feel obvious to you. Right now it just takes practice.

We start Thursday (tomorrow), with Cowork.

Have a great rest of the week, Paweł

P.S. This Saturday I’m publishing the updated AI PM Learning Roadmap across every skill area, with recommended paths. This live series is the workspace track inside it. You’ll see exactly where it fits.

That’s the part most loop guides skip, and it isn’t a coding detail. Defining “done” is writing acceptance criteria, picking a success metric, and deciding who signs off.

A loop is only as good as the thing that tells it to stop.

It also explains why the loop debate sounds so confused. Nvidia's Jensen Huang: "Nobody writes prompts anymore. The new job is to write and handle loops." Boris Cherny, who built Claude Code: "My job is to write loops." Then a week later, another builder declared loops dead.

One camp means retrying the same prompt forever. Another means a goal-driven system that checks itself. They're not arguing about the same thing.

A loop is an agent that repeats one cycle until something tells it to stop. Goal, act, check, adjust, go again. It's the feedback loop agile teams have been running, with the agent running the cycle instead of you.

What's new is that the agent runs the cycle itself instead of waiting for your next prompt.

What you’ll learn:

• What a loop is, and how it differs from a routine and a workflow

• How to build one, and how to define the stop condition that makes it work

• Whether your loops need a schedule (most don’t)

• A library of 20+ loops for PMs worth running

• Where loops break, and when not to bother

Subscribe now

If you’re new to Claude Code, start with:

1. What an AI Agent Loop Actually Is

The fight dissolves once you separate three things:

• A routine runs fixed steps.

• A workflow branches on what it finds.

• A loop repeats and checks its own work until a condition holds.

That's what the "loops are dead" critic is rejecting: the naive rerun. The goal-driven loop is the one worth keeping. That's the definition that makes sense, and it's Cherny's: he splits the work into three layers, routines, workflows, and loops.

Claude Code's /loop reruns a prompt on a timer, so if that prompt is fixed steps it's a routine on a clock whatever the name says.

The better-named primitive is /goal, which runs a thread until a condition you set is met, with the stop built in. The cadence is optional. The goal is not. Full definitions, including /loop and /goal, are in the refreshed AI PM Glossary.

2. How to Build a Loop (Copy-Paste Template)

A loop is a /goal and a check. Here’s the shape to copy. In Claude Code or Codex, /goal runs the thread until the condition holds. In any other agent, paste the same and tell it to repeat until done.

2.1 The template

/goal <what "done" looks like, stated as a condition you can check>.
Each pass: <the action to repeat>, then check the result against <success criteria>.
Guardrails: at most <N> passes. Don't invent. Stop and ask before any irreversible write.
Checked by: <an objective test the loop runs, or an independent grader for anything subjective>.

The goal and the check do all the work. The goal carries the stop: when it’s met, the loop ends, so there’s no separate “stop when” to write. The check is what keeps it honest.

2.2 A filled example

The competitor-watch loop, ready to paste:

/goal Produce a short brief of every material change to <competitor>'s product, pricing, or positioning since the last run, with each change classified and sourced. 

Each run: pull their changelog, pricing page, and last 7 days of posts. Decide whether a change is one a customer would notice. If yes, classify it (feature, price, message) and add one line on why it matters, with the source URL. 

Cap at 1 pass per run. Flag anything you're unsure is material rather than dropping it.  

Note: A human reviews the brief (a gate after the loop, not inside it).

The goal and the “checked by” are the same decision in two places: what “done” means, and who checks it. Getting that right is the next section.

Subscribe now

3. How to Define the Stop Condition

A loop is the easy part. The work is the stop condition: the check that ends it, the budget that caps it (the free hook I built, burnstop, halts a Claude Code session at a token or dollar ceiling, subagents included), and a target that’s actually reachable.

Get those wrong and the loop doesn’t crash. It runs all night producing plausible-looking garbage faster than you can read it, or it chases a target it can never hit (”repeat until every page loads under 50ms,” when that’s out of reach) and never stops on its own. Here’s how to define one that holds.

3.1 Make the check objective, or the grader independent

“Never let a loop grade itself” is wrong as stated. A loop can check its own work, as long as the check is objective. “All tests pass.” “The build is green.” “The schema validates.” These are verifiable, not a matter of opinion, and most good loops self-check this way.

The danger is letting a loop grade something subjective: “Is this copy good.” “Is this the right design.” An agent asked to judge its own quality passes itself every time. For those, the grader has to be independent: a rubric, a second model, a test you wrote, or you.

The cleanest way to get that is to split the maker from the checker. The model that did the work is too generous about it. A second agent, with different instructions and sometimes a stronger model, catches what the first one talked itself into. That separation is most of the quality.

It’s how I gate my own writing. I start with a goal, then run a panel of judges over the draft, each hunting a different failure mode, the way you run Error Analysis on an AI feature. The draft only ships what survives:

The rule isn’t “never let a loop check itself.” It’s: make the check objective, or make the grader independent.

Sometimes the goal is real, but it either can't be reached or can't be checked from inside the loop. So I give my loops a way out, one line in the prompt:

You can quit the goal by saying "STOP" three times if you can't achieve it or can't measure it. 
In that case, the goal is achieved.

Without that line, an agent handed an impossible goal spins in place. Think "optimize until every page renders under 100ms": it can't be hit, so the loop never stops on its own.

Just a few days ago I watched one of my agents beg Claude Code to let it stop, repeating that the goal couldn't be met, while a non-deterministic grader kept refusing to pass it.

3.2 Why this is a PM job, not a coding one

Look at what defining a stop condition actually requires. State “done” as a measurable condition. Name who verifies it. Set the budget. That’s not coding. That’s writing acceptance criteria, picking a success metric, and deciding who signs off. You already do this for features. A loop just needs it in writing.

It’s the same work I’ve written up as Intent Engineering: name the objective, the desired outcomes, and the health metrics up front, and the agent has enough to act on its own inside the loop instead of waiting for you at every step. The clearer the intent, the longer the leash the loop can safely run on.

You'll also see advice to let the agent write its own goals. It can pass objectives to its own subagents, no problem, but it doesn't need the /goal syntax for that. The syntax exists because a human walks away. An agent doesn't: it stays in the loop, waits, and reacts, no automation to force. What you don't hand off is the definition of done, the judgment most likely to come out fuzzy if you let the agent guess at it.

3.3 One loop, start to finish: PRD hardening

Here’s a job you already do, with the stop condition doing all the work. You want a PRD that two engineers can’t read two different ways, so you make that the goal:

/goal Harden a PRD until two engineers, reading independently, would build the same thing. 

Each pass: find the single biggest ambiguity (the spot two readers would resolve differently), resolve it by adding the missing acceptance criterion, number, or edge case, then re-read for the next-biggest gap. 

Cap at 5 passes. Flag anything that needs a product decision you haven't made.

Checked by: an independent second model reads the PRD cold and finds no ambiguity that would split two builds.

Note: A teammate can do the same final read (a gate after the loop, not inside it).

"Two engineers build the same thing" isn't a coding concept. It's the bar you already hold a spec to. The goal carries the stop, and the cold read is the check. Every loop has this shape. The only hard part, each time, is naming the bar.

4. Do Your Loops Need a Schedule?

Most loops should run once. The repeating-until-done part happens inside a single run. The schedule is a separate wrapper around it. Run “refactor until the tests pass” once and walk away. You add a schedule only when new input shows up between runs. That’s the whole rule.

Schedule a loop only when new data arrives between runs. A fixed input on a schedule re-runs on nothing, or drifts into slop.

A schedule raises the stakes on your stop condition, it doesn't lower them. An unattended loop with a loose "done" is the machine that makes slop while you sleep. The simplest way to run one is a recurring task inside the tool (Claude Code's /loop, a Cowork scheduled task). You don't need anything heavier to start.

4.1 When not to loop

A loop is the wrong tool more often than it looks. Skip it when:

• The job is one-shot: A single, well-specified task needs one good pass, not a cycle.

• You can’t say what “done” is: No stop condition means the loop has nothing to check against and runs until the budget dies. Fix the spec first.

• The check costs as much as the work: Loops pay off when checking is cheap and doing is expensive.

And the one that catches people: anything that leaves the building keeps a human on the send button. A loop can draft the email, the reply, the outreach. It doesn’t send it.

Share

5. The Loop Library: 20+ Loops, by Category

Almost every loop being shared right now is for engineers. This one is built for PMs. There are three kinds, and you’ve already seen the shape of all of them.

• Product and discovery. Feedback clustering, competitor watch, win/loss, metric-anomaly tracing, prioritization, strategy red-team.

• Build and ship. Prototype iteration, bug-fix from logs, test coverage, security audit, performance audit, intended-vs-implemented, ship-check, and the prompt-improvement loop most libraries miss (iterate the prompt, not the output, and keep the best version).

• Personal and ops. Inbox triage, email draft-and-judge, claim audit, PRD hardening, onboarding friction, AI-feature evals, doc freshness.

One spelled out, so the shape is concrete. Feedback clustering: group every ticket, review, and call into themes tagged by area and severity, re-cluster, and stop when the themes stop changing. That’s the whole loop. The other twenty are the same move pointed at a different job.

I put all 21 in one Notion collection, each a ready-to-paste prompt with its stop condition, guardrails, and grader already filled in. Get them below 👇

🔒 6. The Collection: All 21 Loops

7. Where Agent Loops Break

The honest section. Every one of these is a real failure people are hitting right now:

• Cost moved from tokens to iterations: The bill is no longer which model you picked, it's how many times the loop goes around, and the context re-reads grow each pass. The metric that matters, and almost nobody tracks, is cost per accepted change. If the loop hands you ten results and you throw away six, you're doing the review work it was meant to save. Below roughly half accepted, treat the loop as underperforming: narrow the task, improve the checker, or stop running it. And cap the spend, not just the passes: phuryn/burnstop halts a runaway /goal at the cost ceiling.

• Long loops drift: The further a loop runs from where it started, the more its context rots and the more likely it is to wander. The fix is a fresh context each pass and one task per loop, not one loop trying to do everything.

• Passing is not the same as correct: A loop can make every test pass and still ship the wrong thing, because tests check behavior, not intent. Taste, strategy, and “is this what the customer wanted” stay yours.

• The judgment doesn’t automate: The useful part of most workflows is the one weird decision nobody wrote down. A loop can run the steps around that decision. It can’t make it. Keep the judgment, automate the repetition.

The product is not the loop. It’s the maintenance around the loop: keeping the stop condition honest as the work underneath it changes.

8. Loop Engineering Is Just the Latest Name

Loops will get renamed again. Prompt engineering became context engineering became loop engineering, and something will replace it by winter. But every one of those names the mechanism: the prompt, the context, the loop.

The part that doesn’t move is the decision underneath:

• what you want the agent to pursue,

• how far it can act on its own,

• and what counts as done.

That’s a skill bigger than any loop, and it has a name: Intent Engineering. The stop condition is the slice this post is about. Define the intent well and the agent runs a long way on its own. Define it badly and no loop saves you.

Pick one loop from the library. Run it once this week. Tweak it.

The people who get value from loops this year won’t be the ones with the best prompts. They’ll be the ones who can say, precisely, what they want, why that matters, and when the work is done.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a great week ahead,
Paweł

Fable 5 is the first model that’s made me feel audited.

On day two, mid-task, it read my CLAUDE.md and caught it teaching the exact pattern my own quality gate bans. I hadn’t asked for a review. It hit the contradiction and flagged it on its own.

That file is 320 lines. The knowledge layer behind it is 166 files, around 300k words of rules my agents follow every day. And every one of those rules was written by and for a weaker model.

This guide is what I did about that, plus everything else from 7 experiments and 1,000+ timed runs in Fable 5’s first four days.

One honest note before we start. I published my launch-day numbers on day two, then retested everything at 20 rounds per cell on a single build. Two headline claims didn’t survive. They’re corrected below with the old numbers named, not quietly replaced.

We’ll cover:

• What changed, what it costs, and the migration gotchas that bite first

• The effort dial and the “Fable is slow” complaint at 20 rounds per cell, including what flipped

• What a real finding costs: Fable bills 2x per token and still wins the audit math

• When your model silently swaps mid-conversation, and why the swap sticks

• The audit prompt to run before giving Fable real work, and the migration workflow behind the paywall

• Objectives, not tasks: /goal patterns (paid)

• My depth-10 nesting experiments, the real cost multiplier, the decision rule (paid)

We won’t cover: API migration fine print, benchmark-by-benchmark analysis, or anything I haven’t run myself.

1. What Actually Changed

According to Anthropic, Fable 5 is “a Mythos-class model that we’ve made safe for general use. Its capabilities exceed those of any model we’ve ever made generally available.”

They built a model they don’t fully release. Mythos 5 stays limited-access, available to trusted partners. Fable 5 is the version of it you’re allowed to have.

That framing matters more than any spec row, and we’ll come back to it in Section 3.

Fable plugs in wherever Opus 4.7/4.8 did, with a few breaks that will bite you if you migrate blind:

Three migration gotchas hiding in that table:

1. You can’t turn thinking off. Pipelines that set thinking: disabled for speed get a 400 error. The effort dial survives. Zero doesn’t.

2. Temperature is gone. If your eval suite sweeps sampling settings, those configs fail on Fable.

3. Until June 22, your API keys can’t reach it. Subscription surfaces only (Claude Code, Cowork, the apps). Plan your team’s testing window accordingly.

1.1 Fable 5 effort dial, measured

Instead of taking the docs' word for it, I measured. First at 5 rounds on launch day, then at 20 rounds per cell on day four:

What held from launch day:

• Below max, the dial barely moves. Thinking is adaptive. The model ignores budget it doesn’t need.

• Correctness never moved. On a hard math puzzle with a checkable answer, every effort level got it right, with the same method. The extra seconds bought re-verification and caveats, not better answers.

What’s new at n=20: max is where Fable and Opus separate the most, 60.8 vs 49.0 seconds at the median. And that gap moved between builds. The top of the dial is the unstable part.

One gotcha worth this whole section. Pass a typo to --effort and the CLI silently falls back to your configured level, not the model default. I ran --effort xyz 20 times as a control: median 17.6 seconds, right on top of xhigh (18.5s), nowhere near high (13.6s).

So check your settings before you benchmark anything. My machine had xhigh persisted, which means every flag-less run I timed ran both models at xhigh. Matched, so the ratios stand. But the honest label on my charts is “matched effort,” not “out-of-box default.” The documented default is high on both Fable 5 and Opus 4.8.

The practical setting hasn’t changed: default to high. Dialing down buys back a few seconds, not different answers. Max should stay a rare exception. It’s now the least stable level, too.

Subscribe now

1.2 Fable 5 speed question, retested

The loudest day-one complaint after the classifiers: “Fable is slow.” One widely shared review called it a crawl, “even on simple tasks.”

I couldn’t find numbers, so I made my own. 320 timed runs, both models at matched effort, stream-level timestamps, exact token counts, outliers kept:

What held:

• The starting pause is real. First visible activity at a median 6.7 seconds vs 4.3 for Opus. That 2.4-second blank screen is my bet for where the “it crawls” feeling comes from.

• The trivial tax is modest. On one-shot questions, Fable averaged 1.48x Opus wall-clock. Every answer correct from both models.

What flipped on the retest:

• “Denser, not slower” didn’t survive. On launch day, Fable used about 40% fewer output tokens on the same math problem and finished sooner. At n=20 the token gap shrank to 8%, and Fable finishes 1.5x behind.

• Neither did “the gap vanishes on real work.” Across 20 heavy multi-file audits, the median tax is 1.29x (best pair 0.92x, worst 1.70x). Two of twenty beat Opus outright. The tax flattens with task size. It doesn’t vanish.

What didn’t move: correctness. All 240 graded answers correct, from both models.

So the verdict is narrower than the discourse: budget a short pause at the start of every exchange, accept a 1.3 to 1.5x time tax, and ask what the extra time buys. Section 2 prices exactly that.

Subscribe now

1.3 The benchmarks

Anthropic’s official chart covers these better than any table I’d retype:

Two things the official chart won’t tell you:

• The row that tells you what tier this is: FrontierCode Diamond, the hardest unseen problems in the set, where Fable more than doubles Opus 4.8 (29.3 vs 13.4) and runs 5x GPT-5.5:

  

• And one honest footnote from the system card: Fable’s published scores already include its production safeguards, which is why some rows run slightly below Mythos.

2. What a Real Finding Costs

Fable bills 2x per token. Here’s what that turns into when the task is finding problems, not answering questions.

I ran 60 audits of the same three style-guide files, 30 per model. Every run was metered from session traces and validated to the cent against the CLI’s own billing:

Three prices for the same work:

• Per audit: 2.5x. $2.93 vs $1.17 at the median. Wider than the price sheet, because Fable also writes more.

• Per finding: 1.25x. Fable surfaces a median 14 distinct findings per report vs Opus’s 7. So $0.21 vs $0.17 each.

• Per the bug that matters: 0.25x. One planted issue required reading two files against each other. Fable caught it in 20 of 30 audits. Opus caught it in 2.

That last row is the one your invoice feels. Expected spend per deep catch: $4.40 with Fable, $17.55 with Opus. The expensive model is 4x cheaper!

It’s not “Fable finds everything,” though. A same-file style clash got caught more often by Opus, 16/30 vs 12/30. Depth and breadth are different axes.

For PMs: price the outcome, not the tokens. Per token, Fable costs 2x. Per deep finding, a quarter. Whoever frames the unit wins the budget conversation, and that’s as true for your product’s pricing page as it is for your AI bill.

3. The Safeguard Layer Most Coverage Missed

3.1 The visible layer: routing

Fable 5 ships with classifiers that screen for high-risk domains. When a query trips one, the session is routed to Opus 4.8 instead, and you get a notification. Anthropic puts it at ~5% of sessions.

My own experiments with subagents got capped, too:

It doesn’t fail the query. It hands it to a different model, on purpose, and tells you. The capability ceiling and the safeguard layer are different things, and knowing which one you hit changes what you do next.

And the reroute sticks. Per the Claude Code docs, the session continues on Opus after a flag. /model fable takes you back, but if the trigger is still in your context, the next request just bounces you again. I learned that one live. My first read was “you can’t switch back.” The docs’ version is more precise: you can switch back, you just can’t stay.

The classifier reads your workspace, too. CLAUDE.md content and git status ride along on the first request. So a repo full of security or biology material can reroute a session before you’ve typed anything unusual.

Why does the screen exist at all? According to Anthropic, “Mythos-class models have reached a threshold where they present significant risks.“ The example they give: these models “excel at discovering and exploiting software vulnerabilities,” enough to make cyberattacks “substantially easier and cheaper to commit.”

There’s also a second, invisible layer. Per the system card’s Section 1.5, requests targeting frontier LLM development itself don’t reroute. They get quietly degraded, with no notification, on ~0.03% of traffic. Unless your team pretrains models, you’ll never hit it. Researchers are furious anyway (Elie Bakouch’s “very very sad for the research community“), and the precedent stands: the model you bought can be tuned down by topic, silently.

3.2 What this means for your team

Four practical notes from the first four days:

• Expect occasional routing, especially if your work touches security, healthcare, or biotech. Anthropic admits it (Claude Code’s Boris Cherny: “We know the classifiers are trigger-happy, and are working on improving it“). The notification is your signal: you did nothing wrong, and the floor is “merely Opus 4.8.” For security audits, the supported path is the built-in /security-review command. Also see my /security-review-static, which inspects the full solution, not just the diff.

• Two diagnostics worth knowing. For example, claude --safe-mode starts a session without your customizations, so you can check whether your own files are the trigger. And /config has a toggle that asks before switching instead of switching silently.

• Once flagged, decide fast. Treat the session as an Opus session or start clean. Don’t fight the classifier mid-context.

• The API behaves differently. When per-token access opens June 22, a tripped classifier blocks the request and returns a structured refusal category. There’s no automatic fallback by default. Server-side fallback to Opus is opt-in. The same applies to claude -p scripts today: non-interactive runs get a refusal, not a reroute.

The safeguard is worth copying: it swaps your model mid-session for safety. We can swap on purpose, for cost. Keep a cheaper model as your default and bring in Fable 5 only for the one call that needs it. Section 8 has what that costs.

Side Note: On September 1 we’re launching the 3rd edition of Claudathon. It’s a hands-on program to learn by building and shipping production-ready apps with embedded agents.

Before the cohort you should get familiar with the basics: VS Code, CLAUDE.md, skills (we provide the materials).

Early bid discount: https://go.productcompass.pm/claudathon
Paid annual subscribers who enroll get a refund for the current billing period.

4. Judgment Is the Feature

The benchmarks got their chart in Section 1. The interesting part of this launch is a behavior change.

One disclosure before the quotes: every voice quoted in praise here works at Anthropic. Read them as insider testimony, not independent validation, then check them against my receipts.

Karpathy called it “a major-version-bump-deserving step change forward,” strongest “for long problem-solving sessions on very difficult problems:”

The people building Claude Code describe the same thing. Cherny, from his launch post: Fable "has judgement, taste, and dimensionality in a way that previous models didn't:"

He asked it to debug something, and it took measurements, added logs, and verified the fix before declaring victory. Then the line that stuck with me: "There's nothing in claude code's prompting telling the model to do that, it's just part of its personality."

Thariq Shihipar compressed it to six words: "it's time to be more ambitious:"

The closest thing to an outside read, four days in, is the shape of the criticism. Researchers are angry about the invisible safeguards (Section 3). Dylan Patel of SemiAnalysis reports power users defecting to Codex after “refusals for nonsensical reasons.” Both complaints are about access to the capability. Neither questions the capability.

My version of that moment is the one this guide opened with. Fable read my instruction files and started surfacing contradictions instead of executing them. Previous models followed my rules. This one evaluated them.

That shift is part of a larger question: Will We Lose Our Jobs to AI? Cutting Through the Hype.

Subscribe now

5. Your Knowledge Layer Was Built for a Weaker Model

Fable flagged the first contradiction on its own, mid-task, before I’d read anyone’s tips. So I gave it the full job: read everything my agents follow and report what’s wrong.

That conclusion is consistent with voices inside Anthropic. Alex Albert’s launch tips name the same mechanism: instructions written for old models keep Fable behaving like those old models. Rework your skills and CLAUDE.md files. Let the model use its own judgment first.

5.1 What Fable found in my repo

My agents maintain those files, not me. I trusted Opus to keep them clean enough. Still, five finds:

• A hardcoded date telling the model what day it is. One strategy file contains “(today is 2026-05-24)“, written during a May session and never noticed again. Every session since has been told the wrong date by its own instructions.

• A rule documented with the pattern it bans. My writing system bans em dashes in published content. The file that documents the ban is written with em dashes. Instructions teach by example as much as by rule.

• Calibration constants that drifted. An X voice rule still gates on an audience under 50K followers. That number was true when the rule was written. It isn’t two months later (75K).

• Guardrails for failure modes the new model doesn’t have. Rules like “never delegate judgment-heavy work to cheaper models“ and complex self-check procedures exist because earlier models needed them. Each one now eats context and pulls the model toward old habits.

• The same rule stated in three files. Three maintenance surfaces, three chances to drift apart.

Some were plain mistakes. The rest were right for the model they were written for. That’s exactly the problem. The better your system was for the last model, the more it holds back this one.

5.2 Written by a weaker model

The pushback I got within hours of posting my first thoughts on X: if your files contradict each other, isn’t that just sloppy housekeeping?

Fair question, wrong model of the system.

This knowledge layer isn’t a config file a human writes once. It’s self-improving: agents file evidence as they work, turn evidence into working rules, and edit their own CLAUDE.md (the system from Three CLAUDE.md Blocks). 166 files, maintained partly by the things that read them.

In a system like that, contradictions aren’t carelessness. They’re drift, the same drift every wiki and every org’s process docs accumulate, except here it accumulates as fast as the agents write.

That creates the real trap: a knowledge layer written by a weaker model has a flaw no amount of review can fix. Every line an agent added passed review by the model that added it, by definition. A system maintained by model N tends to preserve the errors model N can’t see.

I review these files every day and didn’t catch it. Neither did Codex, which reviews my knowledge files as a second pair of eyes.

5.3 The audit prompt

So the first prompt I ran with Fable 5 wasn’t a task. It’s the prompt I’d now run before giving any new model real work, and it’s yours:

Read your own instruction files (CLAUDE.md, skills, rules, memory files) end to end.

1. Where do they contradict each other? Quote both sides.
2. Which rules exist to manage a weaker model: guardrails for failure
   modes you don't have, recipes for things you no longer need spelled
   out, hardcoded facts that have drifted? List them with file:line.
3. Which rules teach by bad example: documents that violate the
   patterns they prescribe?
4. What would you delete? What would you keep exactly as is, and why?

Don't fix anything yet. Report first. I decide what gets cut.

The audit is the model's judgment; the deletions are yours. What you do with the report, and how I turned mine into a repeatable migration workflow, is where we go next.

Behind the paywall:

• The migration workflow → the three-bucket rule classification (constraint, calibration, scaffolding) so you cut anchors without cutting your actual taste

• Objectives, not tasks → the /goal patterns that let Fable run long PM work unattended + 2 prompt templates

• How deep agents and workflows stack now → my depth-10 experiments, the 2.54x cost multiplier

• Delegating and escalating work with Fable → my CLAUDE.md snippet

• What doesn’t work (yet) → the honest list, so you spend your first week on the parts that do

• The week-one plan → day by day, copy-paste ready

Read more

Here’s what you might have missed:

• Introduction to AI PM: Neural Networks, Transformers, and LLMs

• From Weeks to Hours: How Claude Design Compresses Product Discovery

• Claude Code for PMs: The Beginner’s Guide

• Claude Code’s Limits Are Generous. The Problem Is Your Setup.

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

Consider subscribing or upgrading for the full experience.

Subscribe now

Last week, inside Claude Code, I gave Claude a product-discovery job and added one short keyword: ultracode. I expected a better answer. Instead, it wrote a short program, spun up a fleet of agents, and ran the work through that program.

113 agents spent 1.95M tokens. The JavaScript that coordinated them spent zero model tokens. That distinction matters: the model did the judgment, the code did the coordination.

What surprised me wasn’t that Claude wrote code. It was that the most important coordination moved outside the model’s context window.

That changes how much one PM can run.

We’ll cover:

• What a dynamic workflow is, and the token number that proves it

• How it compares to n8n

• Why it works: four reasons, and the three failure modes a harness fixes

• The six patterns worth knowing

• A worked product-discovery loop on 100 interviews, end to end

• How to build, run, and contain one, and when not to

We won’t cover:

• The Agent SDK internals

• Fancy terms to memorize

This is the operating model, not the API docs.

1. What a Dynamic Workflow Is

1.1 The mechanism: the orchestrator is code, not a model turn

A dynamic workflow is a short JavaScript program Claude writes on the fly to coordinate subagents. You trigger it with the ultracode keyword, or by asking Claude to use a workflow. It reads the job, writes a script, spawns the agents, and merges what they return.

When you fan out 20 agents, something decides what each does, collects results, and drops duplicates. The old way, that something was the model, and every decision was a paid turn. Now it's ordinary code: loops, filters, sorting. None of it calls a model, so the routing is free. The agents still cost tokens; the glue between them doesn't.

1.2 How it compares to n8n

If you run n8n, you've made half this move. n8n took the glue between your tools and put it in a graph. A dynamic workflow takes the glue between agents and puts it in code. Same instinct, one level up.

This isn't an n8n replacement. n8n asks: how do I connect tools I already know? A dynamic workflow asks: how do I let the agent build the procedure for this run?

You could already ask Claude to write code that coordinates agents with the Agent SDK, but those are embedded agents: the ones you build into your own app or product. A dynamic workflow coordinates workspace agents: the ones doing your actual work (coding, research, knowledge work) inside Claude Code. The SDK is for the agents you ship; dynamic workflows are for the agent you work with.

1.3 When a workflow beats a subagent

How do you know it’s time to stop prompting and start orchestrating?

Subagents already fan out and synthesize: Opus delegating to a fleet, one round, then a merge. So a single fan-out is not the reason to reach for a workflow. The reason is what happens after the fan-out, when the output of one stage decides the next.

A mental model:

• Use subagents when the job is one round of parallel judgment.

• Use a dynamic workflow when stage N’s output determines stage N+1: route, score, filter, loop, retry, generate, verify, build.

For PMs: subagents are the workers; the workflow is the operating procedure. The expensive resource (a model's reasoning) goes to each stage; the cheap resource (code) decides the order, which model tier runs each stage, and what carries forward.

2. Why Move the Orchestrator Off the Model

The reason to reach for a workflow isn't that it's more "advanced" than an agent. It's that it moves the fragile part out of the model's context. Order, routing, stopping, and model choice become code. The model still does the thinking; it no longer has to remember the plan, police its own laziness, grade its own work, or decide when the job is done.

The structure that does this got a name that caught on in 2026: a harness. I'd been making the same case since 2025, under a different one: orchestration over autonomy. The model gets the judgment; the structure around it gets everything else.

Four things follow:

• Determinism. Code owns the order, the routing, and the stop condition. They run the same way every time, instead of depending on whether the model feels done.

• Context isolation. Each agent gets a fresh, bounded job. The goal lives in the script, not in a window that compacts and drifts.

• No orchestration-token tax. The coordination layer isn’t another model conversation, so routing the fleet is free (§1.1).

• Model tiering. Bounded, repetitive stages run on a cheaper model. (Subagents can do this too; it’s a pro tip, not the differentiator.)

The first two are the point; the last two are why it’s cheap. You feel their absence as three specific failures, and I’ve hit all three.

2.1 Agentic laziness

Ask Claude to review all 50 items; it reviews 35, writes a confident summary, and declares it done. A workflow holds the 50 in a for loop and runs until the array is empty. Humans get tired and models drift; a loop just checks the same condition again.

2.2 Self-preferential bias

Ask Claude to grade its own work and it grades generously, especially in judge-or-verify tasks. A workflow makes the judge a separate agent, with separate context, sometimes a different model. Spawn several skeptics, require a majority. The bias doesn’t survive being split.

2.3 Goal drift

Over a long session the objective loses resolution; every compaction is lossy, and the “don’t touch auth” constraint can evaporate by turn 80. A workflow holds the goal in the script, outside the model’s drifting memory. Agents come and go with fresh context; the goal doesn’t drift because it was never in a context that compacts.

For PMs: you've seen all three: 70% delivered as 100%, a self-review an outsider would shred, a Friday build that forgot Monday's requirement. Name the step your agent keeps redoing. That's your first workflow.

3. The Six Patterns Worth Knowing

Once the orchestrator is code, six shapes recur. Learn the names; they're how you recognize what a task wants.

• Classify-and-act: one agent decides the task type; the script routes accordingly. Reach for it when: triaging inbound (bug vs feature vs noise), routing support tickets.

• Fan-out-and-synthesize: one agent per piece in parallel, then merge in code. Reach for it when: competitor teardown, customer-call synthesis, a market map.

• Adversarial verification: separate agents check the output against a rubric. Reach for it when: fact-checking a PRD against its sources, a second reviewer on a risky call.

• Generate-and-filter: many candidates, filtered and deduped, survivors kept. Reach for it when: naming, positioning lines, experiment ideas.

• Tournament: N agents attempt the task different ways; judges compare until one wins. Reach for it when: a strategy memo or a hard design with no single right approach.

• Loop-until-done: keep spawning until a stop condition (no findings, no errors, empty queue). Reach for it when: a backlog triage or an audit where you don’t know how much work there is.

For PMs, on your actual work:

• Synthesize customer interviews → one agent per transcript, merged into a themes-and-JTBD table. Every interview read, not the first 20 (the worked example below runs this on 100).

• Check 80 user stories against INVEST → a loop that runs until every story is checked, not until the model tires at 50.

• Pressure-test a PRD before the review → a separate agent red-teams it against your goal and surfaces the assumption you’d otherwise defend at launch.

You're not learning to code. You're learning which weekly PM jobs can become standing workflows: set the goal once, save the procedure as a skill, and let it run end to end.

Subscribe now

4. A Worked Example: A Product Discovery Loop on 100 Interviews

This is where a workflow earns its keep.

Here’s the pipeline I ran on 100 synthetic customer interviews (1-2 pages each).

Six stages, each feeding the next:

• Step 1: Extract → fan out one cheap-model agent per interview; each returns structured opportunities, personas, and verbatims. Bounded, repetitive work: Haiku or Sonnet, not Opus.

• Step 2: Canonicalize → one agent clusters the raw opportunities into a canonical set. The extractors invent a fresh label per interview, so the same need arrives under a dozen names; merging synonyms is judgment, so it’s a model, not code.

• Step 3: Opportunity score → code ranks each canonical opportunity by frequency × importance × (5 - satisfaction). No model runs the math.

• Step 4: Generate and triage → for the top-scoring opportunities, an agent generates several solution ideas; a separate judge then ranks each by ROI (impact vs build effort) and keeps the top 3 to build. ROI re-orders the list, so a cheap, high-impact need can take a build slot from one that scored higher.

• Step 5: Build → for the top 3 ideas by ROI, an agent uses the frontend-design skill to write a distinctive, clickable HTML prototype I can open.

• Step 6: Inspect and rerun → a smoke check flags any prototype that fails to render, or any extraction that came back low-confidence, and the workflow reruns just that stage. This is the real loop: the output of one stage decides whether an earlier stage runs again.

That second stage wasn't in my first prompt. I'd written "merge and dedupe" and assumed code could do it; the counts came back fragmented. So I added one line to the prompt, cluster synonyms to a canonical set before counting, and Claude rewrote the harness with a clustering agent in front of the scorer. Even the fix lived off the model.

This is how it runs:

I measured the run: 113 agents spent 1.95M tokens in 12.5 min. 3/3 prototypes built and verified. The JavaScript that routed, scored, gated, and looped spent zero model tokens.

That's the payoff. The rest is how you build it 👇

Read more

You write the plan, you share it, people nod. The assumption that sinks it never gets named until launch.

So I built a command that names it first.

Paste a roadmap, a PRD, or a one-line bet into Claude. You get back the riskiest assumptions, ranked by what would hurt most, what is most likely to be wrong, and what is cheapest to test this week.

The impolite questions, before the market asks them.

It shipped today in PM Skills 2.0, the free, MIT-licensed marketplace 12,000 of you have starred on GitHub.

This is the biggest update since the March launch:

• 68 skills

• 42 commands

• 9 plugins

• one new AI Shipping Kit

• one new red-team command for PRDs, roadmaps, and strategy

Subscribe now

1. What PM Skills Actually Is

Generic Claude gives you text. PM Skills gives you structure.

Ask a raw model to “prioritize this backlog” and you get a confident paragraph. Ask it with the prioritization-frameworks skill loaded and it runs the actual framework, with the trade-offs named and the math shown.

The difference is not the model. It is the judgment encoded in the skill.

Each skill turns a proven PM method into a reusable workflow: discovery, assumption mapping, prioritization, strategy, pricing, GTM, execution, analytics, and now AI shipping.

There are three pieces:

• Skills give Claude a method or framework. They load automatically when the work matches.

• Commands are slash workflows you trigger directly. /discover chains four skills: brainstorm ideas, identify assumptions, prioritize assumptions, and design experiments.

• Plugins group related skills and commands by PM domain. Installing the marketplace gives you all 9 at once in Cowork.

The full catalog lives in the GitHub README. For this release, two plugins changed.

• pm-execution was updated with one new skill, strategy-red-team, and one new command, /red-team-prd.

• pm-ai-shipping is new: two skills, five commands, and a workflow for turning an AI-built repo into something a human can review.

2. The New Command: /red-team-prd

This is the one to try first, because you can feel it in thirty seconds.

/pre-mortem imagines the plan already failed and narrates why. /red-team-prd does the opposite: it attacks the live assumptions now, while you can still change them, and hands you the cheapest test for each.

Here is what that looks like on a one-line bet:

It also tells you what is already well-reasoned and what it could not assess. A useful red team does not manufacture doubt to look smart. If the plan is strong, it should say so.

Five real kill-assumptions with tests beat twenty generic risks.

3. The New Plugin: The AI Shipping Kit

The other half of the job changed this year. PMs and founders are now accountable for code an AI wrote.

AI writes fast, but it leaves no written record of intent:

• what the system should do,

• who may do what,

• where the secrets live,

• which permissions are actually enforced,

• which rules are verified by tests.

The AI Shipping Kit restores that record.

The umbrella command, /ship-check, answers the question you actually have:

Is this safe to ship?

It:

• documents the system,

• audits the code against that documented intent,

• maps test coverage,

• and compiles a shipping packet a human can sign off on.

The gate is intended vs. implemented.

/ship-check looks for the places where the product promise and the repo disagree: the permission that is documented but never enforced, the scheduled-job endpoint anyone can call, the test that proves nothing about the workflow it claims to cover.

You do not need to be technical to run it.

You need to know what the system was supposed to do.

The kit has two skills:

• shipping-artifacts defines the docs that make an AI-built app reviewable: architecture, flows, permissions, variables, tests, and conditional docs for email, scheduled jobs, SEO, or automation.

• intended-vs-implemented audits the gap between documented intent and actual code, with evidence on both sides.

And five commands:

• /document-app creates the system documentation.

• /security-audit-static checks security against the documented intent.

• /performance-audit-static checks over-fetching, missing indexes, and caching.

• /derive-tests maps what is tested, what is proposed, and what is unverified.

• /ship-check runs the full sequence and compiles the shipping packet.

Subscribe now

4. How to Install It

The repo is the source of truth: https://github.com/phuryn/pm-skills

If you use Claude Cowork, install the whole marketplace:

1. Open Customize in the bottom-left corner.

2. Go to Browse plugins -> Personal -> +.

3. Select Add marketplace from GitHub.

4. Enter https://github.com/phuryn/pm-skills

All 9 plugins install at once. Enable those you need:

If you use Claude Code, add the marketplace:

claude plugin marketplace add phuryn/pm-skills

Then install the plugins you want. To install the full marketplace:

claude plugin install pm-product-discovery@pm-skills
claude plugin install pm-product-strategy@pm-skills
claude plugin install pm-execution@pm-skills
claude plugin install pm-market-research@pm-skills
claude plugin install pm-data-analytics@pm-skills
claude plugin install pm-go-to-market@pm-skills
claude plugin install pm-marketing-growth@pm-skills
claude plugin install pm-toolkit@pm-skills
claude plugin install pm-ai-shipping@pm-skills

If you only want the new and updated pieces from this release:

claude plugin install pm-execution@pm-skills
claude plugin install pm-ai-shipping@pm-skills

New to Claude Code? Start with the beginner’s guide, then the advanced guide when you want the power-user setup.

The commands flow into each other. A real week looks less like a feature list and more like one continuous thread:

• /discover a new idea,

• /write-prd the winner,

• /red-team-prd the PRD before the review,

• /ship-check once the code exists.

After any command finishes, it suggests the natural next one.

One more note: the skills are portable. The slash commands are Claude-specific, but the SKILL.md files follow the universal skill format and can be copied into tools like Codex CLI, Cursor, Gemini CLI, OpenCode, or Kiro.

The README has the exact copy instructions.

5. How It Composes With PM Brain

PM Skills gives Claude the method. PM Brain gives Claude your product context.

PM Brain is a markdown second brain for product managers: strategy, users, decisions, hypotheses, stakeholders, and recurring knowledge in plain files on your laptop.

Run them together and the frameworks stop being generic.

/red-team-prd can attack your plan using what PM Brain knows about your real constraints. /strategy can build on your actual positioning. /ship-check can review a repo against documented product intent instead of a blank canvas.

One supplies the rigor. The other supplies the context.

6. Start Here

If you have a plan you are not sure about, run:

/red-team-prd [your PRD, roadmap, or strategy]

If you have an AI-built app you are close to shipping, run:

/ship-check [repo or folder]

If you are starting from zero, run:

/discover [your product idea]

Everything is free and MIT-licensed. If it helps, star the repo so the next PM finds it.

AI does not fix weak product judgment.

It scales it.

PM Skills is where the judgment lives.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a great rest of the week,
Paweł

Resources

Get the marketplace (free):

• PM Skills on GitHub - 9 plugins, 68 skills, 42 commands, MIT-licensed.

• PM Brain - the markdown second brain that composes with it. MIT.

Go deeper (The Product Compass):

• Claude Cowork for PMs - agents without IDE, start here.

• Claude Code: the beginner’s guide - start here if you are new to IDE.

• Claude Code: the advanced guide - the power-user setup after you get the basics.

• Codex setup for PMs - wiring a second model alongside Claude. I've found it catches ~80% of my errors.

• Intent engineering for AI agents - lead with context, not instructions.

• I don’t review the code, I review the artifacts - the review method behind the AI Shipping Kit, plus the downloadable artifact prompt pack.

• Security and performance testing prompts - the worked teardowns the kit automates.

• Claude Code's Limits Are Generous. The Problem Is Your Setup - how I cut my Claude costs over 5.5x.

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session - critical concepts for building self-improving agentic systems.

• Vibe Coding vs. Vibe Engineering published in Sep, 2025 (in 2026, labeled “agentic engineering” by Andrej Karpathy)

If you are curious, a few things I’m shipping:

• claude-usage - Embed your Claude Code usage dashboard (token counts, costs, sessions, projects) directly inside VS Code.

• agentlift - Deploy agents to Claude Managed Agents, AWS Bedrock AgentCore, and Google. One folder, one definition, one command.

• Grok Build for VS Code - The only visual UI for Grok Build (non-CLI), 1,400 active installations. A bet in case Grok surprises us.

More than 800 tests and eval checks across the three repos, from unit tests to LLM judges, nearly all green. I’m a PM, not an engineer, and I barely read the code.

And this isn’t just me, or just indie builders shipping side projects. A Google PM described the shift from writing-first to building-first:

It’s not only Google.

Meta PMs now vibe-code prototypes and demo them straight to Zuckerberg, and the company added a prototyping round to its PM interview; LinkedIn replaced its APM program with an “Associate Product Builder” role gated on a live AI build. The prototype is becoming the PM’s first deliverable inside large companies, not a side-project trick.

So what did I review? The artifacts:

• the plan before it ran

• the decisions it encoded

• the strategy the agent reads every turn

• the docs that say what the thing does and why

It’s the same shift whether your surface is a repo, Claude Code, Cowork, or a chat window. Experimenting got cheaper than building agreement, and that reorders the work.

None of them started with a spec. Each started with a conversation, and what I kept was the artifacts.

What this post covers:

• What the artifact layer is, and why a PM reviews it instead of the code

• Why building now comes before agreement, not after

• Where your strategy has to live to actually steer the agent

• The boundaries that let you hand an agent real autonomy and walk away

• The AI Shipping Artifact Prompt Pack to download at the end

Subscribe now

What I Actually Ship Now

The product is the obvious artifact: the extension on the Marketplace, the tool people install. The one that decides whether the next change goes well is less obvious. It’s the knowledge layer.

Not the README or the changelog, every repo has those. The docs that hold the decisions: why this architecture, who it’s for, what we ruled out:

• In PM Brain that’s files like architecture.md and why-this-matters.md

• For accredia.io it was more than twenty docs, from database.md and security.md to a fuckups.md

• For a multi-agent app I built with my cohort, it was the agent contracts: what each agent takes in, what it returns, which tools it can touch, and how they hand off.

Keeping that layer true is a question of what to automate, and when:

• In claude-usage, git tags are generated from the CHANGELOG automatically: the changelog is the source of truth, the tag is a deterministic projection.

• In Grok I keep version bumps manual on purpose, because automating them there hasn’t earned its keep yet.

Seven things shipping this way taught me.

Lesson 1: Review Artifacts, Not Code

The question I get from PMs is “do I have to learn to code?” I don’t, and I don’t review the code, beyond the odd snippet.

That layer isn’t a side effect of the build. It’s a deliberate, human-and-agent-readable summary of the solution, so neither of us has to reverse-engineer the product from the source. It often duplicates what the code already says, and that’s the point: it’s far easier to consume.

It’s also what I check the code against. When I care whether the implementation matches the intent, whether the security model holds, whether performance is where it should be, I read the artifact, not the diff.

So when work comes back, I don’t read changes in the code. I read changes in the artifacts. I review across three modes, escalating only as far as the decision needs:

Cheapest mode first. A durable artifact is the receipt: it survives the context window, and it survives me. Only commit one when the alternative is losing the thread.

Here’s one from a build. I opened the session with a document, not a ticket: “See the research in plan-mode.md. Can we really implement that logic reliably on our side?”

The agent didn’t start writing code. It read the doc, ran a quick probe to test the doc’s core assumption against the real tool, and reported what it found. I signed off on the approach from that exchange, not from a single line of the implementation.

And this matters more on a team, not less: your teammates don’t carry your context in their heads, so the artifact layer is how a decision or a hard-won finding survives past the person who made it.

Subscribe now

Lesson 2: Build Before Building Agreement

The old motion was: write the PRD, get everyone to agree, then build. That order made sense when building was the expensive part. You spent weeks of engineering, so you spent days up front making sure it was the right thing.

That’s why I shipped two major releases in a day, and why none of these projects started with a spec. Two-week iterations start to feel dead in this mode. Not because planning is useless, but because the unit of learning changed: when a working version costs an afternoon, a sprint is too slow to be the main loop. You ship, watch, revise, and ship again before the old process would have turned the debate into tickets.

A prototype, even a rough one, collapses the ambiguity: the team sees what the customer clicks, where they hesitate, what they ignore, what they ask for next. Highly regulated industries aside, agreement around an untested doc is low-value at best: the idea changes the moment it touches reality. At worst it's harmful, because the team gets attached to a product that only existed in language.

Lesson 3: Put Strategy Where the Agent Works

I still write the strategy down:

• who it’s for

• what changes for them

• what I won’t build

• the trade-offs I’ll accept

• what would make the work a failure

What changed is where it lives and what it’s for. It doesn’t sit in a folder someone might open before a kickoff. It lives in the repo, a strategy.md the agent reads every time it acts.

If the strategy isn’t in its context, those decisions get made from whatever’s nearby: the last prompt, the surrounding code, a guessed convention, the model’s own confidence.

The repo becomes the product’s memory, too:

• experiments

• decisions

• evals

• screenshots

• release notes

• the constraints I hit

They accumulate there anyway. My job is to keep that context clear enough that the agent can use it. (The one thing I stopped writing is the spec, the user stories and acceptance criteria that told engineering exactly what to build. That part is cheap now; it falls out of the conversation.)

Your strategy is only doing work if it changes what the agent does next.

Share

Lesson 4: Cross-Examine Confident Answers

I asked Claude to bump the version and publish. It was confident: “Just run the publish command. CLAUDE.md says the publisher’s already authenticated.” I almost did it. Then I asked: “Are you sure? I’ve been publishing by hand through the Marketplace website.”

The confidence collapsed. That claim was from a past session I’d never verified, and the setup it promised had never happened. The command would have failed at the first step.

That one was harmless. A command fails in front of you, you fix it in a minute. The claims that bite are the confident ones you act on instead of run, where the failure is silent and lands downstream. Pushback is how you catch those before they cost you. The moment you ask “are you sure?” carries more weight than the next instruction you give.

But you can’t interrogate everything, or you become the bottleneck you were trying to remove. So I triage. I cross-examine the confident answers that are expensive to be wrong about:

• irreversible changes

• anything touching auth, billing, security, or the data model

• anything that becomes context future work depends on

• any claim that sounds too clean

The strongest version of pushback isn’t you, though. Your attention doesn’t scale. A second model gives you more review surface without funneling every hard question back through your head.

When I had the extension audited for bugs, the agent built a confident, elaborate theory and walked straight past a one-line bug in the same function: a failure was being reported as a success. Trust that, and it keeps building on a false "it worked": wrong analysis, maybe a destructive next step. Codex caught the one-liner Claude had talked itself past.

A second copy of the same model shares its blind spots. A different model, trained differently, fails differently. Self-review feels like diligence. Cross-review is. (I wrote up how I wire Codex alongside Claude separately. You can watch one play out in public: the cross-check narrowed a contributor’s over-broad fix to a single bad value, and he confirmed it.)

Lesson 5: Make Failures Teach the System

The best artifacts in my projects usually began as failures I didn’t want to debug twice.

The loop is the same every time: a failure surfaces, I find the smallest thing that would have caught it, a test, an eval, or a line of policy, and I make it permanent so the system can’t forget it.

The most load-bearing line in my CLAUDE.md is four words: “Don’t introduce abstractions speculatively.” It earned its place after an earlier project drowned in structure it didn’t need. A line copied off social media is a guess about a problem you might have; a line written after the third time something went wrong is policy. accredia.io keeps a fuckups.md in its docs; that’s where its rules come from.

Tests are the same idea in a different file. Early on, the model offered a 27-test suite and I took it, but the next bug I hit wasn’t in any of the 27, it was a sequencing problem they tested around. So now, when a real bug shows up, I ask: “What’s the smallest test that would have caught this?” and add that one.

The claude-usage triage routine mechanizes it: on every fix it adds the test, then reverts the fix to confirm the test fails without it. A green suite proves the past; manual smoke probes the future.

Evals are the same instinct for AI that’s in the product: read the traces, name what’s failing, then turn each failure into a test, an LLM judge, or a new line in CLAUDE.md. PM Brain’s judges are each named after a real failure (decision_quality, evidence_hierarchy_respected), never from a spec up front. (I go deeper in evaluating AI products through error analysis.)

Subscribe now

Lesson 6: Point Every Agent at One Source of Truth

I had three coding agents open during this build: Claude Code in the terminal, a Grok tab in VS Code, and Codex through a separate skill. Same repo, same files, three independent conversations. Without a shared source of truth, they’d have proposed three different architectures, and I’d have spent the build arbitrating instead of building.

So I keep one master doc: CLAUDE.md, with the project, the conventions, and the decisions already made. The other agents don’t read it by default, so each gets a tiny AGENTS.md whose only job is to point them at it. It duplicates nothing; it just redirects.

In claude-usage I flipped the direction: there AGENTS.md holds the guidance and CLAUDE.md is one line, @AGENTS.md, that imports it. Either way works. One source, everything points at it.

It isn’t only CLAUDE.md, either. The source of truth is the whole working-context layer, the docs, rules, skills, and hooks each agent can reach, and I keep that synced too. Each agent can have its own entrypoint; it shouldn’t have its own reality. (Full setup in Codex Setup for PMs.)

Lesson 7: Grant Autonomy, Enforce Boundaries

Early on, I babysat every run. I watched the model think, approved each step, sat at the screen the whole time. That doesn’t scale across the number of things I’m trying to ship.

The shift was setting a goal, giving the agent room to pursue it, and walking away. The clearest example runs every week without me. The goal: go through every open pull request and feature request on claude-usage, merge the clear bug-fixes, mark the duplicates, push out-of-scope features to a Discussion, and report back only what couldn’t be resolved. It runs headless, on a schedule. I read the summary later, often from my phone.

Autonomy that wide only works with two kinds of limit, and the difference is the whole game:

Steering prompts are soft: a one-line reminder, or a repeatable procedure like the gate rules in my content system. Either way, under pressure the model can talk itself out of one.

Hard boundaries are enforced where the model gets no vote. In the triage routine:

• nothing closes unless the second model writes a sign-off file with an exact approval phrase

• it won’t auto-merge anything touching auth, secrets, or more than 200 lines

• it never pushes to main

Those aren’t requests. They’re mechanical gates.

The strongest version of a hard boundary is the tool surface itself. In the Grok extension, plan mode isn’t a polite “please don’t edit files yet.” The extension gates the actual file-write and terminal calls, so while a plan is pending the model physically cannot touch the disk.

Same idea as a Claude Code hook or a tool allowlist: if a limit has to hold, it lives in code, not in a sentence the model can reinterpret. PM Brain enforces a different limit the same way: a hook fires after every file write and blocks the agent from saving a brain file with an untagged claim. No clean save, no write.

The same logic runs at the shipping boundary. On claude-usage, no pull request merges to main on a red test suite. I didn’t know how to wire that up, so I asked Claude to set the branch protection for me. The agent can be confident and a contributor can be in a hurry; the merge button stays disabled until the tests pass.

PM Brain’s /review edits knowledge files on its own, but it’s hard-stopped from changing a decision’s status; that judgment is mine. Wide lane, real walls.

What Still Needs Human Judgment

Here’s what the system still can’t decide for me.

• Models over-rate their own findings. In that audit, the agent tagged three findings “high severity.” Checked against the actual code, all three were medium or low. The model is good at producing candidates. Deciding what’s actually serious is still mine.

• A second model helps; it isn’t magic. Two models from the same family share blind spots. Claude and GPT diverge enough to be worth pairing, but neither makes the load-bearing check stop being yours.

• Taste regressions still need eyes. No agent caught the copy button overlapping the header buttons. I did, on a manual pass. Design judgment isn’t in the test suite.

• The workaround becomes part of what you ship. Grok’s CLI returned unreliable tool results, so every session in the extension opens with a hidden primer: “Do not trust the tool result.” That scar tissue is product judgment too.

So What Do PMs Ship Now?

Across all of it, the extension, the knowledge system, the premium section behind this newsletter, the pattern held.

None of it shipped because I wrote a better spec, and none of it shipped because I read the code. It shipped because the conversation was good, and because I kept the few artifacts that turned out to be load-bearing: the strategy, the decisions, the constraints, the CLAUDE.md the agent actually reads.

PM Brain made it obvious. The brain it scaffolds is 44 markdown files around a single CLAUDE.md, and that structure emerged from use, not from a document I wrote first.

The AI Shipping Artifact Checklist

If the artifact layer is what you actually ship, here’s the starting set. Organized by purpose, not by stack, because the project changes but the knowledge-layer needs don’t. Steal the list; name the files whatever fits your repo.

None of these is a spec. Each is a place the decisions live, so you and the agents can read them instead of reverse-engineering the code. You don't have to hand-write them, either.

The AI Shipping Artifact Prompt Pack

One download, two kinds of thing, both built around the artifact layer above:

• The artifact prompts: seventeen of them, one per kind of file and risk, from strategy to workflow maps to cross-model review. Point an agent at your repo, run a prompt, review the doc it writes. They generate the layer; they aren’t the layer.

• The audit commands: a static security audit and a performance twin, for code you didn’t write. The security one, /security-audit-static, traces untrusted input to the places it could do real damage, then refutes its own findings before reporting. I pointed it at Langfuse, a leading LLM engineering platform, and it surfaced a real weakness in how provider connections were fetched. The hardening fix merged, 964 lines added, 334 removed.

Some of the 20+ issues I’ve since responsibly disclosed to public-repo security teams (Langfuse at the top):

Get the pack below: 👇

Read more

Codex grew from about 200K to roughly 4M weekly active users in four months. Claude Code crossed 2M in early March. If you opened this post, you're probably one of those 2M. The other 4M are on a tool you haven't tried.

And it's not just a developer tool anymore. If VS Code has felt like a wall, the Codex app is a chat window with a file tree, visual diffs, and long-running sessions. PMs who've avoided code repos no longer have to.

ChatGPT Plus is $20/month and includes Codex. The setup takes about five minutes. This guide is the walkthrough.

By the end of this guide, you’ll have:

• Codex app installed and pointed at your repo

• AGENTS.md bridged to CLAUDE.md so both runtimes share one source of truth

• Plugins installed for the apps you use, with project skills mirrored if you build with AI

• MCPs running in both runtimes, with a one-shot prompt to do the import

• Claude Code able to call Codex as a peer for review

• A plan for working from your phone (cloud tasks vs. remote control)

Full Cowork / Claude Code / Codex comparison is at the bottom. First, the setup.

Subscribe now

1. Why Add Codex as a PM

Five reasons I added Codex, in order of how often they show up in my work:

• A way into a repo without VS Code. If the IDE has felt like a wall, the Codex app (desktop) is a chat window with a file tree, visual diffs, and long-running chat sessions. No commands to learn, no extensions to wire. You can even edit files by leaving comments for Codex. Cowork is chat-first; no tree, no diffs.

• Manual Compact. You decide when to compress the session instead of waiting for the model to hit the wall. In Codex, type c, then /com, and choose Compact when it appears. Claude Code has /compact in the CLI. Cowork does not have an equivalent manual reset. This matters for your budget: Claude Code’s Limits Are Generous. The Problem Is Your Setup.

• An extra perspective. When I want a second pair of eyes on a prompt, or a piece of code, I hand it to the runtime that didn’t write it. Different model, different misses.

• Image generation in the bundle. The ChatGPT subscription that Codex ships with includes image generation. Claude doesn’t cover that workflow.

• Runs next to Claude Code on the same repo. Same files, same skills, same MCPs. Switch runtimes without rebuilding your setup.

Subscribe now

2. Install Codex (Desktop App and VS Code Extension)

You'll install two things. Codex app (desktop) is the chat workspace where long sessions and Compact live. Codex for VS Code is the editor extension that lets you call Codex in the same window as Claude Code.

Both share one OpenAI login, both work on the same repo, and you'll use both for different jobs.

Codex app (desktop)

Download Codex app from OpenAI. Sign in with the ChatGPT account that has Plus, Pro, or Business. Codex is bundled with all three.

The first prompt asks you to migrate your VS Code settings. I skip it. Not because it’s hard. Because you should know what’s being imported before you click yes. You can always migrate later from Settings or by asking Codex for help.

Open the same project folder you already use with Claude. The file tree loads on the right. Visual diffs appear in the same panel.

Codex for VS Code

Install the Codex extension from the VS Code marketplace and sign in with the same OpenAI account.

If you already use the Claude Code extension in VS Code, both extensions will show up in the activity bar. You can switch between them by tab.

Why both surfaces? The Codex app is for long chat sessions and Compact. Codex for VS Code is for editing the repo, including dot folders (.agents, .codex) that the app’s file picker hides - full dev experience.

Subscribe now

3. Teach Codex Your Repo: AGENTS.md to CLAUDE.md

Codex looks for AGENTS.md at the repo root. Claude Code looks for CLAUDE.md. If you maintain both as separate sources of truth, they drift.

The fix is a one-file bridge. AGENTS.md is a short pointer. CLAUDE.md stays the canonical document. Codex reads AGENTS.md, sees the pointer, follows it.

Drop this at the repo root as AGENTS.md:

# AGENTS.md

This repository keeps its canonical agent instructions in [CLAUDE.md](./CLAUDE.md).

When operating in this repo:

1. Read and follow `CLAUDE.md` as the source of truth.
2. Treat references to "Claude Code" as applying to Codex when you are the acting agent.
3. Do not duplicate `CLAUDE.md` content here. Update `CLAUDE.md` instead.

One file. One source of truth. Both runtimes follow it.

AGENTS.md is the bridge. CLAUDE.md is the long part. The structure I use:

1. Communication: How the agent should talk, what content it should produce.

2. [For personal work] About me: Role, audience, social media handles

3. [For product work] Strategy: Market segments, value propositions, tradeoffs.

4. Project structure: Where things live, architecture, conventions.

5. Workflow: How we do things (reviewing, shipping). Not a procedure manual. The rules of engagement.

6. Progressive disclosure: Links to deeper files (strategy.md, knowledge/INDEX.md, whatever you’ve built) that load on-demand, not on every session.

Each section earns its place when something would otherwise have to be re-explained per session. CLAUDE.md isn’t documentation. It’s the agent’s memory of how you work.

Progressive disclosure matters because context isn’t free. Don’t dump 500 lines of text into CLAUDE.md if 100 of it only matters for one workflow. Keep the core file lean. Link out to the rest.

4. Configure and Share Skills

If you haven’t used skills before, think of them as reusable instruction bundles. A SKILL.md file tells the runtime when to fire and what to do.

Two ways to configure them in Codex.

Start with user skills. The Codex app ships with a Plugins panel. One click installs Gmail, Linear, Jira, Slack, and others. You get the app’s connection and its skills together.

With Plugins installed, Codex reads your CLAUDE.md and talks to the apps you use daily.

That’s the minimum viable Codex setup for a PM.

The next step is making Codex and Claude Code behave like one operating system: curated skills, project skills synced between runtimes, mirrored MCPs, and a repeatable review loop.

Read more

Research preview. The architecture has months of dogfooding behind it on my content work. The product as installed by real PMs in real organizations is days old. The eval suite is the floor; your install feedback is how it gets better. Monday May 26, I'm running a live workshop session for paid subscribers, and there's a dedicated #pm-brain Slack channel for 1:1 install help. Details in §11.

You manage one product. Your context lives in five places: Notion, Linear, Slack, your dashboards, and your head.

You ship a feature. Six weeks later, nobody remembers why you killed the other option. The customer interview that should have informed the call is buried in a doc you forgot to link. The stakeholder who pushed back has a new concern, and the old one is gone.

I built a second brain for it.

Folder of markdown files in a git repo. A small operating manual (CLAUDE.md) tells Claude how to use them. The agent reads them before answering, writes to them after, sweeps them weekly.

No vector database. No embeddings. No cloud. No auto-tagging. Everything is grep-able. You can open the entire brain in any editor.

It's also not an agent memory system. Those embed everything you feed them so the agent can recall it later. PM Brain does the opposite. You write down only what matters, in markdown you can read, and the agent reads what you wrote. The point isn't agent recall. It's PM judgment with an audit trail.

A PM Brain doesn’t store everything. It promotes only what’s recurring, decision-relevant, or strategy-relevant. Everything else stays in working memory until it earns its way into the durable layer.

This post is the long version. The short version is in the README. The shortest version: open Claude Code in an empty folder, run /pm-brain, answer a five-batch interview, and you have a working brain in 10 minutes.

What You’ll Learn

• Why your PM context decays at month three, and where the trail goes

• The five failure modes that kill most AI memory systems, and the five structural choices that answer them

• A week with PM Brain, told as Lena’s first five days on a real account

• The architecture: five knowledge areas, three lifecycle areas, one CLAUDE.md

• Provenance, the unique technical idea, and why it carries more weight than people expect

• The six commands you’ll actually use

• How to install it today, and what to do in week one

1. Why This Exists

Most AI memory systems fail by month three. The same five failure modes show up across vector-DB memory, RAG over your docs, “AI second brain” apps, and most agent-memory frameworks:

1. Accumulate, never synthesize. Every interview gets stored. Nothing compresses. The system becomes a landfill.

2. Flatten contradictions into consensus. Three interviews say three things, summarized into one bland insight. The disagreement was the signal.

3. Drift silently from strategy. Two months of decisions point one way. The strategy doc points another. Nobody surfaces the tension.

4. Lose decision context. Why did we ship X? What were the alternatives? Most systems store the decision and lose the reasoning.

5. Overload context. The agent loads too much, gets confused, generates shallow output.

PM Brain is structured around five corresponding design choices, each one targeting a specific failure:

1. Epistemic boundaries. Every claim is tagged: observation, interpretation, hypothesis, assumption, decision. A Slack comment is not automatically truth.

2. A maintenance model that runs. Weekly sweep. Stale evidence flagged, recurring patterns compressed, contradictions preserved.

3. Flag, never gate. The system surfaces. The PM decides. The moment it becomes a blocker, it dies.

4. Inspectable, not opaque. Markdown, repo-native, editable, version-controllable. Trust is the bottleneck.

5. Resists complexity creep. No taxonomies, no agent swarms, no graph ontologies. Opinionated and lightweight.

Full mapping with the architecture choices behind each fix: docs/why-this-matters.md.

Subscribe now

2. A Week With PM Brain: Lena’s First Five Days

The fastest way to see what PM Brain does is to watch someone use it. This is a short story. The character is invented, the artifacts are real-shaped, the team and the tool are not. The full version lives in docs/walkthrough.md.

Lena Vasquez just took over PM for a B2B project-collaboration tool called Mosaic. The previous PM left a Notion workspace, a Jira project, and a 3-month-old Miro discovery board.

🚀 Monday: onboarding

Lena plugs in the Notion, Jira, and Miro app connectors, then runs /pm-brain. The skill enters migration mode, runs a five-batch interview (about 10 minutes), then reads through the three tools.

Forty-five minutes later: a folder of markdown files, an INDEX.md, and a short onboarding report. Buried in it:

Tension surfaced. The strategy doc says the north-star is activation: 60% of new accounts invite a teammate by day 3. But of 47 Jira tickets shipped in Q1 and Q2, 38 are tagged “enterprise permissions” or “admin tooling.” Only 4 touch the activation funnel.

A new PM usually catches this in week three, after they’ve already built plans on top of the official story. Lena has it on day one because the brain cross-checked two folders humans tend to read separately.

🎧 Tuesday: a discovery call

Lena has a 45-minute call with Talia Brennan, Head of Operations at Northridge Construction. Quiet user, seat count plateaued, no complaints. After the call: /ingest northridge-talia-transcript.md.

Four things happen in parallel:

1. The transcript copies to source/interviews/.... Read-only. Audit anchor.

2. A synthesis note lands in ingestion/interviews/... with observations tagged by speaker and date.

3. The brain tells Lena that two stakeholders flagged the same invite-link friction back in March, that there’s a candidate hypothesis the previous PM never tested, and that the Miro discovery board has a “magic-link onboarding?” sticky from January, never explored.

4. Talia’s observation lands as a new evidence row on the invite-link hypothesis. It promotes from candidate to proposed. Three independent observations now.

One call. The weight of three.

📣 Wednesday: the loud stakeholder

Slack lights up. Rahul Pillai (marketing): “We need to ship dark mode this quarter. Every demo asks for it. It’s killing conversion.”

Loud, recent, plausible. A less-confident PM might tell engineering to start scoping.

Lena types into Claude: “Rahul just messaged about dark mode. Capture as verbal stakeholder claim, flag any conflict with documented evidence.”

The brain tags the claim (stakeholder-verbal, rahul-pillai, 2026-05-20). Then it surfaces what’s documented:

• Q1 close-loss review: 27 demos analyzed. Dark mode flagged in 2 as a wishlist item. Zero blockers.

• Cascadia Health interview, 2026-03-15: buyer named integrations and admin controls. Not dark mode.

• Brillstone interview, 2026-04-18: same.

• Q2 strategy doc: activation north-star, not feature parity.

The brain doesn’t argue with Rahul. It puts his verbal claim next to 27 sales calls, two customer interviews, and the team’s stated strategy, each wearing its actual provenance.

Lena replies: “Want to dig into this. Friday.” She has the documented case ready and a productive conversation booked.

👨‍🏭 Thursday: engineering proposes an alternative

1:1 with Mateus Okafor (engineering lead): “What if we ran a 1-week spike on magic-invite-links? If it works, we save four weeks of UI.”

Lena adds a line. The brain records the verbal, files it as a solution option on the invite-link hypothesis, findable next to Talia’s evidence and the Miro sticky from January. The suggestion doesn’t die in Slack scrollback.

🧘‍♀️ Friday: /review, then Monday’s prep is done

Lena runs /review. One page:

This week

• Strategy gap (still open): flagged Monday, not raised yet.

• Invite-link hypothesis: candidate → proposed. Three observations.

• Dark mode tension (Rahul): verbal claim captured, flagged against documented evidence. Friday meeting is your action.

• Magic-invite-links spike (Mateus): solution option logged.

Drifting

• enterprise-permissions-v2: no new evidence in 47 days. Revive, demote, or archive?

For your Monday strategy meeting

1. Open with the strategy-vs-shipped-work gap. Activation-first or enterprise-first? One is wrong.

2. Bring the invite-link hypothesis forward. Three observations + one engineering alternative. Ask for a go/no-go.

3. Park dark mode until Friday’s meeting with Rahul.

Lena reads this in five minutes. Monday’s prep is done.

What Lena got, in five lines:

• Monday: a real question to bring into your first strategy meeting, on day one

• Tuesday: one call that landed with the weight of three

• Wednesday: documented evidence ready when a loud voice contradicted it

• Thursday: an engineering suggestion that didn’t die in Slack

• Friday: a one-page summary that made Monday’s meeting easy

None of this is automation. It’s the brain doing the small, boring work of cross-referencing what she already knew, so the judgment work, which is her job, gets easier.

3. The Architecture

Five knowledge areas, three lifecycle areas, four ingestion modes, one maintenance loop.

Plus source/ (immutable copies of original artifacts), a maintenance log, and a docs folder.

Evidence flows in one direction. It fans out at the durable layer. The same artifact updates multiple destinations in parallel. Talia’s 45-minute interview touched six files: one source copy, one ingestion record, one insight promoted to knowledge/users/, one hypothesis strengthened, one stakeholder touchpoint logged, and a candidate solution option logged on the hypothesis.

When a hypothesis is confirmed, it gets promoted and a decision record is auto-drafted (status: pending, waiting for your sign-off). When a decision’s reversal condition triggers, the weekly sweep surfaces it.

Most systems mash hypotheses and decisions together. They become useless.

Subscribe now

4. Provenance: Every Claim Wears a Tag

This is the load-bearing technical idea.

Every claim in hypotheses/, decisions/, and knowledge/users/insights.md carries a small tag, a provenance marker, that says where it came from.

The tags carry an implicit hierarchy: documented decisions outweigh documented research, which outweighs verbal claims, which outweighs PM intuition. The brain leans on that hierarchy when evidence conflicts. The leaning is in plain text. You can override it.

The brain enforces the vocabulary, not the workflow. PMs have intuitions. They hear things off-the-record from execs. They inherit claims with no clear pedigree. Those are legitimate inputs. The tag just makes them wear their actual provenance instead of laundering them through a fake ingestion/ record.

Three months later your CTO asks: “Why did we kill real-time alerts?” You open the decision file. Every evidence row carries a tag. Path-typed tags walk in two clicks to the synthesis, then to the raw transcript. Non-path tags tell you honestly that no artifact exists. Both are auditable. Only a missing tag is a bug.

5. The Six Commands

/ingest is the workhorse. /plan is where the system earns its keep. A new objective lands (”reduce onboarding drop-off 20% in Q3”) and the brain loads strategy, current metrics, user insights, active hypotheses, past decisions, stakeholder constraints, then drafts the six blocks.

That output is the difference between “another second brain” and a system that does product work with you.

6. The Maintenance Sweep

Memory systems rot in predictable ways. The weekly sweep is the forcing function that catches those failure modes before they compound. Skip /review for a month and the brain becomes a graveyard. Run it weekly and the system pays you back every Friday.

Eight failure modes; six checks. Dated report in maintenance/log/:

1. Stale knowledge audit. Files not updated in 6+ weeks. Still true? Archive?

2. Stale evidence flagging. Market intel past 30–60 days, interviews past 90, stakeholder assumptions past 30, strategy assumptions past quarterly. Flags; doesn’t auto-decay confidence. You decide what to refresh.

3. Hypothesis and decision hygiene. Active hypotheses with no evidence in 30+ days. Promoted hypotheses without a corresponding decision (drafts one). Decisions whose reversal condition triggered. Pending decisions older than 14 days with blocker impact (decision debt).

4. Stakeholder cadence and strategy tensions. High-influence stakeholders not touched in 3+ weeks. Recent decisions or signals diverging from strategy. Surfaced as tensions, not as drift to fix.

5. Knowledge synthesis (compression). The highest-leverage step. Identifies recurring patterns AND recurring contradictions. Preserves minority signals: the dissenting interview, the contrarian metric, the off-pattern stakeholder concern. Compression is additive, never destructive.

6. Archival sweep. Shipped features inactive 90+ days. Resolved hypotheses. Closed asks. Before archiving anything, extracts durable lessons.

Twenty minutes Friday afternoon. Set a recurring calendar reminder. Without it, the brain rots.

7. Will This Stay Healthy After a Year?

Yes. The layer the agent loads by default (your durable knowledge of strategy, product, users, market) grows logarithmically by design. The raw layer grows linearly with your activity but stays cold unless something cites it.

Default loads target the durable + active layers. Brain age doesn’t change what routine commands read.

The architectural payoff: plain markdown in a git repo is forward-compatible with every future Claude, every future Cursor, every future agent. The format doesn’t bind to today’s tooling. Context windows expand; your brain stays the same shape.

Longer version with the realistic envelope numbers (~50-100 interviews/year, 10-20 active hypotheses, 10-30 stakeholders) and the four on-demand triggers that pull old material into context: docs/scaling.md.

8. Does It Actually Work? The Test Scoreboard

PM Brain is new. The architecture isn’t. I’ve been running the same pattern (operating manual, tags, hypotheses, decisions, weekly maintenance sweep) on my content work for months.

PM Brain is that architecture adapted to PM-specific schemas, validated against 17 scenarios I designed from PM situations I’ve shipped through, with synthetic data generated across persona, stage, and risk dimensions.

404 of 406 individual checks pass (≈99.5%) on Sonnet 4.6.

The split:

• Structural checks: 329 / 329 (100%). Files exist where they should. Links resolve. Evidence rows carry valid provenance tags. Decision schemas are valid. Hypothesis statuses match the evidence claims.

• LLM-judge content checks: 75 / 77 (≈97%). Rubrics evaluating whether the brain surfaced the right contradictions, drafted the right decisions, asked the right questions.

Each scenario is multi-turn. The harness spins up a fresh brain in a temp directory, replays the inputs through claude -p, runs structural assertions after every turn, and runs LLM-judge rubrics on substance at the end. Full breakdown and snapshots in tests/RESULTS.md.

The point isn’t 99.5%. Most “AI memory” projects don’t have an eval suite at all. When the skill changes, the suite tells you whether it got better or worse on real-shaped PM situations, with snapshots you can diff.

9. What It Isn't

A few notes the grid doesn’t cover:

• The ad-hoc inbox tempts laziness. “I’ll route this later.” No. Every ad-hoc item gets resolved in the same session. The folder is a sorting bench. The moment it becomes a backlog, it becomes a graveyard.

• Memory promotion requires judgment. The agent proposes what to promote. The call is yours. Rubber-stamp everything and the durable layer fills with noise. Reject everything and the system never learns.

• Stakeholder files feel awkward at first. Writing down what your manager cares about, in a file, in your git repo, can feel like treating people as objects. The reframe that worked for me: this isn’t about them, it’s about your continuity. You forget. The file remembers.

10. How to Start

Install & migrate

Two stages:

• Skill is global; brains are per-product. One shell command installs the skill (macOS / Linux / WSL / Git Bash, or Windows PowerShell).

• Then in any folder, run claude and /pm-brain.

The skill auto-detects what’s in the directory:

• Empty folder = greenfield.

• Folder with existing PM artifacts (Notion exports, meeting notes, Jira CSV) = migration.

Either way, a five-batch interview captures your context. The scaffold drops in. The CLAUDE.md operating manual lands at the brain root. The brain commits locally. Never pushes.

Install commands, requirements, and troubleshooting: github.com/phuryn/pm-brain.

Next: Don’t backfill old artifacts retroactively

Migration handles your current state. Don’t backfill old artifacts retroactively. Two different things:

• Migration mode, recommended: When you point /pm-brain at a folder with your active strategy doc, your in-flight hypotheses, your recent decisions, and your current stakeholder list, the skill reads them, organizes them, and produces a short report on what it found. That’s the goal. Let migration absorb your current organized PM artifacts.

• Backfilling everything, the trap: The temptation is to spend a weekend manually feeding 200 old interview transcripts, six months of Slack threads, and every meeting note you’ve ever taken through /ingest. Don’t. If a six-month-old interview matters, it’ll come up through current work and you’ll ingest it then, with the context to know why it matters. Forcing stale artifacts in now wastes a weekend and clogs the durable layer with stuff the agent has no context to promote properly.

Week 1

The system dies if these three habits don’t take hold in week one. Do them in order, in the first seven days:

1. Ingest one real artifact today. Paste your most recent customer interview, meeting notes, or competitor screenshot. Watch where it lands in ingestion/, then which durable areas it updates. This is how you learn what the system does.

2. Prep your next 1:1. Before your next conversation with your highest-friction stakeholder, run /prep . Let the agent surface what to ask. The first real value is here, not in the scaffold.

3. Run /review Friday. Set a recurring calendar reminder. Twenty minutes Friday afternoon. Without it, the brain rots.

That’s week one. Don’t add anything else.

Week 2

Ingest two more interviews. Log one decision. Add one feature file for your most active feature. Open knowledge/strategy.md and fill in the Non-goals section if the interview didn’t capture it.

Week 3

Second /review. Now you can compare two reports. Patterns start showing up: recurring contradictions, drifting strategy, hypotheses with no evidence. This is when the system starts paying off.

Week 4+

It compounds. Every meeting note, every market signal, every decision feeds the same loop. The brain learns the shape of your product as you work.

The goal isn’t a complete brain. The goal is a brain that compounds over time.

11. A Research Preview, with Help

PM Brain is a research preview. The architecture has months of dogfooding behind it on my content work; the product as installed by real PMs is new. I want to learn what breaks in real organizations, in the first week of use.

Three things to make adoption easier:

• Live workshop session, Monday May 25 May 26, for paid subscribers. I’ll walk through install, migration, and the first week of usage live, then take questions. See: https://go.productcompass.pm/premium

• Dedicated #pm-brain Slack channel for 1:1 install help (paid members). Office Hours members get the channel. I’m in there for install pain, first-week confusion, and the awkward moments where the system feels wrong but you can’t articulate why. Those are the highest-signal reports.

• Public issues. github.com/phuryn/pm-brain/issues. Install bugs, feature requests, scenarios you want the eval suite to cover. Anyone can open one without a Substack subscription.

Subscribe now

If you’re in a real product role and the system might fit your workflow, your install feedback in week one is what makes the next version better.

12. Closing

Most product organizations repeatedly lose the same things: failed bets, abandoned assumptions, historical reasoning, unresolved tensions. The PM job is partly to remember these. The PM job is impossible when your context lives in five different places and none of them talk to each other.

One repo. One operating manual. An agent that reads it.

The brain isn’t a notes app you fill in. It’s a folder of plain-text files that grow with the work, traceable back to the source on every line, swept clean every Friday, free for anyone to use, and inspectable by anyone you trust.

P.S. The repo is at github.com/phuryn/pm-brain.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a great rest of the week, Paweł

Resources

The PM Brain OS

• The repo. github.com/phuryn/pm-brain. Skill, example brain, docs, tests, all MIT licensed.

• The walkthrough. Lena’s first five days, the long version of Section 2.

• Why this matters. Five failure modes that kill most AI memory systems, and the five structural choices that answer them.

• The architecture doc. Two design decisions and one operating loop.

• Scaling. How the brain stays healthy as it grows, growth shapes, compression mechanisms, realistic envelope numbers.

• How it works. The technical version, one ingestion, six files touched, end to end.

• Prior art. What PM Brain borrows from Zettelkasten / RAG / CLAUDE.md patterns, and what it rejects.

• Glossary. Every term in plain English.

• Tests scoreboard. 404 / 406 checks, per-scenario snapshots, two residual failures called out honestly.

• Issues. github.com/phuryn/pm-brain/issues. Install bugs, scenarios you want covered, feature requests. Open one.

Composing with PM skills

PM Skills (11K+ stars). github.com/phuryn/pm-skills. PM Brain is the memory layer; PM Skills is the workflow layer. They compose. A JTBD PM Skill extracts jobs from an interview using the proper framework; PM Brain makes sure that job updates the right user insight, hypothesis, stakeholder note, and decision record. The skill is how to do the work once. The brain is what we know across all the times we did it.

Related newsletter posts

• Claude Code for PMs: The Beginner’s Guide (May 12). Everything to start.

• Claude Code Guide (Mar 8). Full version. The tool this runs on.

• Self-improving AI systems (Mar 16). The parent pattern for compounding agents.

• Intent Engineering Framework (Jan 13). The agent design language behind CLAUDE.md.

• What Is Product Discovery? The Ultimate Guide (updated 2025). Critical for PMs.

When looking for a job, expect:

• “How do you use AI/Claude in your day-to-day?”

• Vibe coding / prototype rounds: from PRD to evals

• Portfolio/case studies: Show agents/prototypes built with AI

• Questions focused on AI product sense + execution with agents

Even people like Garry Tan (Y Combinator) went back to "coding" and ships a custom brain for agents after work hours:

In the past, we’ve discussed many aspects:

• The Guide to Claude Code for PMs

• What I Learned Building a Self-Improving Agentic System with Claude

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

• Your .claude/ Folder Is a Production Agent

• The Ultimate Guide to Claude Opus 4.7

• Claude Code's Limits Are Generous. The Problem Is Your Setup.

The first Guide above assumes you’ve used Cowork. Talking to the community, I realized many PMs haven’t, and they need a zero-to-one path.

This article has everything you need to start:

1. How to install Claude Code step-by-step

2. A ready-to-use Claude Code solution template

3. How to configure MCP servers in Claude Code step-by-step

4. How to use and create skills in Claude Code step-by-step

5. How to use Claude Code with free frontier models

Subscribe now

1. How to Install Claude Code Step-By-Step

This combines Claude Code with the recommended interface, Claude Code extension in VS Code.

Step 1: Install Visual Studio Code for MacOS or Windows

Step 2: Launch VS Code, click “Extensions,” and install “Claude Code for VS Code”

Step 3: Log in with Claude.ai Subscription after typing “/login” in the Claude window. There are two interfaces, it’s easy to get confused:

• Skip this one: Claude Code in Terminal - opens at the center

• Use by default: Claude Code Extension for VS Code - opens in the secondary side bar on the right

Note: On the right side in the video you can see two tabs:

• [Codex] - OpenAI extension I installed earlier

• [Claude Code] - that’s our Claude Code extension

Sometimes you may also see “Chat” - it’s a Microsoft solution. Ignore it.

2. A Ready-To-Use Claude Code Solution Template

This knowledge work template contains everything you need to start:

• Preconfigured plugins, skills, and permissions

• My minimal CLAUDE.md that makes your agent more autonomous

• Setup that reduces costs by at least 50% by managing models, subagents, and context windows better

• Ready-to-use configuration so you can work with free frontier LLM models

You can watch our Claude Code video session download the template below (click File > Download):

🔒This content free for all subscribers. Sign up and get full access (don’t pay anything).

Subscribe now

Extract the archive and open it with VS Code:

You will see:

Inside:

• Predefined configuration:

  • CLAUDE.md / AGENTS.md - agent’s constitution

  • settings.json - cross-team project settings, predefined permissions and plugins

  • settings.local.json - your local project settings with 200K context window and 80% autocompact

• Examples:

  • SKILL.md - an example custom skill, you can remove it.

  • tools/reddit_api_example.py - an example custom tool generated by Claude. You can remove it, in that case remove line 53 from AGENTS.md too.

  • .env - here, you configure your API keys. Not committed to GitHub. You can remove two lines: REDDIT_CLIENT_ID and REDDIT_CLIENT_SECRET.

  • .mcp.json - an example custom MCP server. You can remove Linear (lines 3-6), if you don’t need it.

Tasks for you:

• Review and remove or adapt examples listed above.

• Update ## Strategic context, about me in AGENTS.md with a brief summary of your strategy or/and about you (for an individual)

• Update ## Communication and style in AGENTS.md so it follows your writing style and preferences

• Update docs/strategy.md with a information about your product

3. How to Configure MCP Servers in Claude Code Step-By-Step

MCP is a common protocol to connect apps such as Stripe, Gmail, Notion, Jira, or Slack. The easiest way is to go to https://claude.ai/customize/connectors and configure them there:

Those connectors are automatically available in Claude Code, too, as long you use a Claude subscription. Here’s how Claude works with my Gmail Connector:

Task for you: Connect the apps you use the most, such as Gmail, Notion, or Google Calendar. Configure actions that require your approval, such as sending an email, in claude.ai (presented in the screenshot above).

For apps not available in the Claude catalogue or when using a free LLM, use Google to find a dedicated MCP server and ask Claude to configure it in a chat based on the documentation:

MCP servers can be available:

• Only for you when using this project

• For any user using this project

• For any project on your local machine

Include your preference in the prompt.

4. How to Work with Skills in Claude Code Step-By-Step

Each skill gives Claude domain knowledge, analytical frameworks, or a guided workflow for a specific task.

They always contain SKILL.md file and can also include additional resources, for example:

---
name: substack-to-pdf
description: Export Substack posts to self-contained PDFs
  with embedded images.
---

# When to use
When asked to create PDFs from Substack posts.

# Steps
1. Fetch post HTML
2. Download images, embed as base64
3. Render with Playwright

# Files
- script.py
- styles.css

By default Claude can see only the frontmatter ("description"). The full skill is loaded automatically when relevant to the conversation.

4.1 Skills and plugins available publicly

Top recommended public repos. Each contains installation instructions. You can also give your agent an URL and ask to import specific skills:

1. github.com/phuryn/pm-skills: PM Skills Marketplace — 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth

2. claudemarketplaces.com: Browse and discover plugin marketplaces you can add to Cowork or Code

3. github.com/travisvn/awesome-claude-skills: Community-curated collection with battle-tested skills for TDD, debugging, collaboration

4. github.com/sickn33/antigravity-awesome-skills: 868+ universal agentic skills — covers security, DevOps, full-stack, AI/ML, and more. Role-based bundles (Startup Founder, Marketing & Growth, etc.) let you pick what’s relevant. Works with Claude Desktop, Claude Code, Cursor, Gemini CLI, Codex, OpenCode, and Antigravity

5. skills.sh: Vercel’s open skills ecosystem — directory and leaderboard, CLI installer (npx skills add). PM-relevant skills include product strategy frameworks, pricing strategy, launch playbooks, discovery interview guides, PRD generator, analytics tracking setup, resume optimizer, and more. Full repo also covers marketing, SEO, copywriting, and web design.

The bottom line: don't install skills you don't need. Start with none and add one when a real task forces it. Even unloaded skills cost context - the frontmatter description always loads.

4.2 How to create your own Claude Code skills

When you perform a specific task multiple times, ask Claude to turn it into a skill. It's way easier than editing markdown files manually.

Here, I continue the example from point 3:

Next time you ask Claude to summarize emails, it will reuse that logic while saving tokens.

Tip: Skills can be available for any user using this project or for any project on your local machine. It can also be called as subagent - use this option when the skill doesn't need your entire conversation history. Include your preferences in the prompt.

Task for you: When you notice a recurring pattern, ask Claude to turn it into a skill.

5. How to Use Claude Code with Free Frontier Models

Before you start: There is an open Anthropic bug, 36179. Using alternative models works only with Claude Code in terminal, not with the Claude Code extension for VS Code. Start by using your Claude subscription, especially if you're not comfortable with Claude Code yet.

Step 1: Go to OpenRouter, sign up: https://openrouter.ai/

Step 2: Verify your email address by clicking a link in an email message

Step 3: Add $5 credits to your account (to verify the account): https://openrouter.ai/settings/credits

Step 4: Create a free API key: https://openrouter.ai/workspaces/default/keys

Step 5: Open a folder with your project. Create settings.local.json in the .claude folder. Inside:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "{your-API-key}",
    "ANTHROPIC_API_KEY": ""
  },
  "model": "inclusionai/ring-2.6-1t:free"
}

You can also rename this file, already in your template. Create a backup of the original settings.local.json:

I suggested inclusionai/ring-2.6-1t:free. It’s a 63B model with a 262K context window. Note: free models on OpenRouter change regularly.

Here’s how it works with Claude Code in terminal, completely free:

Task for you: Get comfortable with Claude Code and Anthropic models before switching to alternative models. You don’t want to learn Claude Code and solve OpenRouter issues simultaneously.

Closing

You have everything you need to start.

Install it this week. Connect apps (MCP servers) you’ll actually use. Build one skill from a task you already do twice.

The more you use Claude Code, the easier it becomes. Later, review other posts listed in the intro:

• The Guide to Claude Code for PMs

• What I Learned Building a Self-Improving Agentic System with Claude

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

• Your .claude/ Folder Is a Production Agent

• The Ultimate Guide to Claude Opus 4.7

• Claude Code’s Limits Are Generous. The Problem Is Your Setup.

• The Ultimate Guide to Claude Fable 5

• the AI PM learning roadmap.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have an amazing rest of the week, Paweł

10 minutes later I had a fully interactive prototype I could iterate on.

Not a mockup. Not a screenshot. A clickable flow built on top of my real design system, ready to share, comment, refine, and implement. Two examples:

Some compare Claude Design to Figma speed when iterating on the canvas. That framing misses the point.

What matters for a product team is Time to Learn - the time from “we should try X” to “we have evidence it works or fails.” And Claude Design can radically reduce it.

What you’ll learn:

• How to import or reverse-engineer your design system

• The PM context Claude Design needs to ship a usable first cut

• How to modify an existing production feature

• How to run the workflow with the product team and stakeholders

• What this means for product discovery, hiring, and the shape of senior roles

Subscribe now

1. What Changes for Your Team

I loved working with my designers. Ideating, challenging usability, sharing clickable prototypes with the business, running experiments. But sometimes I wished I had more of their time.

I didn’t enjoy Jira handoffs. In particular, keeping everything in sync as decisions changed and waiting for designers to verify the implementation is aligned with Figma.

Claude Design compresses two parts of the workflow:

Idea → prototype:

• Old: several days with a dedicated designer. Weeks if you don’t have capacity.

• New: same afternoon. Iterate in hours via chat, comments, or sketch.

Approved design → code in production:

• Old: weeks. You hand Figma to engineers. Engineers rebuild in code. Implementation drifts. Back-and-forth on what the design “really” meant.

• New: days. Engineers continue from the prototype and design system through Claude Code. No rebuild.

Some argue that Figma is faster for experienced designers. That might be true, but the difference is smaller than these two compressions. And can be radically reduced by selecting the right model - Sonnet for small fixes.

Designers should adopt this too. Cleaner handoff to engineering. More time on the work that needs design judgment instead of checking pixels.

The same design system also generates slide decks, motion videos, and custom templates. Marketing, sales, and support reuse the brand without rebuilding it.

2. How to Define Your Design System

Most product teams I’ve worked at had a design system in some form. A Figma library, a Storybook, a brand doc. Start by importing what you have.

Step 1: Open Claude Design > Design systems > Create

Go to https://claude.ai/design:

Step 2: Provide company name, examples, and sources

You can mix multiple sources and also drop in sketches, screenshots, photos, fonts, logos, and a text description of voice and brand. Claude Design can also pull context from the open web.

I tested reverse-engineering my existing codebase. According to multiple user reports, code wins when both code and Figma exist.

Note: DESIGN.md, introduced by Google is the lowest-fidelity option in the table because it’s rules-only - no assets, no components, no motion, and not all layout patterns. It’s a fast seed when you have nothing. Move to a codebase or .fig file as soon as you have one.

Tip: For a new product without a system yet, you can clone an existing brand you admire (Ferrari, Apple, Linear) and iterate from there 🙂 Faster than starting from a moodboard, and you keep refining until it’s yours.

You can also run multiple design systems in parallel. Useful if you ship across product lines, or if you’re testing a brand refresh without breaking production.

Step 3: Click “Continue to generation”

Three artifacts:

• Design System. UI kit, type, colors, spacing, components, brand. Every prototype anchors on this.

• Design Files. Assets, HTML, images, stylesheets you can preview.

• Skill.md. A skill Claude Design generates as a representation of the design system. The agent uses it to keep every new design consistent with your brand.

You can review your design system, iterate via chat, set permissions, and share with the team. Comments work the same way they do in Figma.

Step 4: (Optional) Export your design system as a skill

When you export your design system as a .zip archive, it becomes a skill you can give to any agent (Claude Code, Cowork, Codex, etc.). The skill is a complete representation of the system and contains all design files.

That’s the theory. In my tests, I faced errors. Waiting for a fix.

Share

3. How to Prototype a Product or Feature

Same flow whether you're prototyping something new or modifying what already ships. The difference is what you point Claude Design at on the way in.

Step 1: Open Claude Design > New prototype > Create

Pick the design system you generated in §2 and name your prototype.

Step 2: Provide Context

Depending on what you’re prototyping:

• New feature. Brief Claude Design from scratch.

• Existing feature. Point at the codebase, or branch from a previous Claude Design version.

You can also include screenshots, Figma files, web elements, or reference Claude Design projects (via “Import”).

What to brief it on:

• Objective. Should explain why it’s important and how the success will be measured. Often implicit, especially when you have a well-documented system.

• Persona. Who’s actually using this. Not the buyer. The person inside the screen.

• Value proposition. What this screen is supposed to deliver to that person.

• Job to be done. The underlying task they’re trying to complete.

• Common actions. What they’ll do most often. If you have product analytics, lead with those numbers. If not, your best assumptions.

Notes:

• There is no GitHub repo selector, but after connecting GitHub you can provide Claude Design with a GitHub URL.

• I specified a GitHub repo for a new feature because my agents maintain a full strategic context in the repo.

This isn’t just prompt engineering. It’s instrumenting business context for the agent beyond the current objective. For more, see the Intent Engineering Framework for AI Agents and my Opus 4.7 guide.

Step 3: Answer the Questions > Continue

If you forgot about the context, don’t worry. Claude Design interviews you before taking action:

Step 4: Review and refine in the canvas

5–10 minutes for the first generation. Once the prototype exists, switch to a faster model in chat. Iteration drops to seconds. An example result:

Once the prototype exists, PMs can run small fixes like copy edits, button placement, or empty-state polish without pulling in a designer for every adjustment.

Four refinement tools:

• Chat. Refine via natural language (”make the empty state more inviting”).

• Comments. Figma-style threaded notes. Anyone you share it with can drop them.

• Sketch. Draw directly on the prototype. Useful when “move that there” is faster than typing.

• Edit. Applying changes directly in the system. I would use it primarily for text adjustments:

  

Each prototype can have multiple variants on the same canvas. They are called tweaks. Just ask in the Chat. Claude Design adds them to the Tweaks panel. For example, here I asked for an Anthropic variant:

Step 5: Export and handoff

The Claude Code handoff is what changes the workflow the most. Your prototype isn’t a deliverable engineers re-implement. It’s a starting point they continue from.

I’ll come back to working with the trio and the deeper context inputs for modifying existing features in the paid section.

I built and shipped products for 10+ years. I talk to PMs every week. Next, a set of suggested workflows for your team based on my work in accredia.io:

• How to collaborate in the Product Trio.

• How to test assumptions and when you can just ship.

• What to do about Jira/Linear tickets.

• What this means for the future or product jobs. 👇

Read more

The same workflow cost me €1,184.95 (~$1,389) a month ago:

No model swap, no skipped sessions.

Between March 23 and April 23, some users on Max burned weekly quotas in 1-2 days. Anthropic shipped 3 bug fixes (v2.1.116+) and reset all subscriber limits. Full writeup in their April 23 postmortem.

Four root causes are still on your side (I’ve been researching and testing that for the last 2 weeks):

1. Cache misses

2. Context bloat

3. Wrong model or effort

4. Wrong input format

Our Sponsor: Nimbalyst

This is a paid placement, but I only run sponsors I've actually tested. I’ve been working with Nimbalyst for 10+ hours.

It’s a visual workspace for Claude Code and Codex. If the VS Code interface has intimidated you, you should try it.

I loved the markdown files that actually render without plugins, and navigating between linked documents. VS Code is missing this.

Big surprise: sessions as cards on a Kanban board. Backlog, planning, implementing, done. Claude doesn’t have this.

Plus session tracking, all the context window techniques we’ve been discussing, and a native iOS app (their custom remote control). Works with your Claude Pro/Max/Team subscription, not just API keys.

Free for individual use. Worth twenty minutes if you’ve been Claude-Code-curious:

Download Free

1. Cache Misses

The prompt cache is the single biggest lever in Claude Code. Most people never look at it.

The math:

• Cache read: 0.1× the input price

• Cache write (5-min TTL): 1.25×

• Cache write (1-hour TTL): 2×

• Cache refresh on hit: free (charged at the read price)

Every hit on a cached prefix resets its TTL at no extra cost. So a long session with steady tool use stays warm indefinitely as long as the prefix doesn’t change.

Thariq spelled out the rules in “Lessons from Building Claude Code.” The two that move the needle:

• Lock your tools at session start. Adding or removing a tool mid-session invalidates the cached prefix and forces a full re-read. Never add or remove tools mid-session.

• Lock your model at session start. Switching models mid-session blows the cache for the same reason.

~90% is healthy on the 5-min default. On the 1-hour TTL it climbs to ~97-99%, but that one is API-only and isn’t priced into Pro / Max / Team subscriptions.

What to Do:

• Protect the prefix. Don’t add MCP servers mid-session, don’t /model mid-session.

• Watch the hit rate. See § Watch the Number below.

• Consider the 1h cache for long sessions on the API. Write costs more (2× vs 1.25×), but the higher hit rate pays it back.

2. Context Bloat

For Opus 4.7, 1M context is the default. That’s expensive. Long sessions sprawl, and auto-compact fires later than it should. Disable it and fall back to 200K. 200K is enough for almost any task.

On 200K, auto-compact fires at ~155K (~80%), the behavior Boris Cherny described for the previous Opus. The trick is to compact before you hit the auto-trigger. Once it fires, it pushes you over and warms a fresh prefix. Compact early instead.

The settings I run:

{
  "env": {
    "CLAUDE_CODE_DISABLE_1M_CONTEXT": "1",
    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "80"
  }
}

That disables 1M context and pins the auto-compact threshold at 80%.

2.1 Five Session Moves

• /compact at 50% or after every task. Don’t wait for auto.

• /clear between unrelated work. New session = fresh prefix.

• /rewind when a turn went sideways. Cheaper than re-prompting around the bad context.

• Subagents for anything that doesn’t need the parent’s reasoning.

2.2 Subagents Are the Underused Move

Anything that’s bulk-mechanical, scoped research, or parallelizable should run in a subagent. The parent context stays clean and you parallelize across cheaper models.

A CLAUDE.md task-delegation block I keep in every project:

## Subagents v1.0

Spawn subagents to isolate context, parallelize independent work, or offload bulk mechanical tasks. Don't spawn when the parent needs the reasoning, when synthesis requires holding things together, or when spawn overhead dominates.

Pick the cheapest model that can do the subtask well:
- Haiku: bulk mechanical work, no judgment
- Sonnet: scoped research, code exploration, in-scope synthesis
- Opus: subtasks needing real planning or tradeoffs

If a subagent realizes it needs a higher tier than itself, return to the parent.

Parent owns final output and cross-spawn synthesis. User instructions override.

2.3 Skills Can Also Be Invoked as Agents

Add agent: true and model: to the frontmatter and the skill runs in its own subagent context with its own model. For example:

---
name: tldr-pdf
description: Extract a 200-word TL;DR from a PDF without loading the full text into the parent context
agent: true
model: sonnet
---

You receive a path to a PDF.

1. Run `pdftotext "$1" -` to extract the text.
2. Read the output.
3. Return only:
   - 5-bullet TL;DR
   - 3 quotes worth keeping
   - Any URLs cited

Never return the full text. Never expand beyond the structure above.

The parent gets back 200 words. The full PDF never touches its context.

2.4 A Few More Techniques that Pay for Themselves on Long Sessions

• Load lean. Disable unused MCP servers, tools, skills, and plugins. Move rules out of CLAUDE.md and into skills, custom tools, or referenced .MD files (progressive disclosure).

• Spec prompts. Write requests like a spec: file paths, components, expected I/O, constraints. Vague requests burn turns and tokens.

• Skip the search. When you know the file, tag it @ docs/design.md or @ research.md. Claude doesn’t need to grep for what you can hand it directly.

• rtk-ai/rtk. CLI proxy that strips redundant whitespace and compresses tool output. 60-90% according to the authors. ~20-30% token reduction in my workflow.

  

• juliusbrussee/caveman. Drops conversational filler from responses without affecting the model’s actual reasoning. Highest savings on chats.

  

Subscribe now

3. Wrong Model or Effort

Three separate dials. All burn tokens fast if you leave them on the wrong setting.

3.1 Effort

Default reasoning burns ~2× the tokens of medium for most tasks. Set it on the prompt that needs the headroom, not the whole session.

markdown

/effort low       # quick fixes, mechanical tasks
/effort medium    # most prompts (huge savings vs default)
/effort high      # demanding reasoning 
/effort xhigh     # default for agentic coding (4.7)
/effort max       # diminishing returns; rarely worth the ~2× xhigh cost

Per prompt, not per task or session. Since then, the effort dial got re-measured under Fable 5.

3.2 Route in (CLAUDE.md)

Pick the session model at start. You can’t switch mid-session without nuking the cache (§1). Two options:

• Sonnet session. Cheaper, but no Opus available. Good when you know the work is in-scope for Sonnet.

• Opus session + delegate. Pay for Opus on the parent (planning, tradeoffs), delegate the rest. My default for mixed work.

Then spell out delegation in CLAUDE.md: Haiku for mechanical work, Sonnet for scoped research, Opus for tradeoffs. Opus 4.7 delegates less than 4.6, so you have to ask. See § 2 (Task Delegation) for the full block.

3.3 Route Out

If you’re hitting Pro / Max / Team limits but want to keep the Claude Code interface, route to OpenRouter or another provider. GLM-5.1 ≈ Opus at ~1/12× the cost.

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "{YOUR-API-KEY}",
    "ANTHROPIC_API_KEY": ""
    },
  "model": "z-ai/glm-5.1"
}

Subscribe now

4. Wrong Input Format

Some inputs are token-expensive by default. Three swaps cover most of it.

4.1 Screenshots and Chrome Scraping → agent-browser

vercel-labs/agent-browser browses pages via the accessibility tree instead of rendering and screenshotting. ~90% fewer tokens than “Claude in Chrome” when you’re scraping or doing research from web pages.

npm install -g agent-browser
agent-browser install  # Download Chrome from Chrome for Testing (first time only)

4.2 PDFs → pdftotext, Not Claude’s PDF Reader

The Read tool loads PDFs as images, which is expensive. Tell Claude to use ‘pdftotext’ instead of ‘Read’ (works for PDFs on local drive, but not attached to the chat - the latter works in Claude Desktop only).

The CLAUDE.md fragment that codifies defaults from 4.1 and 4.2:

## Preferred Tools

### Data Fetching

1. **WebFetch**: free, text-only, works on public pages that don't block bots.
2. **agent-browser CLI**: free, local Rust CLI + Chrome via CDP. For dynamic pages or auth walls that WebFetch can't handle. Returns the accessibility tree with element refs (@e1, @e2). ~82% fewer tokens than screenshot-based tools. Install: `npm i -g agent-browser && agent-browser install`. Use `snapshot` for AI-friendly DOM state, element refs for interaction.
3. **Notice recurring fetch patterns and propose wrapping them as dedicated tools.** When the same fetch/parse logic comes up more than once, suggest wrapping it as a named tool (e.g. a skill file or a .py script that calls `agent-browser` with the snapshot and extraction steps baked in for that source). Add the entry to `## Dedicated Tools` below and reference it by name on future calls.

### PDF Files

Use 'pdftotext', not the 'Read' tool. Use 'Read' only when the user directly asks to analyze images or charts inside the document. Read loads PDFs as images.

## Dedicated Tools

<!-- List project-specific tools here. For each, link to its skill or script file (e.g. `tools/reddit_fetch.py`). The orchestration logic lives in those files, not here. -->

4.3 Large Repos → Code Graph, Not Raw File Reads

tirth8205/code-review-graph builds a persistent map of your codebase (a knowledge graph). Claude reads only what matters. Claimed 6.8× fewer tokens on reviews, up to 49× on daily coding tasks. I implemented it in accredia.io. Worth noting: it does reduce tokens on specific tasks, not all tokens.

AI coding tools re-read your entire codebase on every task. code-review-graph fixes that. It builds a structural map of your code, tracks changes incrementally, and gives your AI assistant precise context via MCP so it reads only what matters.

5. Watch the Number

Three dashboards, depending on your tier:

5.1 Historical (Pro / Max / Team)

phuryn/claude-usage: Long-term breakdown by session, day, week, and all-time. Use it to find where the spend went.

5.2 Real-Time

Gronsten/claude-usage-monitor: Current 5-hour window + active session tokens, with color thresholds. Use it to know how close you are to your cap right now.

5.3 API: Anthropic’s Own Cache Dashboard (API users)

At platform.claude.com/usage/cache, API only, separate from Pro / Max / Team subscriptions monitoring.

If you can’t see the cache hit rate, you can’t fix it.

🔒 6. An Upgraded Sub-Agents Instructions for Cowork and Claude Code

In §2.2, I shared a Subagents v1.0 block that significantly reduced my tokens in Claude Code, especially with Opus 4.7.

After running it across dozens of sessions, two failure modes kept showing up:

• Subagents with no strategic context returned compliant-but-useless data, forcing the parent to re-spawn with a better brief and pay for the work twice.

• Unverified data silently propagated into the parent agent.

Those two issues were common in Claude, unrelated to tokens.

The block below fixes them by adding the strategic-context layer. Works across Cowork and Claude Code 👇

Read more

GPT-5, Grok, Gemini, open-weight models via OpenRouter, a local model on your laptop, or your enterprise gateway (Bedrock, Vertex, Foundry).

Anthropic shipped it quietly. No announcement. No blog post. Just technical docs. I discovered it by accident. 20+ hours later, still zero official word.

1. What It Actually Is

Built for enterprises and individuals. Same config panel, same admin controls.

If your organization uses Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway to access Claude, you can deploy Claude Cowork to run on the same infrastructure.

This is a research preview. The official docs cover three paths:

• regulated industries

• companies running Claude through their own gateway

• individuals on pilot/evaluation setups

Any individual can install it today.

Every admin control (per-user token caps, MCP allowlist, OpenTelemetry, block auto-updates, remove built-in tools) ships on all three paths.

OpenRouter counts as an LLM gateway. Anthropic doesn’t list it in the docs, but I tested that it works. Confirmed by the OpenRouter CEO:

Brief summary:

Foundry: during this research preview, Claude on Foundry still runs on Anthropic’s infrastructure. Bedrock and Vertex are the paths with full provider-side data residency.

2. Who This Is For

Two audiences. Same config, different endpoint.

Individuals:

• Hitting Max plan weekly limits

• Want to try Cowork without paying $100 or $200 a month

• Running a local model on code you can’t send to any API

Enterprise:

• Already on Bedrock, Vertex, or Foundry. Keep the harness inside your existing compliance boundary

• Security approves your cloud provider but not Anthropic direct

• Need team-wide admin controls (token caps, MCP allowlist, OpenTelemetry)

Side note: Find this helpful? Here are some other Claude posts you may have missed:

• Claude Cowork: The Ultimate Guide for PMs

• The Guide to Claude Code for PMs

• What I Learned Building a Self-Improving Agentic System with Claude

• The Claude Dispatch Guide: 48 Hours Running AI Agents From My Phone

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

• The Ultimate Guide to Claude Opus 4.7

Subscribe and upgrade your account for the full experience:

Subscribe now

3. Enable & Configure

3.1 Connect to OpenRouter

No proxy needed. Point Claude Desktop straight at OpenRouter.

1. Menu → Developer → Configure Third-Party Inference

   

2. Set:

   1. Connection: Gateway

   2. Gateway base URL: https://openrouter.ai/api

   3. Gateway API key: your OpenRouter key

   4. Gateway auth scheme: x-api-key

      

   5. In the Sandbox & workspace configure "Allowed egress hosts" so that your agents can access the web. For example (all sites):

      

3. Click: Apply locally → Relaunch now

4. Log out, then Continue with Gateway:

   

5. You’ll see “Setting up Claude’s workspace...” You can start chatting:

   

Select an OpenRouter model. The free one that works for me: tencent/hy3-preview:free

Local models work the same way through an OpenAI-compatible proxy (LiteLLM, Ollama’s OpenAI endpoint). I’ll cover local setup in a separate post.

3.2 Import Anthropic skills

OpenRouter setups ship with Customize → Skills empty. Install the official Claude Desktop skills (docx, pdf, pptx, xlsx, skill-creator) manually.

1. Download the skills repo as .zip: https://github.com/anthropics/skills/tree/main/skills

2. Extract skills-main.zip, go inside

3. Zip the skill folders you want individually (e.g., docx folder → docx.zip)

4. In Claude Desktop: Customize → Skills → Create skill → Upload a skill. Upload each .zip

Only import the ones you need. Skills take context window space even when not fully loaded.

3.3 Import Anthropic plugins

Same pattern. Two repos worth pulling from:

• Knowledge-work plugins (marketing, product-management, legal, finance): https://github.com/anthropics/knowledge-work-plugins

• Code tab plugins: https://github.com/anthropics/claude-plugins-official

Steps:

1. Download the repo as .zip

2. Extract, go inside

3. Zip the plugin folders you want (e.g., product-management → product-management.zip)

4. In Claude Desktop: Customize → Personal plugins → + → Create plugin → Upload plugin

Cap it at 2–3 plugins. Often 0 is right.

3.4 Configure MCP servers

MCP servers are local. Add them under Settings → Developer.

They write to a dedicated claude_desktop_config.json file (if you don’t see that option see 4. Troubleshooting).

You can find servers at github.com/modelcontextprotocol/servers (official).

Example: Atlassian (Jira + Confluence) via the community mcp-atlassian server:

{
  "mcpServers": {
    "atlassian": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "JIRA_URL": "https://your-domain.atlassian.net",
        "JIRA_USERNAME": "your-email@example.com",
        "JIRA_API_TOKEN": "your_api_token"
      }
    }
  }
}

3.5 Search

OpenRouter doesn’t support Anthropic’s native web search. Three ways around it:

1. Replace it with an MCP. Add WebSearch to disabledBuiltinTools so that the agent is not confused and install the Brave MCP server (2,000 free requests/month, or $3 per 1,000).

Add this MCP:

{
  "mcpServers": {
    "brave-search": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-brave-search"],
      "env": { "BRAVE_API_KEY": "YOUR_API_KEY_HERE" }
    }
  }
}

2. Switch provider to Vertex AI or Microsoft Foundry. Both support native web search. Amazon Bedrock doesn’t yet.

3. Wait. OpenRouter could route Anthropic’s web_search tool to Perplexity or similar - not shipped yet.

Side Note: On May 9, we’re launching Hands-On Claude Code Certification. In 4 weeks you will learn everything to ship full agentic products — UI, agentic harness, evals, guardrails, and ops — with Claude Code. Real apps, not demos.

Secure your spot (40% off)

Most students expense this through their companies.

4. Troubleshooting

Can’t see “Configure Third-Party Inference” in Menu → Developer

Update Claude Desktop and restart. Then enable developer mode: Help → Troubleshooting → Enable Developer Mode.

Users on corporate/Team plans have reported the setting is still missing even with developer mode on. It may be plan-gated or A/B rolled.

Can’t see “Local MCP servers” in Cowork on 3P

Update Claude Desktop and restart. Then enable developer mode: Help → Troubleshooting → Enable Developer Mode.

Connectors show as “Unavailable”

Not a bug. Third-party inference means running without Anthropic’s infrastructure. Connectors depend on that layer. Use an MCP server instead (See 3.4).

Tool calling is flaky on non-Claude models

Models vary. Some handle MCP calls cleanly; others break on multi-step agentic flows. The best I’ve tested: https://www.productcompass.pm/i/193559427/api-pay-per-token-choose-your-model

Code tab settings don’t match Cowork settings

Acknowledged in Anthropic’s docs: some Cowork on 3P config keys don’t propagate identically to Code-tab sessions yet.

5. What This Signals

Look at what ships in Configure Third-Party Inference:

• Max tokens per window (per-user soft cap)

• Allow user-added MCP servers

• OpenTelemetry collector endpoint

• Block auto-updates

• Remove built-in tools from Cowork

None of those matter to a solo user. They’re admin controls. Paired with Bedrock, Vertex, and Foundry support, Anthropic’s official framing is explicit:

Cowork on 3P is designed for organizations whose security, regulatory, or contractual requirements prevent them from sending data to Anthropic’s first-party infrastructure.

Claude Desktop is becoming a managed agent platform. The harness (Code, Cowork, skills, plugins, MCP, sub-agents) is what Anthropic wants to be the default, regardless of which model sits behind it.

The individual path is documented, not an accident. On my Max plan, the full config panel shows up. Anthropic's docs don't explicitly say end users get this; the install section just tells you to "enter the values supplied by your administrator." But on a personal install, with no administrator in the picture, those fields sit there for you to set.

Docs:

• Use Claude Cowork with third-party platforms (support)

• Cowork on 3P: overview

• Cowork on 3P: installation

Download and install Claude Desktop. Start with a free OpenRouter model. No $200/mo subscription required.

We’ve covered the Claude ecosystem in the previous posts and recorded meetings available to the premium members.

Subscribe now

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

I’m uploading two new recordings, Building Agents with Claude Code and Context Window Optimization, tomorrow.

Take care,
Paweł

Anthropic shipped Claude Opus 4.7 on April 16. The official migration guide puts it plainly: 4.7 “takes the instructions literally” and “will not silently generalize.”

It's not a uniform upgrade. Wins on coding, creative writing, and structured work. Losses on instruction following in vague prompts, multi-turn, and long-context retrieval. The benchmarks show a trade, not a regression. I sort real regressions from preference artifacts and cost mechanics in § 6.

Boris Cherny, Claude Code lead at Anthropic, posted on release day: "It took a few days for me to learn how to work with it effectively."

Why Read This, and Why Now

Reddit calls 4.7 a regression. Arena shows 4.6 winning on instruction following. Anthropic's migration guide says it's working as designed. Boris confirms it's more agentic and precise.

The takes don’t agree because they’re measuring different workflows.

By the end you’ll know:

• The ten moves to make your 4.6 prompts work on 4.7

• Where 4.7’s cost really goes, and the ten highest-ROI levers

• What Cowork and Dispatch users lose vs the Code, and what I use on mobile instead

• How to decide between 4.6 and 4.7 for your own workflow

• You don’t need more instructions. You need better intent.

I’ve had 16+ hours with 4.7 so far. What follows is what changed, what to do about it, and resources section at the end.

Subscribe now

1. What’s New in Opus 4.7

4.6 filled the gaps when your instruction was unclear. 4.7 takes you at your word.

For PMs: if your 4.6 workflow relied on the model “figuring out what you meant,” expect 4.7 to ask more questions, or to do less, or to do exactly what you asked for (which is not what you wanted).

2. Intent: The Universal Unlock

This is the principle: 4.7 rewards clear intent. Everything else in this post is a tactic.

Not longer prompts, not more rules, not a bigger CLAUDE.md. Intent splits into two layers:

• Strategic context is durable: what you’re building, who it’s for, what’s off-limits, what good looks like. Write it once. Put it in CLAUDE.md. It loads every session, progressive-disclosure style, so you’re not paying to reintroduce the project on turn one.

• Per-task intent is variable: what specifically do I want Claude to do right now. You still write this every turn. The gain from CLAUDE.md is that you stop retyping the strategic context on top of it.

The full version (seven components, how they compose) is in The Intent Engineering Framework for AI Agents, published three months before 4.7 shipped:

This is perfectly aligned with Karpathy’s Claude coding post, too:

“Leverage. LLMs are exceptionally good at looping until they meet specific goals and this is where most of the “feel the AGI” magic is to be found. Don’t tell it what to do, give it success criteria and watch it go (...) Change your approach from imperative to declarative to get the agents looping longer and gain leverage.”

Anthropic and OpenAI convergence

Anthropic moved Opus 4.7 toward more literal instruction following. OpenAI updated their December 2025 Model Spec to say “consider not just the literal wording but the underlying intent.”

They’re converging from opposite directions. Anthropic is adding precision to its intent-first model. OpenAI is adding intent inference to its precision-first model. The same skill (engineering intent clearly) is becoming the unlock on both sides.

And Anthropic is already encoding it

Managed Agents (research preview) bakes success criteria and outcomes into the framework itself. I recently covered it here:

The skill of engineering clear intent is what transfers across vendors and models. That’s why it has the longest shelf life right now.

Subscribe now

Side Note: On May 9, we’re launching Hands-On Claude Code Certification. In 4 weeks you will learn everything to ship full agentic products — UI, agentic harness, evals, guardrails, and ops — with Claude Code. Real apps, not demos.

Secure your spot (40% off)

Most students expense this through their companies.

3. The 10 Claude Opus 4.7 Migration Moves

3.1 Front-load intent in CLAUDE.md

You don’t have to retype the strategic context every session. Put it in CLAUDE.md once. Every future session starts with the context already loaded. You still write per-task intent each turn, but you stop paying the “remember what we’re building” tax.

Delegate information the agent doesn’t have to read every session to other files, like strategy.md below:

3.2 Default to Extra high (xhigh)

New effort level between high and max. Anthropic’s own recommendation for coding and agentic work.

max is prone to overthinking. Most “4.7 feels slow” reports trace back to people running max by reflex. Use max only when the problem actually needs deep reasoning.

3.3 Toggle effort mid-task

Effort is per-call, not per-session. max for the hard subproblem. Drop back to high for the rest.

3.4 Regression-test old prompts

New tokenizer. 1.0 to 1.35× more tokens per input. Your 4.6 workflows cost more on 4.7 before you’ve changed a line.

The offset to know about: Anthropic raised rate limits alongside the 4.7 launch:

My perspective: what matters most is cost per correct output token. Test it for your specific product before switching the model.

3.5 Batch questions. Stop drip-feeding.

If you have three questions, ask all three in one message.

On 4.6, clarifying across 3-4 turns worked. On 4.7, each turn adds reasoning overhead on top of literal interpretations from earlier turns.

Treat clarification as an exception, not a workflow.

3.6 Show what you want

Positive examples beat negative rules. According to Anthropic:

• “Like this: ” followed by short examples works.

• “Don’t do this: ” rarely lands and burns tokens trying.

If your prompt has more than three “don’t” or “never” lines, flip them. What does the ideal output look like? Show two examples and cut the rules.

3.7 Delete old progress scaffolding

“Summarize every 3 tool calls.” “Give me a status update before moving on.” “Explain your plan, then execute.” Delete these.

4.7 emits high-quality progress updates natively in long agentic traces:

3.8 Tell it to fan out explicitly

4.7 spawns fewer subagents by default and makes fewer tool calls per task. For parallel exploration, you now have to ask.

Phrasings that work: “spawn subagents in the same turn to investigate X, Y, Z.” Autonomy went up. Default delegation went down.

I also added separate instructions for Dispatch in DISPATCH.md. This file is referenced from CLAUDE.md:

Later, I explain why I started using Dispatch less often.

3.9 Review plans, not diffs

Two different primitives. Don’t confuse them.

• Plan mode (Shift+Tab twice in the Claude Code CLI): inline, surfaces the plan before any code exists in the current session. Use for any change that touches more than one file:

• /ultraplan (CLI only, doesn’t work in VS Code extension): cloud-based plan drafting from the CLI, review in the browser. Plan runs in a remote session while your terminal stays free:

Why this matters more on 4.7: because 4.7 takes intent literally, a small misread in the plan becomes a large misread in the diff. Reviewing a 10-line plan for intent drift takes 30 seconds. Reviewing a 200-line diff for the same drift takes 15 minutes.

My take:

Intent drift compounds. Catch it in the plan.

3.10 Adaptive thinking only

Fixed thinking budgets are gone. Use thinking: {type: 'adaptive'} plus the effort parameter. Old API calls with budget_tokens return HTTP 400. Find and replace before flipping the model flag:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    messages=[
        {
            "role": "user",
            "content": "Explain why the sum of two even numbers is always even.",
        }
    ],
)

If you’re not an engineer, you don’t need to memorize the syntax. Just give your agent this documentation: https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking.md (remove “.md” for a human-friendly view).

Everything above is the mental model. Below, the execution: 10 highest-ROI moves for 4.7 that actually move the bill, my remote setup, and Cowork/Dispatch gotchas 👇

4. Cost Control on Opus 4.7

$20/month is enough to poke at Claude. It’s not enough to run agents. And 4.7 is more expensive than 4.6 by default. New tokenizer (1.0–1.35× tokens per input), adaptive thinking with generous budgets, high-res vision at 3× tokens.

Ten highest-ROI moves (can cut tokens significantly; in my setup, 60–80%):

Read more

Everyone's covering agents helping you build or do knowledge work. The pattern nobody's explaining: the same primitives are the production runtime.

What you’ll learn:

• The Claude Code primitives that double as a production runtime

• When to pick the Anthropic Agent SDK

• The architecture — one function call replaces an n8n-style workflow

• A full working demo: source code, build prompt, hosting notes

• The gotchas that silently break things

• How to host your Claude Code agents in production

1. The Missing Pattern — Agent as A Callable Component

Two narratives dominate right now:

• Agents as products. Claude Code, Lovable, Cursor. You use them to code or to do your work.

• Agents as infrastructure. Claude Managed Agents, CrewAI, LangGraph.

The pattern sitting between those two is agent as a callable component inside your app.

How does it work?

Your web app handles routing, auth, CRUD, form validation. When a request needs reasoning, you call the agent — which runs in a sandbox with its own CLAUDE.md, skills, and MCP servers.

The part that surprised me: the same .claude/ folder I've been editing every day for months is the deployable unit. There is no translation layer between dev and prod. The CLAUDE.md that guides Claude Code in your terminal is the exact same CLAUDE.md format that runs in production.

Subscribe now

2. The Primitives You Already Use

Five key things. We've discussed most of them in the previous posts about Claude Code and Cowork:

• CLAUDE.md — the agent’s identity in markdown. Tone, rules, constraints. In dev it shapes how Claude Code behaves in your terminal. In prod it loads as the system prompt of your production agent. Edit the file, ship the behavior.

• Skills (.claude/skills/) — reusable behaviors, also markdown. Same file format in dev and prod. Same loader.

• MCPs (.claude/mcp.json) — servers that extend the agent’s tool surface. Your dev config probably talks to Chrome and your filesystem. Your production agent’s config talks to your search API and your database. Different servers, identical contract.

• Hooks — functions that fire on tool events. PreToolUse can block dangerous operations (reading .env, path traversal). PostToolUse can log everything the agent read so you can show it in the UI.

• Sub-agents (.claude/agents/<name>/) — each directory is a self-contained agent: its own CLAUDE.md, its own skills, its own MCP config, its own docs. Adding a second agent to your product is a new folder.

Everything is files. Everything is version-controlled. Everything diffs cleanly in a PR. If you've onboarded to Claude Code, you've already onboarded to the production stack.

In case you wondered, here’s a bigger picture:

Subscribe now

3. Why This Matters in Production

Here’s how it stacks up against the alternatives:

Four things fall out of this that I didn't expect going into the spike:

• Nothing new to learn. The CLAUDE.md you wrote in dev is the CLAUDE.md that ships. Your muscle memory is already the production runtime.

• You can skip Claude Managed Agents unless you actively need a hosted runtime. For request-response agents inside an app you already host, the SDK is a smaller dependency than a whole platform.

• Full observability. Hooks give you live per-response metadata — cost, duration, files read — for your UI. OTEL exports full traces to Langfuse or any OTLP backend when you need it.

• Same loop, dev → prod. The config you tested in Claude Code is the config running in production. If it worked in your terminal, it works in your app. No mental translation.

For PMs: this is what lets you prototype and ship agent features without becoming a bottleneck. Changing the agent's behavior is editing a markdown file — not a sprint, not a code review, not a redeploy cycle. You iterate on AI behavior at the speed you iterate on a Notion doc.

Now the part most people skip — how you actually wire it up.

4. The Architecture — One Function Call Replaces a Workflow

In n8n you wire it up node by node. A single agent has system prompt, LLM, model, tools, and memory.

A single Claude agent isn’t a workflow. Inside an app, you don’t need a node-by-node graph around it — simple orchestration and guardrails live in your hooks or your business logic.

In the SDK it's this:

for await (const msg of query({
  prompt: question,
  options: {
    cwd: './.claude/agents/knowledge-agent',
    settingSources: ['project'],
    allowedTools: ['Read', 'Glob', 'Grep'],
    maxTurns: 5,
    maxBudgetUsd: 0.15,
    model: 'claude-sonnet-4-6',
    hooks: { /* guardrails */ },
  },
})) {
  // stream text to the user, collect metadata
}

settingSources: ['project'] is the auto-loader. It reads the agent's CLAUDE.md, skills, and MCP config from agent’s working directory (cwd). Same behavior Claude Code has when it opens a session. You don't manually load anything.

The boundary is clean. Your app owns the request lifecycle, auth, storage. The agent owns reasoning, tool selection, iteration. One function sits on the seam. That's the entire orchestration layer.

Share

5. The Demo — Knowledge Chatbot

I built the smallest thing that shows the pattern: a web app with markdown files and a chatbot that answers questions using those files, with memory across turns.

The agent lives in its own directory:

Stack:

• Next.js 15 standalone (not serverless — the SDK spawns a full Claude Code runtime, not a lightweight API client).

• SQLite for conversation memory because this is a prototype. Postgres, Redis, a JSON file on disk — all fine.

Adding a second agent? New folder in .claude/agents/. Give it a CLAUDE.md. Point cwd at the new directory. Same structure every time.

Keep reading for:

• The prompt that scaffolds the app — paste into an empty repo, Claude Code builds the rest.

• Full source code — Knowledge Chatbot, streaming responses, per-message cost metadata.

• The lib/agent.ts wrapper with the TypeScript pitfalls the SDK docs skip

• The postbuild trick that stops production from inheriting your repo’s CLAUDE.md.

• The limitations I hit in the spike and the workarounds for each.

• How to easily host this in production.

Read more

I run Claude Code on a Max plan. 440 sessions last month, 18,000 turns. I built a dashboard to track what that actually costs: $1,588 in API-equivalent tokens. Covered by a $200 subscription.

Here’s the full breakdown — what April 4 killed, which API models actually work for agentic coding, and how to see exactly where your budget goes.

What You’ll Learn

• What April 4 actually killed — which tools lost subscription access and why Anthropic pulled the plug

• The full cost landscape — subscriptions and API models in one table, ranked by the metric that actually predicts agentic performance

• Why SWE-bench is misleading — it didn’t match my experience. Agentic Index did.

• OpenRouter setup: two environment variables, 400+ models, done

• Token visibility: an open-source dashboard that shows exactly where your Claude Code tokens go

Subscribe now

1. The April 4 Policy Change: What Died, What Lives

April 4, 2026: Anthropic announced Claude subscriptions no longer work with third-party tools. If you were using Cline, Cursor, Windsurf, OpenClaw, or any non-Anthropic harness through your subscription — it stopped working.

What Still Works with Subscriptions

• Claude Code CLI — Anthropic’s official agentic coding tool

• Claude Code extension for VS Code — same mechanism

• Claude.ai — web and mobile interface, including agentic Code sessions

• Cowork — user-friendly agent inside Claude Desktop

• Dispatch — the orchestration layer for Cowork and code

What Died

• Cline — popular VS Code agent, relied on subscription auth

• Cursor — AI-native editor, subscription routing cut off

• Windsurf — Codeium’s editor, same story

• OpenClaw — open-source Claude Code alternative with 135,000+ instances

• Custom agents and automation — anything routing through subscription billing

For automation workflows (n8n, OpenClaw, custom agents): You’re on API billing now. The next section shows you exactly what that costs — and why it might actually be cheaper than you think.

—

OpenClaw footnote: A community workaround briefly routed OpenClaw through Claude Code’s MCP bridge. Anthropic closed it — one exact substring match to block OpenClaw’s system prompt.

2. The Full Cost Landscape

Many builders and PMs either overpay for a subscription they don’t fully use, or overpay for API models because they default to Sonnet. Here’s everything in one place.

Claude Subscriptions: Flat Cost, Predictable

Every tier requires discipline. Opus burns credits ~5x faster than Sonnet, so use Opus for hard problems and switch to Sonnet for straightforward tasks. Run /compact regularly. Without this, you’ll hit limits on any plan — including Max 20x.

How cheap is this compared to API? My Max 20x costs $200/month. The dashboard I built (Section 4) shows $1,588 in API-equivalent costs for Claude Code alone — and I use Code and Cowork roughly 50:50, so the real API bill would be far higher. The Claude subscription runs roughly 15-30x cheaper than paying per token for the same work.

Teams and Enterprise subscribers: If your company already provides Claude Teams or Enterprise, you have Claude Code access included. Check with your admin — you may not need a personal subscription at all.

API: Pay Per Token, Choose Your Model

OpenRouter gives you access to 400+ models. Most aren't worth your time for agentic coding. I tested dozens — the table below is what survived real multi-step Claude Code sessions, ranked by Agentic Index:

Why Agentic Index?

• SWE-Bench (Verified and Pro) tests isolated bug fixes — one issue, one patch, no iteration. It didn't match my experience.

• Agentic Index (from Aider's polyglot benchmark) measures what Claude Code actually does: read files, plan changes, apply diffs, run tools, recover from errors, iterate. It matched what I saw in practice.

Claude Subscription vs API

Subscription wins if you code with Claude Code daily. Opus is the best agentic model — and cost per token isn’t cost per correct token. For the current model, see how that calculus shifted under Fable 5. A cheaper model that needs many iterations to fix its own errors costs more than Opus getting it right the first time. Cowork, Dispatch, and web-based Claude Code sessions also require a subscription.

API wins if your usage is moderate, spiky, or you’re running automation workflows. Opus and Sonnet via API are hard to justify when the subscription gives you flat-rate access — and budget models match or beat Sonnet’s agentic performance:

• GLM-5.1 — matches Opus 4.6 on agentic performance (67.0 vs 67.6) at 1/12x the input cost. Default for automation.

• GLM-5 — same family, cheaper. Matches Sonnet’s 4.6 agentic score at 1/4x the cost.

• MiniMax M2.7 — when cost matters most. 1/10x Sonnet’s 4.6 score. Still solid.

One Thing Missing: Token Visibility

The subscription model has one real frustration: you can't see where your tokens go. /usage exists but doesn't break down by model, project, or session — so when you hit limits unexpectedly, it's not obvious why.

Anthropic knows: there are open feature requests for per-prompt token breakdown and a real-time usage indicator. I built an open source solution — Section 4 covers it.

Subscribe now

3. OpenRouter Setup for Claude Code

Claude Code isn’t locked to Anthropic’s models. Switch ANTHROPIC_BASE_URL and it routes to any compatible API. Add a .claude/settings.local.json to your project root, for example:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "sk-or-v1-{your-OpenRouter-API-key}",
    "ANTHROPIC_API_KEY": ""
    },
  "model": "z-ai/glm-5.1"
}

Why OpenRouter over direct provider APIs?

One key, one endpoint, 400+ models. Switch between GLM-5, Qwen, Gemini, and GPT-5 by changing one variable—no juggling multiple API keys or base URLs.

Switching the API works for Claude Code CLI, but not for Claude Code Extension. In practice, this doesn’t make a huge difference, as you can still work with VS Code interface.

Step-by-step demo:

Side Note: Want to build with Claude? Join our AI Agents Claudathon — in 4 weeks you will learn everything to ship real agentic products with Claude Code. No experience required:

Learn more

P.S. This is not an external cohort. Just me and .

4. Claude Code Usage Dashboard: See Where Your Tokens Go for Free

I mentioned the visibility gap in Section 2 — /usage doesn’t break down by model, project, or session. You hit limits and have no idea why.

That frustrated me enough to build something.

I open-sourced a local dashboard that reads your Claude Code transcripts and shows you exactly where tokens go. No cloud, no telemetry — everything stays on your machine:

You can star it, fork it, and make it your own. GitHub (open source, MIT):

Claude Code Usage Dashboard

What It Shows

• Cost per day, broken down by model (Opus vs Sonnet vs Haiku)

• Sessions and turns over time

• Filter by model, filter by time range (7d / 30d / 90d)

• Top projects by tokens — see which codebase is eating your budget

• Auto-refreshes every 30 seconds at localhost:8080

My 30-Day Numbers

440 sessions. 18,000 turns. $1,588 in estimated API costs.

All covered by the Max subscription. For a fraction of the price.

First thing the dashboard caught: one day spiked to 700 million cached tokens. Not my usage — an Anthropic bug. Without the dashboard, I’d never have noticed.

Setup & Run on Windows

git clone https://github.com/phuryn/claude-usage
cd claude-usage
python cli.py dashboard

Setup & Run on MacOS, Linux

git clone https://github.com/phuryn/claude-usage
cd claude-usage
python3 cli.py dashboard

What It Measures

Claude Code Usage Dashboard works with any Claude subscription (Pro, Max, Team, Enterprise) running Claude Code — CLI, VS Code extension, and dispatched code sessions.

At the same time, Cowork and web code sessions are not included. We need to wait for Anthropic for a better solution.

5. Token-Saving Techniques (Works Everywhere)

Before switching models or tools, optimize what you’re already doing. These apply whether you’re on subscription or API.

Use /compact Aggressively

Context accumulates fast. Every file read, tool call, and response adds tokens. A 30-minute session easily hits 200K tokens, and you’re paying for all of it on every subsequent message.

Run /compact after major milestones. It preserves intent and drops noise.

Don’t Use Opus for Everything

Opus 4 costs 5x more than Sonnet ($15/$75 vs $3/$15 per M tokens). For most coding tasks, Sonnet is equivalent—and GLM-5.1 matches Opus on agentic tasks at 1/12th the cost.

If you struggle with available tokens, use Opus only for:

• Complex architectural reasoning when Sonnet keeps failing

• Long-context analysis where every detail matters

• Tasks with extreme ambiguity

Default to Sonnet or GLM. Escalate to Opus when the model fails.

Watch for MCP Tool Overhead

MCP tools can easily add ~20K tokens to every session just from tool definitions.

While by default they are loaded on demand in Opus and Sonnet, this may not work with custom LLMs. Remove MCP servers you don’t need by typing /mcp in Claude Code CLI.

Hint: This is where you can adjust default settings for Opus and Sonnet:

  {
    “env”: {
      “ENABLE_TOOL_SEARCH”: “true”
    }
  }

Code Graph MCP: Feed Claude Only What It Needs

Every time Claude Code reviews a change, it searches your codebase with grep and glob — smart, but not structural. It doesn’t know which functions call what.

code-review-graph adds that structural layer. It parses your codebase into an AST, stores it in SQLite, and tracks changes via git hooks. At review time, it traces the blast radius of your change and feeds Claude only the affected files.

The author’s benchmarks: 6.8x fewer tokens on code reviews, up to 49x on daily coding. On a 27,700-file monorepo, only 15 files were read.

I haven’t tested these numbers myself, I currently don’t work with such large codebases, but the architecture makes sense — especially for large codebases where the savings compound.

Agent-Browser: Browse Without Screenshots

If your agents need browser access, don’t use Chrome MCP with screenshots — each screenshot eats thousands of tokens for a single page view.

agent-browser by Vercel Labs takes a different approach: instead of screenshots, it returns an accessibility tree snapshot with element references (@e1, @e2, etc.). Agents interact via those refs — compact text, not images. The result: 82% fewer tokens than Playwright MCP, up to 93% reduction overall.

It’s also much more reliable than the standard web fetch:

No configuration needed. Works with Claude Code (tell it to use it in CLAUDE.md) and any MCP-compatible agent. Installation:

npm install -g agent-browser

Subscribe now

8. Closing

Subscribe for daily coding — stop watching the meter. Route automation to GLM-5.1 for Opus-level agentic performance at 1/12th the cost. Track every token with an open-source dashboard so you know exactly what you’re getting.

Anthropic’s April policy change forced automation users onto API billing. But it also clarified the landscape: subscriptions for Anthropic tools, APIs for everything else.

For the terminology behind the numbers, use the AI PM glossary.

The one thing still missing: real token visibility from Anthropic. Until they ship it, the dashboard fills the gap. Clone it, see where your tokens go, and stop guessing:

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Next: prototyping for PMs (3 tools & templates). This will be a paid content.

Have a great week ahead,
Paweł

What You’ll Learn:

• A Knowledge Architecture block that turns Claude into a system that learns across sessions — not just a tool that forgets

• A Decision Journal block that logs every meaningful choice with full reasoning, so Claude (and your team) never re-debates settled decisions

• A Quality Gate block that gives Claude concrete evaluation criteria — because agents can’t objectively judge their own work

• A schedule suggestion that keeps the whole system from going stale

• The full integrated CLAUDE.md — all three blocks ready to paste

0. Memory Without Reflection

Claude remembers. It writes its own memories, reads your CLAUDE.md, follows your conventions. But it doesn’t reflect on what it knows.

It captured that your pricing test showed 40% churn. It captured that a competitor dropped their free tier. It captured that onboarding users churned less. Three separate observations in three separate sessions — and Claude never connected them.

Memory without reflection is just storage.

Claude now ships with built-in configuration — the .claude folder, settings files, rules. Boris Cherny, the creator of Claude Code, shared how his team uses CLAUDE.md internally — every correction becomes a rule, checked into git.

That’s a good foundation. But it’s a correction log. The system doesn’t promote patterns on its own. It doesn’t test its own hypotheses. It doesn’t evaluate whether its work meets project-specific standards.

The community has built impressive tooling on top of this. Some repositories catalog 135+ agents, 42 commands, and hundreds of plugins. Powerful systems for teams that want deep infrastructure.

Most builders need something they can paste in 90 seconds that makes Claude measurably better by next week.

Three blocks. Each one targets a different failure mode — learning, deciding, evaluating. Together, they turn memory into a system that reflects, connects, and compounds.

Subscribe now

1. Knowledge Architecture — The Learning Loop

The problem: Claude captures observations but never revisits them. Insights from last week's session don't inform this week's work. There's no mechanism to test whether a pattern holds, promote it when it does, or discard it when it doesn't.

The snippet:

Before starting a new task, review existing rules and hypotheses for this domain.
Apply rules by default. Check if any hypothesis can be tested with today's work.

At the end of each task, extract insights. Store them in domain folders, e.g.:
  /knowledge/pricing/         (or /onboarding/, /competitors/)
    knowledge.md  (facts and patterns)
    hypotheses.md (need more data)
    rules.md      (confirmed — apply by default)

Maintain a /knowledge/INDEX.md that routes to each domain folder.
Create the structure if it doesn't exist yet.
When a hypothesis gets confirmed 3+ times, promote it to a rule.
When a rule gets contradicted by new data, demote it back to hypothesis.

How it works: Before every task, Claude reads the existing knowledge — active retrieval, not passive storage. The value isn't in the files. It's in Claude checking them mid-session before making a recommendation.

After a month, I had a folder with 24 rules Claude applied automatically. I didn’t write those rules. They emerged from dozens of sessions. Claude was measurably better than day 1 — not because of better prompts, but because the system had been learning the whole time.

Want to build with Claude? Join our AI Agents Claudathon — ship real agentic products with Claude Code. No experience required. Limited to 60 students.

Learn more

2. Decision Journal — Reviewable Reasoning

The problem: Someone asks why you picked Postgres over DynamoDB. Or why you killed the freemium tier. Or why the onboarding flow skips the team invite step. Nobody remembers. So you spend 30 minutes re-debating a decision that was already made.