I start there on purpose. An AI strategy can only be as good as your picture of the work. And AI is changing that work in every function at once, from sales and finance to delivery and support.

The leaders I’ve seen get results from AI know their work well enough to keep redesigning it as the tools improve.

Subscribe now

What an AI-first mindset is

Here’s how I define it. An AI-first mindset is a habit. For every piece of work you do, you ask: if I were designing this today, knowing what AI can do, how would it run?

You start with the work and bring in the tool second. Keep asking, because the answer changes every time the models improve. A workflow you settled last quarter may deserve a fresh look this one.

Judgment stays with people. Some workflows will run on their own, and others you’ll work alongside. Either way, AI proposes, and you decide.

In practice, AI-first means every workflow gets a fair hearing, including the ones you’ve run the same way for years.

Start with the value chain

When I teach AI strategy to leaders at Berkeley Haas and in my cohorts, we start with the value chain, before any tool.

Michael Porter gave leaders the value chain in Competitive Advantage (1985). His insight was that competitive advantage lives in the specific activities a firm performs to design, sell, deliver, and support what it offers.

Porter sorted those activities into two groups. Primary activities create and deliver the offer, such as operations, marketing and sales, and service. Support activities make them possible: your people, technology, procurement, and the firm’s infrastructure. Each activity drives your costs or shapes the value a customer sees. The links between activities matter just as much.

That same year, Porter and Victor Millar wrote in Harvard Business Review that information technology was changing the value chain itself: how each activity gets done, and how the activities connect. AI is doing the same thing now, and it's reaching work that used to require a person, like research and first drafts.

That’s why AI strategy has to work at the level of activities. AI doesn’t transform “marketing.” It transforms how you research a prospect, draft a proposal, and review the pipeline on Monday morning.

Where AI advantage comes from

Porter drew another line that matters for every AI plan. In “What Is Strategy?” (HBR, 1996), he separated operational effectiveness from strategy.

Operational effectiveness means performing the same activities better than your rivals. You need it, and your competitors will copy it, so the gains don’t last. Strategy is a different kind of choice. In Porter’s words, “Competitive strategy is about being different. It means deliberately choosing a different set of activities to deliver a unique mix of value.”

When every firm buys the same models to speed up the same activities, everyone gets faster together. That’s operational effectiveness at scale, and no one pulls ahead.

Advantage comes from using AI to reshape your own value chain. You perform activities your rivals don’t, or you perform shared ones in a way that runs on your know-how. Porter called the way activities reinforce each other fit, and he argued fit is what makes a strategy hard to imitate. A competitor can buy the same AI. It can’t easily copy a whole system of workflows built around how your firm creates value.

Competitive advantage shows up in the P&L

In my cohorts, I put up a slide built on Joan Magretta’s Understanding Michael Porter, her guide to his work. In Porter’s framework, competitive advantage links three things: the value you create, how you create it (your value chain), and how you perform (your P&L).

Advantage shows up in the numbers. Compared with rivals, you run at a lower cost, charge a premium price, or both. Activities in your value chain drive both levers.

The other half of that slide comes from Felix Oberholzer-Gee’s Better, Simpler Strategy, and I find it especially useful for AI. He calls it the value stick:

• Willingness to pay. The most a customer would pay. Raise it, and you create customer delight.

• Price. What the customer actually pays. The gap between price and cost is your margin.

• Cost. What you pay employees and suppliers.

• Willingness to sell. The least an employee or supplier would accept. Lower it by improving the work, and you create employee satisfaction and supplier surplus.

The value a firm creates is the distance between willingness to pay and willingness to sell. You can widen it from either end. If you want to go deeper, Oberholzer-Gee lays out the value stick in his HBR article, “Eliminate Strategic Overload.”

So when I look at a workflow to reimagine with AI, I ask what it moves. Take proposal drafting. If AI cuts the first draft from a day to an hour, that lowers cost. If the hours saved go into tailoring the proposal to the client, that can raise what the client is willing to pay. If the person drafting spends less time on boilerplate and more on thinking, the work gets better too. If a workflow moves none of these, it’s activity, and it won’t show up in your results.

I tell the leaders in my cohorts the same thing every time: this isn’t a science project. We’re using AI to deliver outcomes in the P&L.

The map becomes a strategic canvas

It all starts with seeing your chain. What do you offer? Which processes deliver it? Inside each process, which workflows run, and in what order?

A process is an outcome your business delivers, like winning new clients. A workflow is one repeatable piece of work inside it, like researching a prospect before the first call.

Order matters more than it looks. When workflows follow the sequence the work actually happens in, you can see how value moves through the business, and where it gets stuck.

Once I could see my workflows that way, I could start making choices about them. I sort each one into a group:

• Reimagine. Work that could run in a different way with AI. In my business, email triage, research, and first drafts all landed here.

• Protect and deepen. Work where your judgment and relationships create the difference clients pay for. Aim AI at making the people who do this work better, and keep investing in them.

• Hand off. Work that has to happen but doesn’t set you apart. Delegate it to a partner, a platform, or an agent, and keep your attention on the work that does. Porter put it plainly: “The essence of strategy is choosing what not to do.”

The map shows one more thing: gaps. A process with no workflows behind it is either work no one owns, or an opportunity waiting to be built.

You can’t safely hand off a workflow you haven’t mapped, because you can’t tell whether it’s core. The groups also shift. Work that’s core today can become routine as models improve, so the map must stay current.

This also changes the old build-or-buy question. You now answer it workflow by workflow: build what’s core to your know-how, buy what a platform already does well, and partner on the rest. You can only make those calls once you can see the workflows.

Your know-how lives in your workflows

Much of a firm’s intellectual property lives in how its people do the work: the first questions a senior consultant asks, or the checks a finance lead runs before anything leaves the building.

When that knowledge stays in someone’s head, no one else can improve it or build on it with AI. When that person leaves, it goes with them.

Once you name a workflow and link it to the outcome it serves, the firm keeps that know-how as an asset. Link it to the skills and agents that power it, and you can see where AI is doing work in your business, and why.

The method I teach: understand the work, then catalog it

In both of my cohort courses, Hands-on Agentic AI for Leaders and Agentic AI for Claude Builders, students map their work first. In the first session, they catalog it in what I call an AI Registry. They practice building skills and agents along the way, and the registry ties each one to the workflow it serves. By the last week, it records every workflow they built.

I run my own business the same way. My AI and I catalog every line of business, process, and workflow. As of this week, that’s 27 processes and 77 workflows, each with a status. Every workflow page links to its process and to the skills and agents behind it. I don’t write the pages by hand. My AI drafts them with me as the work happens, and I check that they say what I mean.

The registry is the page I open most days. When I start a new workflow on Claude, it first opens a registry page linked to the process it strengthens. When I ask my AI which workflow to design next, it follows those links and answers from my own chain of work. Without them, I’d get generic advice.

The work is the craft

I built every one of my workflows, and I still find it hard to remember them all. The registry keeps me close to them. Each time I open it, something catches my eye: a process with nothing behind it, or a skill I built that no workflow uses yet.

Understanding the work we do shapes our ability to get the outcomes we want, in business and in life. I believe we need to see, touch, and improve our workflows every day as we practice our craft. AI amplifies judgment, and that judgment comes from staying close to the work.

Start with the workflow that frustrates you most, or the one you’d struggle to explain to a new hire. Either is a good place to ask the AI-first question.

Try this (30 minutes). Pick one line of business. List its processes, then write the workflows inside one process in the order they run. Mark each one: reimagine, protect, or hand off. For each one you’d reimagine, note what it moves: willingness to pay, cost, or the work itself.

See my value chain, then build your own

To see how this works in practice, I showed it in my latest Lightning Lesson, a free 45-minute live session on Maven: Map Every Workflow You Run on One Page. I open my AI Registry and walk through my business as a value chain. I trace one workflow up to the outcome it serves, then ask my AI which workflow to design next. Watch the recording →

If you’d like to go further with me, both of my cohort courses start Monday, November 9:

• Hands-on Agentic AI for Leaders, cohort 21. Four weeks building the skills and agents behind your workflows on Claude, ChatGPT, M365 Copilot, or Gemini Enterprise.

• Agentic AI for Claude Builders, cohort 8. Five weeks building the skills and agents behind your workflows on the Claude platform.

No matter where you start, the ideas are the same. An AI-first mindset starts with the work; the tool comes second. Every firm can buy the same models, so advantage comes from how AI reshapes your own value chain. And it has to show up in the P&L.

So map your processes and workflows. Decide what to reimagine, what to protect, and what to hand off. Then keep the map current as the models improve, because the right answers will change.

You don’t need a course to begin. The 30-minute exercise above is enough to start this week.

Stay curious. Stay hands-on.

James

When to use subagents, and when one Claude with good skills does the job better

TL;DR

• Just use Claude. Anthropic found that a single agent with skills often beats a team of subagents. For you, that agent is Claude itself.

• Splitting work costs context. A subagent is handed a job and a summary. It never sees the full picture.

• Use a subagent for three jobs: heavy reading, parallel work, and fresh-eyes review.

• Everything else is a skill. Task, reference, and orchestration skills cover most business work.

• The test: does this work need to know what we’ve been discussing? If yes, it’s a skill.

You open Claude and set up a team. A marketing agent, a sales agent, a finance agent. Maybe an operations agent to tie it all together.

It feels like good management, but it’s usually the wrong AI design.

This week Anthropic published guidance from its Applied AI team on folding subagents back into the main agent. Across several enterprise deployments, a single agent with skills often beat multi-agent designs in quality. It also cost less and ran faster.

That single agent already exists. It’s Claude, the one you use every day. Your job is to give it great skills.

Anthropic’s article targets developers building production agents. But the lesson applies to every leader setting up Claude for their team. Here’s how I’m teaching it.

First, the key terms

Claude is already an agent. When it searches the web, reads your files, or uses a connector, it’s acting as an agent. You don’t need to build a separate agent first.

The main agent loop is how that works. Claude reads the context, picks a tool, checks the result, and decides the next step. It repeats until the job is done.

A subagent is a second Claude the main one sends off on a task. It gets its own fresh context, does the work, and sends back a summary.

So for anything you set up in Claude, the real decision is narrower: should it be a skill or a subagent?

• A skill is a playbook. It tells Claude how your team does something. Claude loads it when relevant.

• A subagent is a contractor. Claude sends it out to do a separate job and report back.

Think about your next board update. You’d hand your chief of staff the template, because they already know the context. You wouldn’t send it to an outside writer who missed every meeting that shaped it.

The template is the skill. Your chief of staff is Claude, with the full context of your conversation. The outside writer is the subagent: capable, but starting cold.

Skills come in three types:

• Task skills teach Claude how to do one job well, every time. Drafting a proposal, scoring a lead, writing a board update.

• Reference skills give Claude what it needs to know. Your brand voice, pricing rules, product specs, policies.

• Orchestration skills run an end-to-end workflow. They sequence the steps and call on task and reference skills along the way.

Why the org chart design breaks

Systems tend to mirror the organizations that build them. That’s Conway’s law, and Anthropic sees it often in enterprise agents. Each team gets its own agent, and the architecture ends up mirroring the org chart.

Three things go wrong:

• Context gets lost. Each subagent sees only what you pass it. Details drop out at every handoff, like a game of telephone.

• Instructions conflict. Every team adds its own rules. Anthropic calls the result a “Frankenprompt.”

• Speed suffers. Each handoff is another model running its own loop. One customer saw roughly 2x faster runtime after moving to a single agent.

The higher cost is insight, because one Claude that saw every step can connect the dots in ways a stack of summaries can’t.

Leader Lens

Dividing work by function is a sound management habit for people, but it transfers poorly to AI. Older models needed tasks broken up and handed to specialists. Since Opus 4.5, models plan, check their own work, and handle far more in one loop.

So the leadership question shifts from “who owns this agent?” to “who owns the playbook?” Let teams own their skills, and keep one owner for how Claude works overall.

Why one Claude can handle more now

The old reason to split work was overload. Load every playbook and tool up front, and Claude wades through instructions it doesn’t need for the task at hand.

The answer is called progressive disclosure. It means Claude gets information in stages, only when a task needs it. Think of how a good team onboards a new hire. On day one, they get a list of the playbooks that exist, and they open a specific one only when the work calls for it.

Claude handles skills the same way. It sees a one-line description of each skill and reads the full playbook only when a task needs it. Tools work the same way through a feature called tool search: Claude sees tool names and pulls up the full details only when it’s about to use one.

In Claude’s apps, this happens automatically. You can connect many skills and tools without slowing Claude down. Anthropic cut Claude Code’s system prompt by over 80%, partly by doing this.

The trade-off is that Claude can only pick the right skill if its description is clear. Vague or overlapping descriptions can confuse two skills. A one-line description that names when to use the skill is worth the extra minute.

When a subagent earns its place

Anthropic’s article reserves subagents for specific jobs. Translated for business work, there are three.

1. Too much reading. The task would flood your conversation with material you’ll never look at. Example: “Review these 50 customer interviews and return the top five themes.”

2. Parallel work. Several independent jobs can run at once, each with fresh context. Example: “Research these six competitors’ pricing at the same time.”

3. Fresh eyes. You want a reviewer who didn’t produce the work. Example: “Critique this proposal as a skeptical CFO who hasn’t seen my draft.”

If none of these apply, it’s probably a skill.

The one-question test

Ask this about any task:

Does this work need to know what we’ve been talking about?

• Yes: keep it in the main conversation. Capture the know-how as a skill.

• No, I just want the answer back: it’s a subagent candidate.

For most business work, the answer is yes. Proposals, analysis, planning, and writing all depend on shared context, and one Claude keeps it intact.

Try this (10 minutes). List any subagents, projects, or saved instructions you’ve set up in Claude. Run each one through the test: should it be a skill or a subagent?

Skills first, agents second

This is why my cohorts spend a full week, and then some, on skills before we touch agents. That week is often where leaders get the most value.

My guidance, in my courses and with every leader I advise, is the same. Start by building skills for your specialized tasks, and get the most out of them before anything else. Skills are where your unique expertise lives. They’re how you package what you know so Claude can use it every time.

Writing a skill also asks you to do something. You have to put into words how you actually do the work: the steps, the judgment calls, the standards. It requires the same clarity as good delegation to people.

In my experience, these three skill types cover a surprising amount of work, and orchestration skills carry the most weight. One orchestration skill gives you much of what people expect from a multi-agent system. You get a coordinated, multi-step workflow without a single handoff.

Once you’ve built a few of each, add subagents only for the three jobs above.

The 15-minute sorting exercise

I use this with leaders in my cohorts. It works best with tasks from your real calendar.

1. List five to seven recurring tasks from your actual week.

2. Is it a procedure, reference, or multi-step workflow? Make it a task, reference, or orchestration skill.

3. Is it heavy reading, parallel, or a review? It’s a subagent candidate.

4. Neither? Ask Claude directly. No special setup needed.

Expect most of your list to land in steps 2 and 4.

Keep what holds up

Anthropic’s closing advice is simple discipline: measure, change one thing at a time, and keep what works.

Applied to your setup, that means one rule. Before building a new agent, try the task with one Claude and a good skill. Add a subagent only if the result is clearly worse without it.

So over the next two weeks, take the top orchestration skill from your sort, build it, and run it on real work at least three times.

Once you’ve run the sort, post your top orchestration-skill candidate in the comments. Seeing which workflows other leaders pick is one of the fastest ways to spot your own.

Source: Building agents: When to fold subagents into your main agent loop, Diane Sarkis, Anthropic, October 22, 2026.

A worked example from my course

If you’d like to see it all working together, here’s the example I use in class. In my Build Agentic Workflows with Skills lesson, I teach this framework with one worked example: the Opportunity Decision Brief. You hand Claude a business idea, and it returns a researched go, refine, or no-go recommendation for you to weigh.

It’s the whole post in one workflow. An orchestration skill does the coordinating. Four research subagents work in parallel, and a fifth writes the brief. You make the final call. (My next two cohorts start November 9.)

Opportunity Decision Brief workflow diagram: you clarify the idea, four research subagents work in parallel, a synthesizer writes the brief, and you decide

The dark boxes are where you stay in charge: clarifying the idea at the start and making the decision at the end. Everything in between is Claude’s work.

Below the line for paid subscribers:

• The full worked example: how the skill and its five subagents fit together, mapped to the one-question test

• The six design choices worth copying into your own orchestration skills

• The one piece I’d test folding back into the main Claude, and how to run that test

• The installable files, with setup steps for Claude and Claude Code

• How to adapt it for decisions in your own business

Read more

Nobody can hold that many in their head, so I stopped trying. My AI and I keep them all in one place, and I look there.

That place is my AI Registry. It’s the thing I open most days, and it’s one of my favorite things to teach. Here’s how it works and how I use it.

TL;DR

• Workflows multiply once you work with AI, and nobody can track them from memory.

• An AI Registry catalogs them in three levels: line of business, process, workflow. Each workflow has a status and lists the skills and agents that power it.

• The pages link to each other, and those links are what make the registry useful to your AI.

• I’m walking through mine live, free, on Thursday, October 22.

Name the work first

Once you work with AI, workflows multiply. Email triage, sales pipeline review, coaching session prep.

Each one is a piece of how your business creates value. Unless you capture it somewhere, it lives in your head, and know-how in your head can’t be improved, delegated, or handed to a new hire. Your AI can’t build on it either.

Naming the work also clarifies it: what you actually do, how the pieces link together, and what outcomes they produce. AI tools matter, but they create real impact only when they’re attached to named work and connected to an outcome. Get clear on the work first, and AI can help you build it.

Whether you work alone or lead a team, the result is an institutional record of what you do and how you do it.

So before I build anything, my AI and I name and catalog the work. I don’t write the pages by hand. My AI drafts them with me as we go, and I check that they say what I mean.

What the registry records

My registry is a folder of plain Markdown pages. Three levels form its spine, and each one orders the level beneath it:

• Line of business. What do we offer? Mine are Consulting, Learning, and Coaching, plus shared operations.

• Process. What do we do, and why? Lead Generation, Course Delivery, Student Support.

• Workflow. How do we do it? One page per workflow, with its status and the skills and agents that power it.

Here’s one thread through mine, top to bottom:

Learning (line of business) → Lead Generation (process, owned by my Marketing function) → LinkedIn Prospect Research (workflow), whose page lists the agent that does the research.

Skills and agents don’t get pages of their own. A workflow page links to them where they live, so there’s never a stale second copy.

What one page shows me

At first glance, the registry reads as one page. Top to bottom, it’s a value chain: what I offer, the processes that deliver it, and the workflows inside each one. As of this week:

• 25 processes and 69 workflows. The whole business in one view.

• 55 in production, 13 under development, 1 in backlog. Every build has a place and a status, so “where are we?” has an answer without a status meeting.

• 37 skills and agents that no workflow references yet. A check I run against the registry finds them. Each one raises a useful question: which workflow does this serve? I couldn’t see any of them before the map existed.

• One process with no workflows at all. An empty process is where my next build idea usually comes from.

If you lead a team

Leaders get asked three questions about AI. Where are we using it? What breaks if this tool or vendor changes? Which processes should we invest in next? A registry scoped to the part of the organization you lead answers all three, and because it’s a record rather than someone’s memory, it stays when people move on.

How I actually use it

A few habits, since this is the part people ask about most:

• New work starts as a registry page. When I have an idea for a workflow, my AI writes it into the registry as a backlog page before anything gets built. Then it has an address from day one.

• Status changes as the build moves. When a workflow ships, its page moves to in-production. The page always says where things stand.

• A weekly sweep catches what I missed. An agent scans what I’ve built and flags anything that isn’t in the registry yet, so nothing drifts out of view.

None of this takes much time, because my AI does the writing. My part is the judgment: naming the work well and deciding what’s worth building.

Why your AI should read it too

The registry is plain Markdown, so any AI that can open a folder can read it: Claude, ChatGPT, M365 Copilot, or Gemini.

Underneath the one page, every page links to the others: each workflow to its process and its outcome, and to the skills and agents behind it. Those links are the real value. My AI follows them, which turns the registry into context about my business.

So when I ask, “Given how my business runs, which workflow should I design next to strengthen Lead Generation, and why?”, the answer cites my own pages and proposes something that fits beside what’s already there. Without the registry, the same question gets generic advice. With it, the AI proposes, and I decide.

See mine, live

If you’d like to watch this in action, I’m teaching a free 45-minute Lightning Lesson on Maven on Thursday, October 22: Map Every Workflow You Run on One Page.

I’ll open my registry, trace one workflow up to the outcome it serves, and ask my AI which workflow to design next. Then I’ll show you a small first registry and how my AI and I set one up. You don’t need 69 workflows to start: one line of business and the work inside it is enough.

The last fifteen minutes are for your questions, and everyone who registers gets the recording.

Save your seat →

Bring a line of business you’d like to map. We’ll start there in the Q&A.

Stay curious. Stay hands-on.

James

I’ve gone through the launch posts, the help center, the desktop changelog, and my own account, and pulled out the updates that matter if you build with Claude. For each one, you get what changed, why it matters, and a 15-minute thing to try. The aim is to keep you productive on the platform you’ve already invested in.

TL;DR

• One Claude. Starting September 16, chat and Cowork are one conversation, rolling out plan by plan. Describe the outcome, and Claude decides whether it is a quick answer or a multi-step task.

• One memory. Memory now carries across chats and cloud tasks. A new “sensitive topics” setting is off by default, and it never saves four categories.

• One place your work lives. Since October 6, every new task on Pro and Max runs in Anthropic’s cloud. Your local folders stay on your machine. A project can also read synced sources such as GitHub and Drive from any device.

• Projects changed shape. A project is no longer a folder on your computer. The folder is linked context, and each old project now offers to move its files to the cloud as a one-time upload that is not kept in sync.

• Next step. Five things to check this week, listed under each section.

Six weeks ago, using Claude for real work meant choosing a tool before you started. Chat for a question, Cowork for a task, Design for a visual, and memory that didn’t follow you between them. Anthropic has collapsed that into one product in three releases: unified memory on August 25, the Cowork and chat merge on September 16, and cloud execution for every task on October 6. Projects changed shape along the way.

Each release is small on its own. Together, they change how a leader should set up Claude, what to tell a team about where data goes, and what a task costs. This edition covers the four changes, what each one means for a business user, and a 15-minute thing to try for each. Every claim below comes from Anthropic’s help center, launch post, or changelog, linked where it appears and listed again at the end.

1. Chat and Cowork are one Claude

What changed. The “Chat” and “Cowork” selector in the message box is gone. Anthropic’s help page on the merge has the full rundown, and here is the short version. You describe the outcome, the format you want, and the inputs Claude needs. Claude decides whether that is a two-line answer or a task that searches the web, reads your files, runs code, and returns a finished document, spreadsheet, or slide deck. Anthropic’s stated reason in its launch post: people used both and found deciding where a task belonged frustrating.

Longer tasks keep running after you close the laptop and show up on your phone, where you can answer a question or redirect the work. Several tasks can run at once. Claude Docs and Claude Slides launched in beta the same day, so a report and its matching deck can come out of the same conversation, and you can schedule the whole thing to repeat every Monday.

Why it matters. There is one product to roll out, one to teach, and one to govern. Any conversation can now turn into a task that runs while you’re in a meeting, which is where the time savings come from, and also why the next two controls matter.

One new control. In the prompt window, next to where you type, you pick how much Claude does before checking with you. Manual is the default: Claude asks before each action. Auto lets it work through the task with automated safety checks and no interruptions. It applies to the whole conversation, and you can change it any time. My advice is to start on Manual. You learn a lot about what Claude is doing on your behalf by watching it ask. In either case, Claude asks before permanently deleting any file.

The cost to know. Everything counts toward the same plan usage limit, and a task that searches, reads files, and writes a deck uses more of it than a chat reply. You can see usage in Settings > Usage, and it’s worth a look after the first week.

What carries over. Existing Cowork tasks, projects, connectors, skills, and files all move with you. Two things moved location. Cowork’s global instructions were folded into Instructions for Claude in Settings > Account (Anthropic’s help page calls it Settings > General), so if you had instructions in both places, you now have one set, and every conversation reads it. And Cowork tasks now sit in Recents alongside chats. The web search toggle is gone, since Claude searches when it helps. Research runs from /deep-research or the “+” menu.

Who has it. Pro and Max first, rolling out gradually, so two people on the same plan can see different versions. Team and Free follow “soon” with no date. Enterprise admins get at least 30 days’ notice, and they choose when to enable the Docs, Slides, and Design betas. For organizations that manage Claude Desktop centrally, the desktop changelog names November 10 as the date the unified experience turns on for every organization. Once an account has the new experience, you can't go back to separate Chat and Cowork.

Try this (15 minutes). Open Settings > Account and read your Instructions for Claude from top to bottom. The rules you wrote for Cowork tasks, such as where to save files or which format to produce, now apply to quick answers as well, and the rules you wrote for chat now apply to tasks. Resolve anything that conflicts. Then find the permission control in the prompt window and leave it on Manual for a week before you decide.

2. One memory across chat and tasks, with new controls

What changed. Memory is now a single store that chat and cloud tasks both read and write. Anthropic’s memory help page covers every control; the key ones are below. Claude saves memory as individual topics during the conversation, not as a summary written afterward, and you can ask it to “remember this” explicitly. Everything saved appears as a list of topics in Settings > Memory, where you can read, edit, or delete each one.

Each Claude Project keeps its own memory, separate from other projects and from general chats. A task that ran only on your computer keeps its memory with that task. Memory is fixed when a chat or task starts, so any changes you make apply from your next conversation.

The sensitive topics setting. This is new and worth understanding before anyone on your team turns it on. By default, Claude doesn’t save health, race, ethnicity, religion, politics, gender identity, or similar subjects to memory. A setting called “Include sensitive topics in memory” turns that on going forward. Every save on a sensitive topic then shows a notice above the message box so you can review it. Turning the setting off deletes the sensitive items already saved.

Four categories are never saved, even if you ask: government ID numbers, criminal history, financial account numbers, and immigration status. Anthropic’s rationale, as it told Engadget: “what some consider sensitive, others may consider useful for Claude to remember.” The decision sits with the user, not the admin.

For Team and Enterprise. Owners enable memory in Organization settings > Capabilities, and each member stays off until they opt in. Enabling memory doesn’t enable sensitive topics; each user opts into that separately. Owners can’t view or edit anyone’s memory. Turning memory off at the organization level immediately and permanently deletes every user’s memory data. Memory is unavailable to organizations with HIPAA, public-sector, or custom data-retention agreements.

Two details worth knowing. Deleting a conversation doesn’t delete the memory entries it created. Those are deleted individually from the topics list. Memory is included in data exports, so an export now contains what Claude has learned about you, as well as what you typed.

Try this (15 minutes). Open Settings > Memory and read the topics list from start to finish. Delete anything you wouldn’t want in a data export. If you run a Team or Enterprise plan, decide the org-level memory policy before the merge reaches your organization, because the off switch is permanent.

3. Your work now runs in the cloud

What changed. As of October 6, every new task on Pro and Max runs on Anthropic’s servers, not on your computer. Anthropic’s page on Cowork across web, desktop, and mobile spells out the rules, and they are fair ones. The “Only on your computer” option was removed from Settings > General. Anyone still set to local was moved to the cloud the next time they opened the desktop app, with a notice, and the move can’t be reversed.

Work already in progress stays put. Tasks you started on your computer before October 6 stay there until you finish them, each with a banner saying it runs only on this computer. Scheduled tasks that already run on your computer keep running there. New scheduled tasks run in the cloud.

In practice, a new session and its files are identical on desktop, web, and mobile. Start on your laptop, check on your phone, and finish on the web. Cloud scheduled tasks run even if no device is online. You get a phone notification when Claude finishes or needs you.

Where your files go. Local folders stay on your computer. Claude reaches only the folders you have connected, only through the desktop app, and only while the app is open. When a cloud task needs a file from one of those folders, Claude fetches a copy of that single file and nothing else. Deleting the session deletes the copies under the normal retention practices. Whether conversations help train models still depends on the “Help improve our AI models” setting in Settings > Privacy.

Trusted folders are a separate list. Under Settings > General, the Tasks section lets you manage trusted folders. Trusting a folder on a device lets Claude use it and the folders inside it without asking each time. It doesn’t add the folder to any session or project, and Claude may still ask when you add it to a session. Which folder a project reads is set in that project’s Context, covered next.

Three ways to give a task your files. Open any project, select Add next to Context, and the menu shows the three kinds of sources a cloud task can read.

• Uploads. Files or pasted text, stored with the project. A copy, frozen at the moment you added it.

• Synced sources. A GitHub repository, Google Drive files, a Notion workspace, or another connected app. The project shows “Synced” with a time. A GitHub source pulls the latest version when you select Sync. Drive files refresh automatically when you open the project and can be added only to a private project. Either way, the content is the same on desktop, web, and phone.

• Linked local folders. Desktop only. The folder stays on your computer, carries an “Only you” badge, and is readable while the desktop app is open on that machine. This option doesn’t appear in the web menu.

  

For a builder, use the synced source. My own knowledge graph lives in a GitHub repository, and that’s the “Synced just now” line in the screenshot above. A knowledge graph of Markdown files, or any Markdown file that lives in a GitHub repository, is available to every task on every device. One click on Sync pulls in your latest commit, and you don't have to copy anything into the cloud by hand. The local folder remains the right choice for files that can’t leave the machine.

What still needs the desktop app. Local file access, local connectors, driving a browser, and computer use. A cloud session can use them only while the desktop app is open on that computer. Close the app, and the session keeps running but loses local access.

If work has to stay on your machine. Anthropic’s answer, in the same page, is Claude Code in the desktop app, which keeps folders and history local. A Cowork task can be moved across: open it, select “Download task data,” unzip the download, open the folder in Claude Code, and run /port-task-data. To keep a copy of everything, select “Export your Cowork data” on the card on the desktop home.

Try this (15 minutes). Open Settings > General and select Manage next to Trusted folders. Remove any folder you’d rather Claude ask about each time, and don’t trust a folder that holds files you wouldn’t want copied into a cloud task. Then pick one working folder you reach for from your phone and add it to its project as a synced source instead.

4. Projects: your folder can stay linked or move to the cloud

What changed. A Cowork project used to be a folder on your computer. You created the project from the folder, and the project lived there. New projects are saved to your Claude account, and a folder is one kind of context inside them, listed under Context as a linked folder next to uploads and connectors. The project still holds the same things: instructions, context, scheduled tasks, and its own memory, separate from every other project. Anthropic’s projects help page walks through each one.

Open a project that was built on a local folder, and you get a decision. Under the linked folder sits a card titled “Move folder to the cloud,” with three choices: Move folder, Learn more, and Keep folder linked. Nothing moves until you say so.

What “move” means. Learn more opens a dialog that states the terms. It counts the files that will be uploaded to the project. The upload is one-time and not kept in sync. The folder is unlinked from the project once all files are uploaded. It excludes hidden files, dependency and cache folders, and files over 30 MB. It also shows how much of the project’s capacity is already used, since the uploaded files count against the project’s limit.

How to decide. The upload is a snapshot, so the question is whether the folder changes. A folder of reference material that is finished, such as a style guide, a set of templates, or last year’s reports, can move, and Claude can use it from the web and your phone. A folder that keeps changing, such as a knowledge graph or a working client folder, has two good homes. Keep it linked, or put it in a synced source such as a GitHub repository or Google Drive, which you can refresh with one click and access from every device. Moving it with the card is the one choice to avoid, since the project would read a copy that stopped updating the day you moved it. Keep folder linked means Claude reaches the folder through the desktop app while it is open. A cloud task fetches a copy of a single file when it needs one.

One more thing to check. Since the October 5 desktop update, a regular chat in a project can read the project’s linked folder. Before that, only a task could. A folder you linked before that update isn’t picked up automatically. Link it again and start a new chat.

Try this (15 minutes). Open each project built on a folder and make the call on the card. Move the folders that are finished. Keep the ones you edit linked, and confirm the link by asking Claude in a new chat to list the files it can see.

Five things to check this week

• Settings > General. Under Tasks, trust only the folders you’re comfortable a cloud task copying from.

• Settings > Account. Read Instructions for Claude.

• Settings > Memory. Read the topics list. Decide on sensitive topics. Set the org policy if you own one.

• The prompt window. Pick Manual or Auto for the conversation you’re in.

• Each project’s Context. Move finished folders to the cloud. Keep the ones you edit linked, or sync them from GitHub or Drive.

If something here doesn’t match what you see in your account, leave a comment. The rollout is gradual, and your screen may be ahead of mine.

Build with me. I love building with interesting people from all over the world, and the next chance is coming up. Agentic AI for Claude Builders Cohort 8 starts November 9: five weeks, built on your own workflows, on the Claude you just read about. Join the cohort and let’s build together.

Stay curious. Stay hands-on.

James

Read more from Anthropic

• Cowork is now Claude, the launch post

• Claude Cowork and chat are one Claude, the help page on the merge

• Use Claude’s chat search and memory, including sensitive topics and admin controls

• Use Claude Cowork on web, desktop, and mobile, including the October 6 cloud changes

• Organize your tasks with projects

• Claude Desktop changelog

• Using the GitHub integration, how repository sync works

• Google Drive connector, how Drive files behave in projects

Subscribe now

• I’m running a free 45-minute Lightning Lesson this Friday, October 2. Save your seat →

• One skill, four platforms: Claude, ChatGPT, M365 Copilot, and Gemini, all from one GitHub repo.

• Last Friday’s session didn’t record, so this is a second live run.

• Bring the skill you’ve been rebuilding in every tool.

Subscribe now

Last Friday I taught a Lightning Lesson on running the same AI skills on Claude, ChatGPT, M365 Copilot, and Gemini from one folder on GitHub. Afterward, I found out the recording didn’t process, which means no one can go back and watch it.

So I’m doing it again, live, this Friday. Same session, and this time the recording goes to everyone who registers.

Why this one matters to me

My skills hold how I work: my brand voice, my review checklists, the way I build a course. That’s my expertise, and I want it in a folder I can move, back up, and hand on, not locked inside one AI platform.

So all of it, 100 skills and 28 agents, lives in that one repo. Claude and ChatGPT install the set as a plugin. Copilot and Gemini take the same folder as a zip. When I change a skill, I change it once.

The idea I most want you to leave with is simple. The skill you built in one tool isn’t stuck there. Export it, and it’s a folder of files you own.

What you’ll see

• One skill, four platforms. My brand-voice skill writes the same LinkedIn post in Claude, ChatGPT, M365 Copilot and Gemini. The folder never changes.

• One edit, two updates. I change one line in GitHub and watch it land in Claude and ChatGPT.

• 100 skills at once. The whole set ships as a plugin to Claude and ChatGPT, and as a zip to Copilot and Gemini. The trade-off: a zip stays a snapshot until you upload the new version.

It’s a demo, so there’s nothing to install or build. We've set aside 15 minutes for your questions.

Try this before Friday. Pick the AI skill or set of instructions you use most. Count how many copies of it exist across your tools, then ask which one is current. Bring that answer; it’s where we’ll start.

Run Your Agent Skills on Any AI Platform Friday, October 2 · free · 45 minutes Save your seat →

Can’t make it live? Register anyway, and I'll send you the recording.

Reply and tell me which skill you’d most like to stop maintaining in three places. I read every reply.

Stay curious. Stay hands-on.

-James

Subscribe now

• The Hands-on AI plugin went from 7.0 to 8.1.1 between September 21 and 29. Same install, four new capabilities.

• Build your knowledge graph from one sentence and a short interview.

• The AI Registry comes first. Analyze adds its candidates there, and every later step reads it.

• Every framework step was rewritten. Each opens with an agenda and a time, and closes with the next step.

• Testing is a report card. Run the workflow, say test this, and every criterion is graded Met or Not met with evidence.

• Next step: update the plugin and take one workflow through a Test round.

If you took a Maven cohort course with me this year, you installed the Hands-on AI plugin in the first session and used it in every session after. It has changed a great deal since then, and the course materials on the shared Google Drive have been updated to match. This edition covers what shipped in the last two weeks and what each change lets you do.

What the plugin is

The plugin exists to help you take one piece of your work and turn it into an AI workflow that runs reliably. It follows the AI Workflow Framework, the seven-step method I teach in every cohort: Analyze where AI would help most, Deconstruct the work into its steps and rules, Design how AI will do it, Build it, Test it against real inputs, Run it for real, and Improve it over time.

Each step is a skill you invoke inside your AI tool. Say analyze my workflows or design this in Claude, ChatGPT, or Claude Code. The skill walks you through that step, asks the questions, and writes the result to a file you keep. The plugin also includes the skills for your knowledge graph and your AI registry, covered below. It’s free.

It didn’t exist at the start of this year. The first skills shipped in February, and since then they have given the people I teach a standard way to build. Because every cohort uses the same seven steps, a workflow built by one person can be read, tested, and improved by another.

Everything below applies whether you’ve taken a course or not. Full details and install steps: handsonai.info/use-the-playbook/build/handsonai.

1. Build your knowledge graph with one sentence

In August I wrote about giving your AI a memory of your business: a folder of Markdown pages about your clients, offerings, processes, and people that the AI maintains. In the courses, building one meant pasting a long prompt.

That prompt is now a skill. Open a folder in Claude Code, Cowork, or the ChatGPT desktop app and say build my knowledge graph. The skill reads what’s already in the folder and interviews you about the work. Then it proposes the four to seven kinds of things your business runs on, plus the sentences that connect them (”a Client buys an Offering”). Nothing is written until you approve the list and send the word build.

What the build writes:

• A knowledge/ folder in the Open Knowledge Format, with one page per real thing and a SCHEMA.md that holds your types and rules.

• An overview.md you would hand a new hire, plus an index and a log.

• Two local skills, ingest and lint, that keep the graph current as you drop in new documents.

• Provenance on every page. Who wrote it, when, and a footnote from each claim back to the document it came from.

It needs a tool that writes files on your computer. A browser chat window can’t build one, and the skill says so. Setup page: Knowledge Graph Setup.

2. The AI Registry comes first

The registry and the knowledge graph are now two distinct things, side by side in your folder. The knowledge graph records what your business knows. The registry records what you build with AI: your workflows, the processes they belong to, and the skills and agents that run them.

Three skills own it:

• scaffolding-registry stands up the registry/ folder with a schema and nodes for your business, lines of business, functions, and processes. Say set up my registry.

• analyze (Step 1 of the framework) now reads the registry and adds each candidate workflow to your backlog there, so every later step knows what’s next.

• indexing-registry checks the registry for errors and regenerates a REGISTRY.md dashboard and a visual HTML version. Say what have I built and get a real answer.

The registry is what I check when someone asks how many workflows I’ve automated. With Analyze filing into it, it also answers the question the framework starts with: where does AI create the most value, and what have you already done about it? Setup page: AI Registry Setup.

3. Every framework step rewritten for the person running it

Version 8 rewrote all seven skills. Each one opens with an agenda and a time estimate, signposts its phases as it goes, and closes by naming the next step. Plan on about a working day, across three or four sessions, to take one workflow from Analyze to Run.

The changes that alter how you build:

• Two mechanisms. A workflow runs as a Skill or an Agent. Design asks the question in plain terms and reuses the skills you already have before proposing new ones.

• Draft, then approve. Design writes the Design Spec as a draft you read and sign off. Build refuses a spec you haven’t approved.

• Build by intent. Build states what it wants built and lets your platform’s own model create the skill or agent its own way.

Every framework term is now defined in plain language in the Framework Glossary.

4. Test grades the real run

This is the change I’d point alumni to first. Testing was a score. It’s now a report card, and it grades the run where the run happened.

How a round works:

1. Deconstruct proposes the test inputs. You give one or two real inputs you’ve actually handled. The skill proposes the rest, each aimed at something that could go wrong: a hard case, an empty input, a must-never rule, an embedded instruction in content the workflow reads. You correct the list, and each input is saved as a file.

2. Every built workflow ends with a “What I did” list. The steps it took, where it paused for you, what it did with your tools, and where the deliverable is. That’s the evidence Test grades against.

3. Run it, then say test this. Open the round in one chat. Run each input in a fresh chat and say test this there. The skill grades every criterion Met or Not met, quoting the What I did list, and the verdict lands in the last chat.

A guard refuses to grade any run that saw your design before it started. Ready means every line met. Build won’t rebuild while a round is open, and Improve’s regression check uses the same run-then-test this pattern. Full walkthrough: Test and the worked example.

A workflow you haven’t graded against real inputs is a demo. The report card is what turns “it worked when I tried it” into something you can hand to a colleague.

How to update

If you already have the plugin, you need version 8.1.1. Checking for updates and installing them are two separate steps on Claude, so do both.

• Claude (claude.ai, Desktop, Cowork). Customize → Plugins. Open the … menu on the handsonai-plugins marketplace and choose Check for updates. Then open the handsonai plugin and click Update. No restart needed.

• Claude Code. One command:

/plugin update handsonai@handsonai

• ChatGPT. Plugins → find the handsonai-plugins marketplace → Check for updates (or Sync) → update Hands-on AI.

• Uploaded ZIPs instead of the plugin? Re-download the skills you use from the downloads table and upload them again. Each one replaces the skill of the same name.

Screenshots for every step are in the Update the Skills section of the setup page. Installing for the first time? Start at handsonai.info/use-the-playbook/build/handsonai.

Your next step

Update the plugin, then take one workflow you already run through a Test round. Pick the input most likely to break it. If you haven’t built your knowledge graph yet, that’s the other place to start, and it takes one session.

I hope the framework skills have changed the way you build. Reply and tell me how they’ve helped. I’d like to hear it.

Coming Up. If you have a friend or colleague who would be a good fit for one of my cohorts, two start Monday, October 5: Hands-on Agentic AI for Leaders and Agentic AI for Claude Builders. Forward this along, and they’ll use the same plugin from the first session.

Stay curious. Stay hands-on.

James

Today I’m adding a section for the first one. Hands-on AI Playbook is the Master AI pillar in practice. It is the part of Graymatter where every edition gives you something you can use this week.

TL;DR

• A new section inside Graymatter, not a new publication. You can subscribe to it on its own, or opt out and keep the rest.

• One play per edition. A platform capability, a workflow taken apart, something I use to run my own business, an installable skill or agent, or an alumni build.

• For leaders who own results. Practical and thoughtful. No code required, but you do have to be willing to try things in your own work.

• Weekly. One edition, one play, every week.

• Course alumni, this is your channel. If you took a program with me at Berkeley Haas or a cohort on Maven, this is where I share what’s working now.

• The weekly Playbook posts are free. Alongside them, I’ll post short lessons from my two Maven courses, often with video, for paid subscribers: small enough to learn and apply the same week. Paid also includes a Slack community for collaboration and live sessions as the group grows.

If you already subscribe to Graymatter, you’re in. Playbook editions will arrive alongside the posts you already get, and there’s nothing to do. If you’d rather not receive them, it’s one switch in your account settings.

Why a section, and why now

AI is moving faster than anyone can keep up with. You don’t need to track everything. You need what works.

Most AI newsletters answer “what happened this week.” This section answers a narrower question: what can I put to work this week? That question is what a decade of teaching leaders has taught me to ask first.

The name matches the rest of what I do: the Hands-on AI Playbook website and my two Maven courses, Hands-on Agentic AI for Leaders and Agentic AI for Claude Builders. Same method, three doors, and each one reinforces the others.

What a play is

The unit of this section is the play: one thing you can put to work this week. Every edition delivers exactly one. Here are the shapes it takes.

• Workflow Teardown. One real workflow taken through the AI Workflow Framework: the messy before, the design, the build, the working result. This is the anchor format. It’s how I teach in every cohort.

• How I Run It. Something I use to run my own business, whether an approach, a technique, or a capability: what it is, how it works, and what it changed. The knowledge graph behind my courses, the pipeline that triages my email, the registry that tracks every workflow I’ve automated.

• Skill Drop. A ready-to-install skill or agent with a short walkthrough. Useful the same day, and a preview of what the cohorts build.

• Alumni Build. A short spotlight on something a Maven or Berkeley alum built, in their words where possible.

• What Shipped. A new capability in Claude, ChatGPT, Gemini, or Copilot, and what it changes for your work. Not a news recap. If a release doesn’t change what you can do, it doesn’t get an edition.

• Coming Up. Occasional announcements of new cohorts, workshops, and Lightning Lessons.

Every edition ends with one next step. Try this, reply with your build, or go deeper on the website when a page exists.

Maven Course Updates. Once a month, alongside the plays, a rundown of what changed in the material for my two Maven cohort courses: new lessons, updated decks, revised guides. If you’re a Maven alum, you already have access to it all on the shared Drive, so this is how you know what’s new. If you haven’t taken a course, it shows how the material keeps up.

Who it’s for

Business leaders and innovators who want to apply AI practically and thoughtfully.

Practically means workflows that fit real work and produce results this week or this quarter. Not demos, not hype.

Thoughtfully means judgment. When AI should and shouldn’t be used. Keeping people in the loop. Building capability in your team rather than dependence on a tool.

You’re responsible for results, not just experiments. You don’t need to write code. You do need to be willing to try things in your own work. A play you read and never run is just an article.

Who I am

I’m James Gray. I spent thirty years in technology leadership, including a decade at Microsoft building the data and AI platforms the business ran on. I’ve since been a CIO and a CPO. I teach Data and AI Strategy at UC Berkeley Haas Executive Education, reaching thousands of senior leaders each year. And I run two hands-on cohorts on Maven, Hands-on Agentic AI for Leaders and Agentic AI for Claude Builders, where I’ve trained more than 1,000 professionals.

This section shows the work: what I’m running in my own business and what the people I teach are building.

How to subscribe to just this section

Substack lets you choose sections. Want only the Playbook? Subscribe at graymatter.jamesgray.ai/s/hands-on-ai-playbook. Want everything but the Playbook? That’s one switch in your account settings. Everyone stays on one list, one domain, one brand.

If you haven’t taken a course with me, this is the fastest way to see how I teach. Everyone is welcome.

For deeper guides and resources, the full playbook lives at handsonai.info. Details on paid Graymatter are on the About page.

Welcome to the Playbook. Whether you’ve been reading Graymatter for a while or just found it, I’m glad you’re here. The best of what I teach came from people trying things in their own work and telling me what happened, and that’s what I hope this becomes. I look forward to learning together.

Stay curious. Stay hands-on.

James

So you open Claude, and Claude knows nothing about any of it. You paste in three documents and explain the background again. You get a good answer. You close the tab, and every bit of judgment that went into that conversation evaporates.

Tomorrow you do it again.

I did this for two years. It isn’t about being organized enough. Claude has no memory of your business, so you supply it by hand, every time. The models got dramatically better every quarter. That part never changed.

The fix has two halves, and neither of them is a product.

The first half is a pattern, published by Andrej Karpathy, a founding member of OpenAI, formerly director of AI at Tesla, and now leading pretraining research at Anthropic, in what he calls an “idea file”. He named it the LLM wiki. A wiki is just a set of cross-linked pages, like Wikipedia, and this one answers the question every knowledge base eventually runs into: who keeps this current?

The second half is a standard. Google published the Open Knowledge Format, or OKF, and it answers the question that decides whether the thing you build is still useful in three years: what shape do you write it in? Every team solving this problem today invents its own private notes format. None of them travel. OKF is the agreed shape — published openly, free to use, and implementable by anyone without asking permission, because it is four rules about plain text files.

You need both. The pattern without the standard gives you a knowledge base trapped inside whichever tool you happened to start in. The standard without the pattern gives you a beautifully specified folder that’s still yours to keep current, which is the part you don’t have time for.

Together you get something genuinely rare in this market: a knowledge base that compounds instead of resetting, and that stays readable without any vendor’s software.

I run two knowledge bases on this standard. One holds the 333 pages behind my courses. The other holds 104 pages describing how my business actually operates. Both are plain text files in a folder. Neither one took a weekend to get started.

Here is the whole thing, both halves.

TL;DR:

• A knowledge graph is one file per thing, with ordinary links between them. There is no further structure to learn.

• Attaching files to a chat makes Claude rediscover your business every time. A knowledge graph makes it read what it already worked out.

• Karpathy’s insight: wikis stall because the bookkeeping is boring, and boredom is a human constraint. An LLM doesn’t get bored. That constraint is gone.

• It’s built in three layers: raw sources Claude never edits, the pages Claude writes, and a rulebook that disciplines the writing.

• You only ever do three things with it: ingest a document, query the graph, lint what’s gone stale.

• Build it on the OKF standard, and it’s portable by construction. Plain files keep it alive; the standard makes it travel. The conformance bar is one required field per file, so it costs you nothing.

This Thursday I’m demoing all of this live: two working knowledge bases, one real question, 45 minutes, free. Model Your Business as a Knowledge Graph for AI. If you’d rather watch it work before reading about it, start there and come back.

A graph is things plus relationships

The thing you’re building has a name: a knowledge graph. The definition is one sentence long, and the rest of this post follows from it.

A knowledge graph is things and the relationships between them. Everything gets its own page. Every relationship is a link from one page to another. The web of pages and links is the graph. That’s the entire definition.

Wikipedia works this way. You land on one page; the words inside it link to other pages, and you follow the ones that matter to your question. Claude reads your knowledge base exactly the same way. It lands on the page that matters and follows the links out of it.

You run your business this way too, whether or not you’ve ever called it a graph. Read this sentence, which could have come out of any account review:

Northwind Manufacturing is a mid-market account owned by Dana Ruiz, which came from the Q3 webinar, is running a pilot, evaluates Atlas Platform, and is blocked by security review.

Six things and five relationships. Northwind is a Company. Dana is a Person. The Q3 webinar is a Campaign. The pilot is a Deal. Atlas Platform is a Product. Security review is a Process. And the words joining them (owned by, came from, is running, evaluates, is blocked by) are the relationships.

Give each of those things its own page. Turn each of those phrases into a link. You have a knowledge graph. That shape was already in the sentence. Naming it is the only thing that changed.

Folders answer “where.” Links answer “how.”

This contrast matters, because most business knowledge is organized in a folder tree today, including mine.

In a folder hierarchy, every file lives in exactly one place, which forces a choice: does the Acme contract go under Clients/Acme/ or Contracts/2026/? Both answers are defensible, which is why the question keeps coming back.

A graph doesn’t make you choose. Acme is one page, and it links to its contract, its three engagements, the two tools you deployed there, and the playbook you used. None of those live inside Acme. You keep your folders exactly as they are. You add links on top.

Types and concepts

One distinction to settle first, because everything downstream depends on it.

Look at the Contacts app on your phone. “Contact” is the type, the kind of entry. The entry for your accountant is a concept, one actual record, filled in.

Your business has both. Client is a type; Acme is a concept. Playbook is a type; the onboarding playbook is a concept. Types are the kinds. Concepts are the real ones.

Two places the Contacts picture stops. Your pages are not forms. The type is a label saying what kind of page this is and nothing more; the body is how you’d describe the thing to a new hire, under whatever headings suit it. And unlike Contacts, your pages link to each other.

Four words, no synonyms

• Concept. One page, one file, one thing.

• Type. The kind of concept. A label, not a form.

• Link. A relationship between two concepts.

• Graph. All your concepts plus their links.

Markdown and frontmatter, in two minutes

Two file conventions, and then you can read any of these files you ever meet.

Markdown is plain text with light formatting. A # at the start of a line makes a heading. **bold** makes bold. [text](path) makes a link. That’s most of it. It opens in any text editor, on any computer, forever. A file ending in .md is a Markdown file.

Frontmatter is a few name: value lines fenced between --- markers at the very top. Think of a contact card. Frontmatter is the labeled slots at the top (name, phone, email). The body below is the free-text notes.

Only type is ever required. title, description, and tags are optional extras, and they earn their place for one reason: they let Claude list, search, and preview a page without opening it.

A three-page graph

Before a big one, look at a minimal one. Say you run a solo consulting practice. Three concepts, three files:

knowledge/
  clients/acme.md
  engagements/acme-ai-roadmap.md
  playbooks/kickoff-checklist.md

And inside engagements/acme-ai-roadmap.md:

---
type: Engagement
title: Acme AI Roadmap
description: Six-week roadmap engagement, Q1 2026.
tags: [active, roadmap]
---
# What we are doing
Six-week roadmap engagement for [Acme](/clients/acme.md),
run off the [kickoff checklist](/playbooks/kickoff-checklist.md).

# Where it stands
Discovery interviews done. Draft roadmap due 14 March.
Dana wants the security review resolved before we present.

Look at what that file is made of. Four labeled lines at the top are the frontmatter. Everything below is ordinary writing under headings you chose. # What we are doing and # Where it stands are not required by anything. They’re just how you’d explain this engagement to a new hire. Another page might use entirely different headings.

And two ordinary phrases are links, written the way any markdown link is written: square brackets around the words you read, parentheses around the page they point to.

[Acme](/clients/acme.md) shows the word Acme and points at the Acme page. [kickoff checklist](/playbooks/kickoff-checklist.md) shows kickoff checklist and points at the playbook. Two links, sitting inside a normal sentence. That’s what makes this a graph, not a document.

The / at the front of each link means “start from the top of this knowledge base.” Not the top of your hard drive, and not a web address. /clients/acme.md reads as the acme.md page in the clients folder of this knowledge base, and it means the same thing written from any page, however deeply buried. That’s what keeps a link working when the page it points to moves.

One thing to expect the first time you open these files. This link style is the form the standard recommends, and Claude resolves it correctly because your rulebook tells it where the top of the knowledge base is. Your text editor and GitHub don’t know that, so a preview pane may not turn these into clickable links. Nothing is broken. The reader that matters here is the model.

Three files, two links. Now ask the question that used to cost you an afternoon: where does the Acme engagement live? The folder answers where (under engagements/). The links answer how it’s connected (to the client it’s for, and the playbook it runs off).

Then ask one more: which of my playbooks has Acme seen?

No single page holds that answer. It lives in the links, and Claude assembles it by following them. Hold onto that question. It’s the whole point, and I’ll come back to it.

Three types are smaller than you’ll build. Yours will start at four to seven. The 333-page knowledge base that runs my courses is this exact shape, repeated.

One thing worth knowing now rather than later: that three-file example is already a conformant open-standard bundle. Not “roughly like” one. More on that shortly. You had to adopt nothing to get there, which is the strongest argument for the standard.

Why knowledge bases die

The reason to care about any of this is not the shape. It’s who keeps it current.

Karpathy’s argument starts with a familiar failure. Wikis and shared knowledge bases die. They die not because the idea was wrong, but because, in his words, “the tedious part of maintaining a knowledge base is not the reading or the thinking, it’s the bookkeeping.”

Somebody has to file the new document, update the four pages it contradicts, and fix the cross-references. Humans get bored and stop. The wiki rots, everyone goes back to searching their email, and eighteen months later someone proposes building a wiki.

An LLM does not get bored. It will update fifteen cross-linked pages in one pass, at 11pm, for the hundredth time, with the same care as the first. The maintenance burden that killed every wiki is the exact constraint that just got removed.

That’s the whole shift, and it’s worth sitting with. A decade of dead wikis taught people that a shared knowledge base is not worth starting. That was a fair reading of the evidence at the time. The evidence changed. (His note is a fifteen-minute read and worth it in full.)

Concretely: the folder still says the Acme engagement ends in March. The graph got updated in October, when you told Claude it had been extended. A folder of documents is storage. A graph someone keeps current is knowledge.

Why this isn’t the same as attaching files to a chat

Attaching files to a chat, or pointing an AI tool at a folder to search, is the common approach. It works. I’m not going to pretend otherwise.

But nothing accumulates. Each question sends Claude back to the original documents to find the relevant passages and work out an answer from them. When the conversation ends, that thinking is gone. Ask a related question next month, and the same work happens again, from the same raw documents, at the same cost, with no memory that you ever asked.

The LLM wiki inverts it. Each source is read once, filed into the pages it affects, and cross-linked, with contradictions flagged as they surface. Built once and kept current, rather than rediscovered every time.

That’s what “compounds” means in practice. It’s why a graph gets better the longer you use it, while a folder of documents just gets bigger.

It is worth being precise here, because a technical colleague will ask. Both approaches retrieve. Claude reads my index and opens the pages a question needs, and that is retrieval by any definition. The difference isn’t retrieval; it’s whether the thinking gets kept. Search-every-time systems have a name: RAG, retrieval-augmented generation. They re-derive the answer from the source documents each time, and discard the derivation when the chat ends. The wiki writes the derivation down on the page it belongs to, so the next question starts from it instead of redoing it.

Founder Lens

Build, not buy. There’s a wave of AI knowledge products arriving, and the good ones are genuinely good: real retrieval, real permissions, connectors into everything you already run. That isn’t the question. The question is where your operating knowledge ends up living. How you price, what you’ve learned works, why you do it this way rather than that way — that’s your intellectual property, and it scatters across chat histories, uploaded files, and whatever each platform decided to keep. Scattered isn’t an asset. And once it’s inside a product, the vendor sets your exit costs. Plain markdown in a folder you own works in any AI tool or platform you point at it today, works in whatever you’re using in 2028, and moves to another machine by copying a directory. The advantage here is the format, and the format is free.

Architecture: three layers

Keeping these separate is what makes the pattern work rather than degenerate into a folder of AI-generated sludge. If you’ve ever had a bookkeeper, you already know the shape.

1. Raw sources, read-only. Your actual documents: contracts, transcripts, reports, notes. These are the receipts and bank statements. You never alter a receipt, and that is exactly what makes it worth having. Claude reads them and never edits them. They are evidence.

2. The wiki, Claude’s layer. The concept pages, written and rewritten by Claude from the raw sources. These are the books your bookkeeper keeps. This is distilled knowledge, not evidence, which is precisely why it’s safe to let Claude rewrite it. The receipts are still there to check it against.

3. The schema, the rulebook. A file that says how the wiki is organized and what the conventions are. This is the chart of accounts: the agreed list of what goes where, written down before the entries are made.

Karpathy’s point about that third layer matters most. The schema is what makes the model a disciplined wiki maintainer rather than a generic chatbot. Without it, every session invents its own filing system, and six weeks later you have four naming conventions and no way to query anything.

The three layers. Raw sources stay untouched. Claude reads them, distills what matters, and writes the pages. The rulebook governs both sides.

A note on filenames, so you’re not confused later. Karpathy puts these rules in the file the AI tool already reads at startup: CLAUDE.md for Claude Code, AGENTS.md for other tools. I use two files instead. A SCHEMA.md holds the actual rules, and a short CLAUDE.md tells every future session to go read it. Same layer, split in two, for a practical reason: the rules are something you’ll read and revise yourself, and they’re easier to find in a file named after what it contains.

Operations: three of them, and that’s all

These three are all you ever do. Not just while you set the knowledge base up: a year in, running it still means only these three.

Ingest. Hand Claude a new document. It folds what matters into the pages that already exist rather than dropping another file on a pile. You hand your bookkeeper a receipt; they don’t file it in a drawer, they post it, and the balances change.

Query. Ask the graph a question. Claude answers from the pages and cites which ones it used, so you can check it. That includes questions whose answer sits on no single page and has to be assembled across links. And when an answer took real work to assemble, it gets filed back as a page of its own — which is how a question you asked once stops being a question.

Lint. Claude proofreads the entire graph against your rulebook, hunting four things specifically: pages that contradict each other, claims that have quietly gone stale, orphans nothing links to, and links that should exist and don’t. It reports; you decide what gets fixed. A few minutes a week, and it is what keeps the other two trustworthy as the graph grows.

Ingest, query, lint. Running these three is the only maintenance your knowledge base needs.

That’s the first half. Things and links, three layers, three operations.

The second half: an open standard, not a product

Everything above tells you how a knowledge base stays alive. It doesn’t tell you what shape to write it in, and that turns out to matter just as much.

Here’s the problem Google set out to fix. What AI agents most lack is internal knowledge. What a metric means in your company. Why something is done a particular way. Which client the rules apply to. Every team that solves this builds its own private notes files. Those files all look broadly similar, and none of them were designed to work together, so nothing travels. Every new tool starts the collection work over, and every vendor that offers to help would prefer the knowledge live in their database.

The Open Knowledge Format is the response, and what matters is what it is not. It’s not a product, a platform, a repository, or a service. It’s an agreed shape for these knowledge bases. Plain files anyone can write, and any agent can read, with nothing proprietary in between. Closer to what CSV is for tabular data than to anything you would buy: no vendor, no runtime, and every tool already reads it.

The specification is deliberately small, and most of it is already above:

• A bundle is a folder of markdown files.

• One concept per file.

• A type in the frontmatter.

• Ordinary markdown links connecting the pages.

That’s it. That’s the shape you read in the three-file example, which means the cost of building to the standard rather than to your own private convention is approximately zero.

What you get for that zero: your knowledge works in any AI tool you point at it today, in whatever you’re using in 2028, and on a colleague’s machine when you hand them the folder. You are not building inside a product that can change its mind about your pricing tier, get acquired, or sunset the export button.

Be precise about what’s doing the work there, because it changes how much weight to put on the standard. The durability comes from plain markdown in a folder you own — that would still be true if OKF disappeared tomorrow. What the standard adds is interoperability: your bundle and someone else’s have the same shape, so a tool written against one reads the other, and an agent that has never seen your business knows how to walk your files.

One caveat you'll hit within ten minutes of opening the spec: OKF is early. It is at version 0.2, published by Google in a public repository, with no formal governance body behind it yet. That is also why my instructions to Claude point to the published spec and ask it to read the current version rather than pinning one—I want today’s rules, not the ones that were current when I set up. Point at the source, and carry a short fallback summary for when it can’t reach the page. If the standard moves, my files don’t. Only the rules Claude checks them against do.

That’s why I run both of my bundles on it, and why I check the spec before I change either one’s structure. The pattern keeps it current. The plain files are why it stays mine. The standard is why it travels.

Spec, if you want to read it: Open Knowledge Format.

You choose the types

There’s one thing worth pulling out of the specification, because it’s the part that decides whether this works for your business.

OKF hands you no vocabulary. It asks for that one type field and does not tell you what the types may be. You choose those, and any tool reading your bundle must cope with types it has never seen before. Nobody decides whether Playbook or Engagement is a legitimate kind of thing in your business except you.

That’s worth more than it sounds. A fixed taxonomy that can’t hold a new kind of thing is where structured knowledge systems tend to break down, a few months in, once real work starts arriving. OKF avoids that by declining to define the taxonomy at all.

Here’s what that looks like in practice. My two bundles run on the same standard. The one behind my courses uses these types:

Course · Week · Session · Module · Lesson · Project

The one that runs my operations uses these:

LineOfBusiness · Function · Process · Workflow · Note

Same standard, same file shapes, same three operations. Entirely different types, because a teaching business and the operation behind it are made of different things. Neither list was approved by anyone. Yours will be a third list, and it should be.

Those six carry the teaching content. That bundle runs thirteen types today: cohorts, post-course reviews, and improvement items all eventually needed pages of their own. Every one arrived because real work showed up with nowhere to live, which is the only good reason to add a type.

The rulebook, in plain language

“Schema” sounds far more technical than it is. Here’s the core of mine, trimmed to the types that carry the teaching content:

Types and directories
  courses/     Course
  weeks/       Week
  sessions/    Session
  lessons/     Lesson
  projects/    Project

Plural folders, singular type names.
Every page carries a title, a description, and a date. No exceptions.
One style of link, so nothing breaks.

Four house rules: which kinds of pages exist, which folder each kind lives in, what every page must carry, and how pages point at each other.

Write that once, and every page Claude creates afterward follows it. Across 333 pages I have reorganized plenty — lessons move between weeks, whole modules get resequenced, a migration once decomposed a syllabus into eighty pages. I have never had to rewrite the rules themselves, because they were settled before the pages existed. That separation between what moves and what doesn’t is most of what a rulebook is for.

A vague rulebook is what produces a messy knowledge base. This is the file to slow down on, and the one that pays back most. Specifically:

• Name the types before you write pages. Start at four to seven. If your first list is already at twelve, two or three of them are probably fields on a page rather than pages of their own. Types earn their way in later, once something real has nowhere to live.

• Say what every page must carry. A title and a one-line description is the minimum that makes an index possible.

• Pick one link style and write it down. Mixing relative and absolute links is how graphs quietly break when files move.

• Say what does not belong. Mine says raw source documents are never edited, and generated files are never hand-written. Constraints prevent more mess than instructions do.

What a query actually looks like

This is the moment worth seeing properly, because it’s the entire reason to do any of this.

Earlier I asked you to hold on to a question: which of my playbooks has Acme seen? Here is that exchange, in the shape you will get:

You: Which of my playbooks has Acme seen? Answer only from my knowledge base, with citations.

Claude: Two. The kickoff checklist, used to run the Acme AI Roadmap engagement, and the discovery interview guide, used on the earlier scoping engagement. The onboarding playbook has not been used with Acme.

Sources: engagements/acme-ai-roadmap.md, engagements/acme-scoping.md, clients/acme.md

Read what had to happen for that answer to exist.

Nowhere in the graph is there a page listing Acme’s playbooks. Claude started at the Acme page, followed the links to both engagements, looked at which playbook each one pointed to, and assembled an answer that had never been written down anywhere.

Then it told you which three pages it used, so you can open them and check.

Three payoffs come out of this, and you’ve just watched the third. Your information gets organized in one place. The relationships become visible instead of remembered. And Claude can derive knowledge that was never written down anywhere: answers assembled across several pages, contradictions between two pages that each look fine alone, patterns across clients that no single page records.

A folder of files cannot answer that question. A graph does, in seconds.

The same question, against a real knowledge base

Acme is invented, so here is the same shape against my operations bundle. The 104-page one. Real pages, real answer.

One of my rules matters for this. In that bundle, a workflow never records its own owner. Ownership lives on the process the workflow belongs to, and functions own processes. I set it up that way on purpose, because writing an owner in two places is how two places end up disagreeing.

Which means this question has no page to read the answer off:

You: Who owns the Course Concept Development workflow? Answer only from my registry, with citations.

Claude: I’ll look up the workflow node in your registry.

Used 6 tools

Owner: the Product function, led by James Gray.

The chain, per your registry’s ownership rule (workflows inherit the owner from their process; processes name a function slug, never a person):

• Course Concept Development — the workflow node carries no owner: field, as designed (registry/workflows/course-concept-development.md)

• It’s workflow #1 under the Course Development process (LOB: Learning), whose frontmatter reads owner: product (registry/processes/course-development.md)

• The Product function’s lead: is “James Gray” (registry/functions/product.md) — so it’s staffed, not orphaned

Sources:

• registry/workflows/course-concept-development.md

• registry/processes/course-development.md

• registry/functions/product.md

Three pages, and the answer wasn't on the page you'd open first. Claude says so itself in the first bullet: the workflow node carries no owner field. It went and found the process that lists this workflow, took the owner from there, and resolved that owner to a function. Six tool calls to land on three pages, and it showed its work.

Then it added something I hadn’t asked for. So it’s staffed, not orphaned.

No page in my registry says whether a function is staffed. No such field exists, and I have never marked one. What exists is a single line in my rulebook: a function with no named lead is unstaffed. Written once, never repeated, and never applied to anything — until Claude applied it here, to a function I’d asked about for an entirely different reason.

That is what a rulebook buys you that a folder cannot. One sentence about what an absence means, and every page in the graph quietly acquires a property nobody typed. Ask that same question across every process in the business, and you have a staffing gap report I never wrote, and no page contains.

That’s the difference between storage and knowledge. A folder tells you where a file is. The links tell you who owns the work, and the rulebook tells you which work nobody owns.

The citations are not decoration. They make the answer checkable, and checking one occasionally is the habit that keeps you honest about how much to trust it.

What it costs, what it returns, and where it doesn’t fit

Here is enough detail to decide whether this is worth your time.

Setup. Twenty minutes of thinking, which is the exercise below. Then an hour or so to build the thing, which is the next post. No license, no vendor, no procurement conversation.

Running it. Ingesting a document takes about as long as handing it to someone. Lint is a few minutes a week. Querying is faster than asking the colleague who would know.

Return. The compounding part is hard to put a number on, so here’s the part that isn’t: the question that used to mean an afternoon of digging through old proposals and threads gets answered in seconds, with citations you can open and check. That happens in the first week. After that it keeps improving, because every document you add makes the next answer better.

When it pays off — and when it doesn’t. Not day one. On day one, this is worse than pasting documents into a chat, because the graph is nearly empty and you’re the one filling it. Judge it at week three, not at the end of the first session. If you won’t give it three weeks of real use, don’t start. In week one you are still building the thing, and judging the build tells you nothing about the tool.

Your knowledge stays yours. These are plain files in a folder on your own machine. Nothing gets uploaded into a knowledge platform, no vendor ends up holding your operating knowledge, and Claude reads the files when you ask it to under whatever data terms you already work with. If you can keep a folder of documents, you can keep this.

Where it doesn’t fit. This is not a system of record. It doesn’t replace your CRM, your finance system, or anything carrying an audit requirement. Those hold transactions; the graph holds understanding, and links out to them. It’s also weakest where the knowledge changes hourly. A graph earns its keep on things that stay true for months.

Solo or team. Start solo, because you can, and because the thinking is yours either way. It scales to a team by putting the bundle in a shared repository, with one honest constraint: somebody has to own the rulebook. That’s true of every shared filing convention ever attempted, and this one is no exception.

Lint: the operation that decides whether this survives

“Lint” is a borrowed word. Developers run a “linter,” a tool that automatically checks their work for problems they’d never catch by rereading it.

In a knowledge base, lint means Claude proofreading the whole graph against SCHEMA.md. It finds four things:

1. Contradictions. Two pages that disagree. One says the engagement ends in March, another says it was extended to October.

2. Stale claims. Assertions that have quietly gone out of date.

3. Orphans. Pages nothing links to and that link to nothing. They exist, and no question will ever reach them.

4. Missing cross-references. Links that should exist and don’t. This one is subtle and it’s where most of the value hides, because a missing link is knowledge you have and cannot get to.

A worked lint inspection: a contradiction between two pages, an orphan nothing links to, and a missing field. Report first. Nothing is rewritten until you approve it.

Two things make lint work.

It reports, it doesn’t rewrite. Problems get flagged, and you decide what gets fixed. Anything else and you’ve built a machine that confidently overwrites your business knowledge while you’re asleep.

It’s only as good as your rulebook. An inspection against a checklist you wrote yourself is exactly as sharp as the checklist. This is the second reason SCHEMA.md is worth reading closely rather than rubber-stamping.

Run lint weekly. It takes a few minutes, and it is the difference between a knowledge base and the ruins of one.

Indexing and logging: two files keep it navigable

As the graph grows, you need a way in and a way back. Two plain files do that job. Both are optional in the standard. Leave them out, and you will end up rebuilding them by hand a few months later.

The index is a contents page. Every page you have, listed in one place, with a one-line summary. In my bundle, that’s an index.md in each folder. Part of my courses index reads:

Courses
  Hands-on Agentic AI for Leaders
    - 4-week Maven course to build, ship and manage AI workflows.
  Agentic AI for Claude Builders
    - 5-week Maven course turning Claude users into Claude builders.

Every page earns exactly one line, and Claude writes it. This answers what do I know?

The index also drives performance. It’s what Claude reads first, so it opens only the pages a question actually needs instead of trawling 333 files. At ten pages this is a nicety. At three hundred, it’s why queries stay fast and cheap.

The log is a running diary. A dated heading, and under it a bullet for each change. In my bundle that’s a log.md at the root:

## 2026-08-03

* **Add**: New lesson: the LLM wiki and the Open Knowledge Format.

## 2026-07-15

* **Migration**: Decomposed course syllabus into 80 pages.

Newest entries at the top. Nothing is ever overwritten. It answers the question the index cannot: how did I get here? Months later you can ask why something changed and get a real answer instead of a guess.

Claude writes and maintains both. You don’t. They describe the graph rather than adding to it, so when you count your concepts, the index and the log don’t count.

What this asks of you

One honest note, because I’d rather say this than let you find it out in month two.

The hard part isn't technical. None of it requires code. The hard part is that a knowledge base makes your thinking legible, first to Claude and then to yourself. Writing down what a “client” is can reveal that the word means something different in sales than in delivery. Defining a process can surface a step whose owner was never actually named.

That’s not a side effect. It’s most of the value. The graph is a mirror before it’s a tool, and that is where most of the return on it comes from.

AI amplifies your judgment. It doesn’t replace the work of developing judgment worth amplifying. A knowledge base makes that work visible.

The vocabulary

Eleven words. Keep them somewhere you can glance at.

• Concept. One page, one markdown file, one thing.

• Type. The kind of concept. The label, like Client.

• Link. A relationship between two concepts.

• Graph. All your concepts plus their links.

• Schema. The set of types you chose, plus the rules for using them.

• SCHEMA.md. The file those rules live in, and the one Claude maintains the graph by.

• Bundle. The folder that holds it all. OKF’s word for it.

• OKF. Open Knowledge Format. The published shape a bundle takes.

• Ingest. Folding a new document into the pages it affects.

• Query. Asking the graph a question and getting a cited answer.

• Lint. Claude proofreading the graph against the rulebook.

Do this part now, before you build anything

Everything above is the thinking. Here are the twenty minutes that turn it into something you can build from.

No files yet, no tools open, just answers.

Answer five questions. Twenty minutes.

• What kinds of things does your business run on? Name four to seven. These are your types.

• For each one, name three real examples. Those are your first concepts.

• Which relationships between them do you actually reason about? (”This engagement is for that client.”)

• What must every page carry? Title, description, and date are a fine answer.

• Which documents are your raw sources, and where do they live?

If you can’t name three real examples of a type, it isn’t a type yet. Cut it.

That’s it. No files to create. The next post opens with a prompt that interviews you and writes your SCHEMA.md from what you approve, so the file isn’t your job. The answers are, because that’s the part no prompt can do for you. It isn’t really a filing decision. It’s you saying out loud what your business is made of, and it tends to surface at least one definition worth settling.

Keep what you write. You’ll build on it in the next post.

What happens next

You have the pattern, the standard, and your five answers. The next post builds from them.

Understanding how this works and having it running are different things. This post is the understanding. The next one is the implementation: turning an empty folder into a running knowledge base in about an hour. Do the twenty minutes above, and you arrive with the hard part already behind you.

Further reading

• The LLM Wiki (Andrej Karpathy). The original design note behind the three layers and the three operations.

• Open Knowledge Format specification. Read it before you change your bundle’s structure, not after. The surrounding repository has tooling and examples.

This Thursday I’m running a free 45-minute session where I demo all of this against the two knowledge bases above: Model Your Business as a Knowledge Graph for AI. Same material, watched rather than read, with 15 minutes of open Q&A at the end. The recording goes to everyone who registers.

If you’d rather build it live with me and a room of other builders, I teach it in Agentic AI for Claude Builders, starting Monday, August 31.

Stay curious. Stay hands-on,

James

In the AI cohorts I teach, people sometimes preface their question the same way: “I’m in my 40s, my 50s…” Yesterday, an email put it plainly: “I’m new to AI and older in the workplace, trying to find new footing.”

Behind those questions sits a quiet belief: that AI is a young person’s game, and that the best years are already gone. Before I answer, I respectfully tell them where I stand, with a touch of fun: “I’m 61, and I’m just getting going.”

I haven’t always thought that way.

At the end of 2022, I felt exactly what that email described. My role as a CIO had ended, and tech firms were laying off thousands of people. I felt lost, unsure how to apply three decades of experience. One question kept surfacing: what would I regret not doing at this stage of my life?

So I went looking. I read widely, studied my own patterns, and enrolled in a year-long leadership coaching certification because I was curious how people actually evolve and grow. That program taught me about identity, self-limiting beliefs, and growth that starts from the inside out.

It also made me listen. I had started teaching for UC Berkeley Executive Education’s data and AI programs in January 2022, while I was still in my corporate role. Leaders in those programs kept telling me I had a gift for explaining AI in a practical, clear way. The signal was there. I simply wasn’t processing it. When I noticed how alive I felt teaching, fully in the zone, I realized I hadn’t yet claimed that as my identity.

The renewal was bumpy and emotional. It was stressful, and there were months I did not know how I would pay the mortgage. But I needed to answer life’s most important question: who am I, and who do I want to become? I answered with as much clarity and courage as I could find. I learned how to identify emotions and lean into them instead of pushing them off.

Money tested that resolve. I let curiosity lead, not the rush to replace my income, trusting it would follow if I stayed focused on the right work. Had I chased the paycheck, I would have gone straight back to what I was doing before, and I knew that was not my destiny.

In mid-2024, I followed that thread and built a cohort course, the Inner Quest, to help people accelerate their own self-discovery. I wanted to share all I had learned about inner transformation and pursuing new career paths. My first AI cohort followed in January 2025, and another in January 2026. Step by step, I found myself: weighing my experience and talents, listening to real market feedback, and building the confidence to follow what made me distinct. For what felt like the first time in my life, I was pursuing life from the inside out with the courage to act on it.

That is when I settled on a new belief. I am peaking. My best years are ahead. I have been training for this the whole time, and applying my talents to create value for others is the work I am responsible for now.

And the work has given me a gift I never saw coming. More than 500 people have now joined my cohorts, and I get to learn alongside them from all over the world. Being trusted with a piece of someone else’s journey is something I treasure. They range from CEOs to an Olympian to founders to quietly brilliant professionals, each with a talent all their own. Meeting new people every month is exhilarating, and I would have missed all of it had I not embraced my curiosity about who I want to become in this next decade.

What the research says about age

Recently I read “What to Make of a Life” by Jim Collins. It gave language to what I had lived over the previous few years. Collins describes three elements of building “one big thing”:

1. Discover and deploy your set of encodings.

2. Flip the arrow of money.

3. Focus the inner fire and do great work late in life.

Collins defines encodings this way:

“Encodings are durable capacities of a person’s intrinsic construction that lie within, awaiting discovery through experiences of life.”

Read that phrase again: “lie within, awaiting discovery.” Reinventing a career at any age is an inside job. As Collins puts it, “You don’t create encodings; you discover them. You don’t add encodings from without; you find them within.”

Our encodings already live in us. The work is the awareness to find them and the courage to apply them. That is the inner journey I began in earnest in 2023, and it led me to the work I do today. There was no silver bullet, and plenty of lost moments, but I trusted the process.

Now back to the belief that age is the barrier. One line from Collins stays with me: “Life’s not done until it’s done, and you never know what’s coming next.”

That idea is exactly what fueled my curiosity to keep exploring, even when the path felt deeply uncertain. In his research, many of the people Collins studied did their best and most important work later in life. Three capabilities explain why, and together they grow with time:

1. Encodings. They don’t dim with age. People keep discovering hidden ones “as the frame of life shifts, which serves only to increase one’s capabilities.” I found one of mine later in life, when I grew into my identity as a data and AI instructor.

2. Cumulative experience. You get better at what you’re encoded for over long stretches of time.

3. Credible equity. Credibility acts as an exponential multiplier and compounds on itself.

Collins concludes:

“Our most creative and productive years can happen long after the midpoint of our lives.”

What I’d leave you with

The inner journey comes down to self-trust: trust to discover your encodings, embrace them, and put them to work. Listen more closely to what is inside you, while reading the outside signals that confirm where you create value. Looking back on the past few years, here are a few things I want to leave you with:

1. Every day you will find evidence that confirms your self-limiting belief. The feeling is real. The better question is whether it is actually true.

2. Finding your unique mix of encodings takes study, awareness, and curiosity. Become the best student of yourself.

3. Wherever you are, it is never too late to reimagine what comes next by combining your experience with your encodings. As Collins reminds us, “You cannot straighten out the road behind you.” Those miles are already driven. Look ahead instead, to whatever waits around the next bend. Stay curious, and you will find out.

Sit with these three questions over the week ahead:

• Who am I today, and who do I want to become?

• How can I combine my past experiences and encodings into a path that is uniquely mine and valuable to others?

• What self-limiting belief is holding me back from that path, and am I willing to let it go?

Honest reflection and conversations with people you trust are how you reach the next stage of your career. Your encodings are already within you. The work now is to rediscover them and put them to use.

Why this matters for you

AI is an enabler for people of any age. It amplifies who you already are. It rewards judgment, clarity, and pattern recognition, which is exactly what decades of experience build. Your age and your experience are not liabilities here. They are the multiplier.

So if you are finding new footing, hear this: you are not behind, and you are not too late. Your experience is not a weight to set down. It is the material for whatever you build next, and your most meaningful work may still be ahead of you. Be gentle with yourself as you explore and stay curious.

The answers are already within you. It is time to discover them.

I would love to hear from you. Which encoding within you are you ready to put to work in your next chapter? Hit reply and tell me. I read every response, and I am cheering you on.

-James

We spend our lives studying everything except the one subject that matters most.

We master tools, markets, and frameworks. We refresh the feed. We chase the next topic, the next thread, the next opinion someone else decided was urgent. Most of it is noise dressed up as learning, a comfortable distraction from the only study that sets the direction of a life.

The most important subject you will ever study is yourself.

This is a discipline, not a slogan. The strength of your self-awareness guides you toward purpose and enables you to bring your unique capabilities to bear on the world. And almost no one is doing the work. We’ll read books about other people, or scroll through Instagram, before we sit quietly with ourselves and ask the questions that change anything.

I’ve been circling this since 2008

Back then I hosted career-strategy workshops at Microsoft. What struck me was how few people had an internal compass that was calibrating and guiding their direction. It was a realization that kept surfacing: we needed to discover our own values, our own expertise, and how we wanted to grow as individuals, regardless of the role we happened to hold at that moment.

The opportunity in front of you is temporary. The questions underneath it are not. Who are you? Who do you want to become? Where does your particular expertise belong?

That fascination wasn’t academic for me. It carried me through one of the hardest chapters of my life, the season when a job ended and I felt lost. What steadied me had nothing to do with a title. It came from turning inward, from trusting I could discover who I was apart from any single role. Self-awareness was the compass when the map disappeared.

Collins calls them “encodings”

This past week I read Jim Collins’s What to Make of a Life. It put words to something I’ve been circling for years.

Collins calls our unique qualities encodings. He defines them as “durable capacities of a person’s intrinsic construction that lie within, awaiting discovery through the experiences of life.” Sit with that last phrase: awaiting discovery. You don’t invent or construct your encodings. You uncover what is already in you.

“You don’t create encodings, you discover them. You don’t add encodings from without, you find them within.”

This is the part most of us get backward. We treat our future selves as something to be built: more skills, more credentials, more bolted on from the outside. Collins says the most important things are already there, fixed, waiting. The work is less about adding to yourself and more about digging out what is already in you.

And discovery is only half of it. He poses the question I haven’t been able to put down:

“Which encodings will the journey of life lead you to discover, and will you entrust them enough to align your life around them?”

Discovering your encodings is one thing. Trusting them enough to organize a life around them is another entirely. There will be seasons of self-doubt, moments when the safe path beckons, when following the crowd feels like the responsible choice. But your true calling announces itself differently. It’s the energy you feel when you apply your encoding in a way that is natural and entirely yours.

A constellation, and a frame

Collins offers an image I keep returning to.

“Picture a constellation of stars. Now imagine looking through a frame that limits how much of the constellation you can see, such as looking through the lens of a telescope or camera. Stars outside the frame remain hidden, while those inside the frame shine brightly through the lens.”

The encodings are fixed. Like the stars, they don’t move. What changes as you move through life is the frame: where it points, how wide it opens, and whether a bright cluster of your encodings happens to sit inside it.

So much of self-discovery is patiently adjusting that frame until what was always there comes into view.

How to see your stars: the bug book

So how do you bring the constellation into the frame?

Collins did it with what he called a bug book. To learn about himself, he carried a notebook everywhere and took notes throughout the day, trying, in his words, to be a scientist of the self. He tracked the moments that lit him up and the ones that drained him. And in that book he discovered his own encoding: a gift for packaging and teaching ideas in a way that sticks.

I love this because it’s a practice, not a personality test. You don’t find your encodings by thinking harder. You find them by observing yourself honestly, over time, the way a scientist observes anything: patiently, without flattering the result. We excel when we learn to recognize the experiences that give us energy and strength, then point our lives toward more of them.

For me, this is a daily journal. I write at the start of the day and again at the end, capturing what I notice in myself: where my energy went that day, and what I want to look at more closely tomorrow. Some days it’s only a few lines, and that’s fine. What matters is the habit of noticing.

These days I’ve added a modern layer to it. I still keep the journal, but I also bring those notes to AI as a thought partner. I’ll hand a week of raw notes to a model and ask what it notices: the themes I keep circling back to, the work that gave me energy, the patterns I’m too close to see in myself. It won’t tell you who you are, but it will help you question your own notes faster and surface insights you might have walked right past. If you already like thinking out loud with AI, this can be your bug book. The notebook becomes a conversation, and a good thought partner helps you reach insight sooner.

If you take one action from this piece, take that one: start your version of a bug book this week. A paper notebook, a voice memo on a walk, or an AI thought partner, whichever one you’ll keep. Watch for the moments that pull energy up.

It’s not about being better than others

Most of us, when we think about our strengths, immediately ask the wrong question: what am I better at than other people? Collins reframes it:

“It’s not about finding what you can do better than others, but about finding what you can do exceptionally well relative to other ways you could expend yourself.”

The comparison that matters isn’t you versus everyone else. It’s you versus the other ways you could spend your one life.

You have agency of choice, and there’s a real opportunity cost every time you pour your expertise into work that doesn’t align with your encodings. You’re not just failing to win some competition. You’re spending the most precious thing you have on the wrong thing.

He says it plainly, and more than once: encodings lie within, waiting to be discovered rather than taught from without.

The personal hedgehog

Finding and aligning with your encodings is only one part of Collins’s framework. The larger idea is what he calls a personal hedgehog, an arena of activity that meets three tests:

1. You’re encoded for it. It draws on your durable, intrinsic capacities.

2. You flip the arrow of money. Doing it generates resources rather than drains them.

3. It focuses the inner fire. It lights you up from within.

To be in hedgehog mode is to commit. You organize your life and channel a huge share of your energy toward the pursuit of one big thing. Not ten things. One. The intersection where your encodings, your livelihood, and your fire all line up.

Most people never find that intersection, even though it’s right there. Finding it takes honest self-study and the courage to act on what you learn. Both are hard, which is why most people stop short.

What I want to leave you with

This is about self-discovery and self-awareness, and no one else can do it for you. No one else can tell you which path in life is best for you. The best subject for you to study, for the rest of your life, is yourself. Become fascinated by the uniqueness of who you are and what you are capable of becoming.

I’ll be honest about how rare this is. Over many years and many conversations, I’ve watched person after person struggle to answer a simple question: what is the work that brings out the best of you? Just recently, a former colleague who had taken real time for discovery, weeks and even months, still couldn’t name how he wanted to apply his unique expertise in the years ahead. That’s not a failing of intelligence. Studying yourself is a skill, and, like any skill, it can be strengthened through practice. Any of us can begin building it today.

Each of us is unique in our own particular way. It’s our responsibility, to ourselves, to find that uniqueness and have the courage to pursue our craft with excellence. No one else is in a position to judge where you apply your encodings. That discovery comes from within. So does the courage.

Master Yourself

This matters more than ever because of the world we’re living in. Everything around us keeps shifting, and the pace only accelerates with AI. The people who keep thriving are the ones who can adapt without losing themselves along the way, and that starts with self-awareness. When you know your encodings, you have a stable core to move from. You can keep changing how and where you apply yourself, staying relevant and continuing to grow through every phase of your life.

This is the master yourself theme of Graymatter. Alongside mastering AI and building what matters, it’s the one I believe matters most.

This isn’t about tools or tactics. It’s the longer journey of discovering ourselves, evolving, and living aligned with what we find. One idea, each time, worth sitting with.

Your reflection

There’s no need to answer out loud, and no need to reach a conclusion by the end of this coming week. The practice is being willing to sit with the questions that land hardest, because those are usually the ones pointing at something true.

And here’s the good news: these encodings already lie within you. Each of us has unique expertise, and it’s our responsibility to discover these encodings and bring them to life. So I’ll leave you with three questions to sit with:

1. When was the last time you looked up to explore your constellation of encodings?

2. When was the last time you adjusted the lens angle and saw the ones that shine more brightly?

3. When was the last time you trusted yourself to pursue your own encoding instead of following the crowd toward what was easy or expected of you?

And one last question, this one pointed forward: what is the single next step you can take to discover your encodings and put them to work in a way only you can?

If something surfaced while you read this, hit reply and tell me. It comes straight to my inbox, and I read every one.

-James

One section in Chapter 2 really resonated with me. Stulberg calls it selecting worthwhile pursuits — and it gave me a diagnostic I am starting to use on every new project, every inbound opportunity, every commitment I’m weighing.

TL;DR:

• Decades of research on motivation point to three core needs: autonomy, competence, and belonging

• Before saying yes to a project, job, or commitment, ask: will this increase or decrease autonomy, competence, or belonging in my life?

• In an AI-disrupted career, this filter matters more — because the wrong yes compounds faster

• For existing commitments, ask what conversations or moves would restore any of the three

• Bonus: turn the filter into a prompt and riff with Claude or ChatGPT on the decisions you’re stuck on

The Three Needs

Stulberg pulls from decades of self-determination research. We thrive over the long haul when three needs are met:

Autonomy — some control over how we spend our time and energy. Not total freedom. Just a real say in the how.

Competence — a path toward concrete improvement in our chosen pursuits. The thing we’re doing needs to grow our craft, not just consume our hours.

Belonging — connection to something beyond ourselves. A person, a community, a lineage, a tradition. An emotional stake in why this work exists.

His line that stopped me: “The more time and energy we spend on pursuits that afford us autonomy, competence, and belonging, the better.”

Simple. But almost nobody applies it when evaluating the next thing on their plate.

Why This Filter Matters Right Now

A year ago, a lot of work was good enough. The pay was fine, the scope was clear, the path was predictable. You could stay on autopilot and be okay.

That’s over. AI is redrawing the edges of what humans should do. Tasks that felt worth doing in 2024 are now commodity output. Roles that felt stable are getting reassembled. The leaders I coach are making harder choices — about what to say yes to, what to drop, and what to rebuild.

In that environment, the wrong yes doesn’t just waste time. It compounds. Every month spent on a pursuit that drains autonomy, stalls competence, or isolates you is a month your peers are getting sharper on the things that will actually matter in 2027.

Which is why Stulberg’s question has become my default diagnostic:

Will this increase or decrease autonomy, competence, or belonging in my life?

How I’m Using It

Three ways I’ve been running this filter in the last few weeks:

On new opportunities. When something lands in my inbox — a speaking gig, a consulting ask, a collaboration — I don’t jump to the calendar. I ask the three. Does it give me more control over my time, or chain me to someone else’s schedule? Does it push my craft forward, or just repeat what I already know? Does it connect me to people and ideas I care about, or is it a transaction?

If two of the three are a no, I pass. No agonizing.

On existing commitments. Stulberg adds a second move most people skip. For work you’re already in, ask what actions would enrich the three. How can I protect more autonomy here? What conversation with my team would rebuild competence momentum? What would reconnect me to why this work matters? A good commitment doesn’t need to be abandoned — it often just needs a small intervention.

As a prompt, when I’m stuck. This is where the AI angle gets practical. When I’m genuinely torn, I paste the situation into Claude and run it through the filter:

I'm deciding whether to [take on / continue / walk away from] this project:

[brief description — scope, time commitment, stakeholders, outcome]

Use Brad Stulberg's framework from The Way of Excellence.
Evaluate this on three dimensions:
1. Autonomy — will it increase or decrease my control over my time and energy?
2. Competence — will it grow my craft, or just consume hours?
3. Belonging — does it connect me to something beyond myself, or is it purely transactional?

Give me a direct read on each, then the trade-offs I should weigh before saying yes or no.

Claude doesn’t decide for me. But it surfaces the angles I’d missed — especially the ones I was quietly avoiding.

The Harder Version of the Question

The sharpest line in the chapter is this: “What would it look like to shape our lives for more mastery and mattering?”

That’s the harder question. Not should I say yes to this one thing, but:

Am I designing my life around pursuits that grow me and connect me — or am I letting it happen to me?

In an AI era where almost everything about work is in motion, the leaders I watch thriving are the ones asking this out loud. They’re not waiting for the dust to settle. They’re picking the pursuits that compound autonomy, competence, and belonging — and pruning the ones that don’t.

That’s the real work. AI is the accelerant. But what you’re accelerating — that’s still the decision only you can make.

Your Turn

Pick one commitment on your plate right now. Run it through the three.

→ Is it giving you more or less autonomy than it did six months ago?
→ Is it building real competence, or just repeating what you already do well?
→ Do you feel connected to the people and the purpose behind it?

If the answer is honest and uncomfortable, that’s the signal. The next move isn’t always quit — sometimes it’s a conversation, a scope change, a recommitment. But the filter cuts through the noise.

Reply and tell me what came up. I read every response.

Stay curious. Stay hands-on.

James

The book is The Way of Excellence by Brad Stulberg. Worth reading the whole chapter on the psychology of excellence — chapter two is where this framework lives.

If this was useful, forward it to one person weighing a hard yes right now. They can subscribe at graymatter.jamesgray.ai.

We’d spent weeks learning tools, building workflows, writing prompts. And then, one by one, people started sharing — not what they’d built, but who they were becoming. Someone said AI had made them more creative than they’d felt in years. Another said they could see a broader version of who they could be. A third said: for the first time in a long time, I know what I want to do next.

That wasn’t a conversation about AI. That was a conversation about the Life’s Task.

Robert Greene writes about this in Mastery — the idea that each of us has a primal inclination, a thread that runs through everything, and that the work of a lifetime is to find it and follow it fully. I’ve been reading Greene for years. But I didn’t expect AI to be the thing that brought his theory to life in real time — accelerating the moment when people finally see what’s possible for them.

AI isn’t just changing how we work. It’s forcing a deeper question: what are you actually pointing this at?

Subscribe now

Five Strategies for Finding Your Life’s Task

Greene offers five strategies. I walked through all of them in this episode — here’s the map.

1. Return to Your Origins — The Primal Inclination Strategy
Go back before the job titles, before the expectations, before the world told you what to be good at. What drew you in as a child? What did you lose yourself in? I ask this in every cohort, and what strikes me is how quickly people remember — and how long they’ve been ignoring it. That pull was never random. It was always pointing somewhere.

2. Occupy the Perfect Niche — The Darwinian Strategy
Don’t compete in a crowded lane. Find the intersection that is uniquely yours — where your combination of skills, experience, and inclination has no direct competition. That’s where you thrive.

3. Avoid the False Path — The Rebellion Strategy
Some paths are chosen for the wrong reasons — money, approval, inertia. Greene calls this the false path. Recognizing it takes courage. Leaving it takes more.

4. Let Go of the Past — The Adaptation Strategy
What got you here won’t necessarily get you there. If AI has reshaped your industry or your role, the task isn’t to hold on — it’s to find what carries forward and build from there.

5. Find Your Way Back — The Life-or-Death Strategy
Some people only find their Life’s Task after a crisis forces the question. A job loss. A health scare. An industry upended. The disruption isn’t the end — it’s the redirection.

The Inner Quest

The Inner Quest is a series within the Graymatter podcast — dedicated to one of its three pillars: mastering yourself. Alongside mastering AI and building what matters, this is the thread I believe matters most.

Not tools. Not frameworks. The deeper journey — to find ourselves, evolve ourselves, and adapt ourselves. The quest that runs beneath everything else. The one that doesn’t end.

Every episode, one idea worth sitting with. This is that series.

Your Reflection Prompt

Somewhere inside you, you already know.

There is something — in your heart, in your bones — that is your Life’s Task. Something that would bring out your uniqueness in a way nothing else can. You’ve caught glimpses of it. You may have pushed it away. It’s likely that you haven’t had the courage to fully touch it, to say it out loud, to pursue it.

That’s not weakness. That’s human. The Life’s Task asks everything of you, and that’s terrifying.

But here’s what I want you to sit with: we don’t know how many days we have. None of us do. And when you hold that truth — really hold it — the question changes.

Not “what should I do with my career?”

But: what would I honor?

What is the one thing you can see, right here, right now — your Life’s Task, your opportunity, the thing that is uniquely yours to bring into the world?

Write it down. Even one sentence. That’s where it begins.

I’d love to know what comes up for you. Drop it in the comments — even one sentence. You might be surprised what you write.

-James

Most AI education gives you pieces. A prompting trick here. A tool demo there. Disconnected fragments that leave you with the same question you started with:

How do I actually go from my business process to a working AI system?

Over the next three weeks, I’m running three free Lightning Lessons on Maven that answer that question — start to finish.

Each session is 30 minutes. Each one builds on the last. Together, they walk you through the Business-First AI Framework — the same 7-step methodology I teach in two cohort courses — from deconstructing a messy process to testing and iterating a production-ready AI workflow.

Here’s what’s coming.

Subscribe now

Week 1: Deconstruct (Framework Step 2)

March 27 | 30 min | Free on Maven

Your 5-step process is actually 15 steps. You just can’t see them yet.

That’s the core insight of the Deconstruct phase. Most AI projects fail not because the technology breaks — but because the process wasn’t broken down enough for AI to execute reliably. Hidden decisions, implicit data handoffs, undocumented context needs, and failure modes only surface after you’ve built the wrong thing.

In this session, I’ll deconstruct a real business process live using a 5-question framework:

• Discrete Steps — What are the actual sub-steps hiding inside each “step”?

• Decision Points — Where does someone make a judgment call?

• Data Flows — What goes in, what comes out, where does it come from?

• Context Needs — What templates, docs, or references does each step require?

• Failure Modes — What does bad output look like, and how would you catch it?

By the end, a simple-looking process becomes a fully mapped workflow definition — the kind of clarity AI actually needs to do useful work.

You’ll walk away with: A repeatable methodology you can apply to any process in your organization. No AI tools required — just sharper thinking about how work actually works.

🎟️ Register for free on Maven

Week 2: Design + Build (Framework Steps 3-4)

March 31 | 30 min | Free on Maven

You’ve deconstructed the process. Now what?

This session picks up where Week 1 leaves off. Starting from a workflow definition, I’ll walk through the Design and Build phases — live on Claude.

First, Design: you’ll see how each step in a deconstructed process maps to AI building blocks. Which steps become prompts, which become skills, which need agent orchestration, which require integrations. The design matrix classifies your workflow — deterministic, guided, or autonomous — and that classification constrains what you can build.

Then, Build: you’ll watch the actual construction. A workflow definition becoming executable artifacts in Claude Code, in real time. The definition drives every decision. You’re not guessing what to create — the Deconstruct output tells you exactly what artifacts you need.

The key insight: Build is step 4 of 7. Shipping the first version isn’t the finish line. Test and Improve are what turn a build into a production system — and that’s where we’re headed in Week 3.

You’ll walk away with: A clear mental model for turning any deconstructed process into a working AI system — and an understanding of what comes next to make it production-ready.

🎟️ Register for free on Maven

Week 3: Test + Iterate (Framework Steps 5 & 7)

April 3 | 30 min | Free on Maven

You’ve built the workflow. Now prove it works — and make it better.

This is where most people stop. They ship v1 and hope for the best. But the Business-First AI Framework has two more phases for a reason: Test verifies your build produces consistent, quality output across real scenarios. Improve optimizes for speed, cost, and reliability so the workflow actually gets used in production.

In this session, I’ll show both phases in action — using Claude skill configuration as the lens:

• Structured evals (Test) — Run evaluations that verify your skills produce consistent output before you rely on them. Evals catch the inconsistencies that spot-checking misses.

• Effort levels (Improve) — Control how deeply Claude thinks before responding. High for nuanced analysis, low for straightforward transformations. Match the compute to the job.

• Model selection (Improve) — Match Opus, Sonnet, or Haiku to each skill based on the reasoning it requires. Not every skill needs the most powerful model.

The punchline: a well-configured skill on Haiku can outperform a poorly configured one on Opus. Testing tells you which configuration actually works. Iteration makes it cheaper and faster without sacrificing quality.

You’ll walk away with: An eval methodology to verify your builds work — and a configuration matrix for optimizing quality, speed, and cost across any Claude skill.

🎟️ Register for free on Maven

Why These Three Sessions Fit Together

This isn’t three random topics. It’s one framework:

Analyze → Deconstruct → Design → Build → Test → Run → Improve

That’s the Business-First AI Framework — the 7-step methodology I teach in my Maven courses and at Berkeley. These three Lightning Lessons cover the critical phases:

• Week 1 (Deconstruct) exposes the real complexity in your process

• Week 2 (Design + Build) turns that clarity into a working AI system

• Week 3 (Test + Improve) proves the system works and makes it faster, cheaper, and more reliable

Most people skip straight to building. Then they wonder why the results are inconsistent. The reason is almost always the same: the process wasn’t broken down enough, or the system was never tested and tuned for the job.

These sessions give you the key phases in 30 minutes each. My Maven courses — Hands-on Agentic AI for Leaders and Claude for Builders — give you the full lifecycle with hands-on practice on your own workflows.

All Three Are Free. All Three Are Live.

Live demos, real processes, real builds. And if you can’t make it live, register anyway. You’ll get the recording and the slide deck after each session.

Register for any or all:

• March 27: Deconstruct Any Business Process into an AI Workflow

• March 31: Build an AI Workflow from a Business Process

• April 3: Configure Claude Skills for Quality, Speed, and Cost

If you know someone who’s been trying to figure out how to go from business process to working AI, forward this to them. These three sessions cover the complete path.

Stay curious. Stay hands-on. 🙌

James

You set up an AI workflow to handle your weekly pipeline review. It’s supposed to pull deals from your CRM, flag anything stalled, draft a summary, and post it to Slack. You kick it off and step away.

Three minutes later: “Do you want to allow this Notion query?” You approve it. Two minutes later: “Do you want to allow this Slack message?” You approve it. Then: “Do you want to allow this CRM update?” Three more approvals follow in the next five minutes.

By the time the workflow finishes, you’ve approved eleven actions. A task that was supposed to run while you did something else pulled you out of focus seven times. You might as well have just done it yourself.

This is the approval-fatigue problem with agentic AI that nobody mentions in the demos. And until last week, Claude Code gave you exactly two ways to handle it — neither of them designed for real business work.

TL;DR

• Claude Code shipped auto-mode on March 24 — a new permissions setting between “approve everything” and “skip everything”

• Before each tool call (Notion, Slack, Gmail, CRM, Sheets — any MCP connection), a classifier decides if it’s safe to proceed automatically or risky enough to block

• Low-risk actions execute without interrupting you; potentially destructive actions get blocked before they run

• This is the thing that makes business workflows actually autonomous — not just automated with a human stuck in the approval loop

• It’s a research preview for Team plan users now; Enterprise and API users get it in the coming days

• Honest limitation: the classifier isn’t perfect, and Anthropic still recommends isolated environments for now

The All-or-Nothing Problem (Before Auto-Mode)

If you’re running Claude Code with MCP connections to your business tools — Notion, Slack, Gmail, HubSpot, Google Sheets — you’ve been living with a frustrating binary.

Option A: Default mode. Every MCP tool call asks for approval. Claude wants to read a Notion database? Approve. Write a new record? Approve. Send a Slack message? Approve. Update a deal stage in your CRM? Approve. The workflow is safe. It’s also not autonomous in any meaningful sense. You’re the approval layer, which means you’re still doing the work — just with extra steps.

Option B: --dangerously-skip-permissions. No approvals, ever. Claude runs from start to finish without checking in. This sounds like the autonomous workflow you wanted until you think about what you’ve traded: any ability to catch a mistake before it executes. Mass-delete the wrong Notion records? Send a draft Slack message to the wrong channel? Write junk data to a production CRM? You find out after the fact.

The flag is named --dangerously-skip-permissions for a reason. Anthropic isn’t being dramatic. For workflows touching real business data and real communication channels, skipping permissions entirely is a bad bet.

Neither option is actually right for how you want to use Claude Code as a business operations tool. Default mode is too slow. Skip-permissions is too reckless. The gap between them is where the real frustration lives.

What Auto-Mode Actually Does

Anthropic shipped auto-mode on March 24 as a research preview for Team plan users. The mechanism is straightforward: before each tool call runs, a classifier reviews it.

The classifier categorizes the action — safe or risky — and routes accordingly:

• Safe actions proceed automatically. Reading records, writing standard updates, and posting messages within normal parameters. Claude keeps moving without interrupting you.

• Risky actions get blocked. The classifier flags potential problems — bulk deletes, data exports to unexpected destinations, actions that appear destructive — and redirects Claude to find an alternative approach.

• Persistent blocks surface a prompt. If Claude keeps attempting actions that keep getting blocked, it eventually surfaces a permission request to you. The system doesn’t silently fail — it escalates when it actually needs to.

That last point matters. Auto-mode isn’t binary. It’s a dial. The classifier handles the routine. You get pulled in when there’s genuinely something to decide.

For a business operations workflow, this changes the picture entirely. A pipeline review that used to ping you 11 times now runs to completion with 1 or 2 meaningful check-ins. A daily brief that pulls from Notion, summarizes it, and posts to Slack actually executes while you’re in your first meeting of the day. The approvals that do come through are the ones that actually warrant your attention.

What This Changes for Business Operations

The operations workflows I see leaders building — and wanting to build — are exactly the category auto-mode unlocks.

Think about the kinds of tasks that make sense to delegate to Claude Code with MCP connections:

• Pull data from a CRM or spreadsheet, identify exceptions, draft a report, and post it to a Slack channel

• Monitor an inbox, triage inbound requests, update a Notion tracker, and draft responses for review

• Scan a project management board, flag overdue items, update statuses, and send a summary to stakeholders

• Reconcile meeting notes against a Notion database, extract action items, and create task records

Every one of these workflows involves multiple sequential tool calls. In default mode, each call is an interruption. That makes the workflow feel more like a demo than a deployment — something you’d show to impress someone, not something you’d actually rely on to do work while you’re busy doing other work.

Auto-mode is what makes these workflows real. Not impressive. Real.

The permission-fatigue problem isn’t just about convenience — it’s about what happens to your attention when approvals are required for everything. When you have to approve every low-stakes action, you stop carefully reviewing the approvals. Everything becomes a quick click. And that’s the moment you’re most likely to miss the one approval that actually matters.

Matching the approval friction to the actual risk of the action is how you build a system where human judgment shows up where it’s worth something.

The Junior Operator Analogy

Here’s the mental model I keep coming back to.

Think about how a strong operations coordinator handles delegated work. They handle the standard decisions — updating the tracker, sending the routine check-in, filing the document where it belongs — without asking you every time. That’s not because they’re unsupervised. It’s because the trust level for those decisions is already established.

But they bring you in on things that are outside their lane: a message that doesn’t have an obvious right answer, an action that could be hard to undo, a decision where they genuinely aren’t sure what you’d want. The judgment about what to escalate is itself a skill — and a good coordinator gets it right most of the time.

Auto-mode is Claude Code developing that judgment for MCP tool calls. It’s not unlimited autonomy. It’s calibrated autonomy, matched to the actual risk of each individual action. The routine proceeds. The genuinely uncertain gets flagged.

That’s the working relationship you want with an AI system doing operations work — not “check with me constantly” and not “never check with me.” Something in between, calibrated to what actually warrants a decision.

What Auto-Mode Can’t Do (Being Honest)

Auto-mode is a research preview. That’s not a disclaimer to skip — it matters for how you use it.

The classifier isn’t perfect. Anthropic says this directly: some risky actions will slip through when intent is ambiguous, or when Claude doesn’t have enough context about your environment to recognize additional risk. Some benign actions will also get blocked. The system is good, but calibrate your expectations accordingly.

It reduces risk compared to --dangerously-skip-permissions — it doesn’t eliminate it. Anthropic explicitly recommends using auto-mode in isolated environments. If you’re running it against production Notion workspaces, live CRM data, or active communication channels — the calculus hasn’t shifted as much as you might think. Start with test environments, read-only connections, or low-stakes workflows while you build a feel for how the classifier behaves.

There’s a small cost. The classifier runs before each tool call, resulting in additional token consumption and marginal latency. For most business workflows, this is negligible. Worth knowing it exists.

Admins can disable it. For team deployments, this is important: administrators can turn off auto-mode entirely with "disableAutoMode": "disable" in managed settings. If you’re planning to roll this into team workflows, check with whoever manages your Claude Code deployment first.

The Bigger Pattern: Autonomy Is a Dial, Not a Switch

Here’s the practitioner take that applies well beyond auto-mode.

Most business leaders think about AI autonomy as a binary: either you’re in control, or the AI is. Either you approve everything, or you trust it blindly. That framing produces exactly the two bad options we started with.

The more useful mental model: autonomy is a dial, calibrated to the actual risk of individual decisions. Some decisions are low-stakes and should proceed automatically. Others warrant human judgment. A well-designed system knows the difference.

Auto-mode is the first serious implementation of this in Claude Code. And it points to a principle that should shape every AI workflow you build or oversee.

When you’re connecting Claude Code to your business tools via MCP — Notion, Slack, Gmail, HubSpot, Google Sheets, whatever your stack looks like — the autonomy question is always present. How much should the agent decide on its own? When should it check in? What constitutes an action that actually requires a human?

The wrong answer is “always check in” (you’re the bottleneck, there’s no leverage) or “never check in” (the risk is unmanaged, the accountability is gone). The right answer is: match autonomy to actual decision risk. High-frequency, low-stakes tool calls proceed automatically. Novel situations, irreversible actions, and genuinely ambiguous contexts surface human judgment.

Auto-mode operationalizes this for MCP tool calls. Your job, as someone building or managing AI-connected business workflows, is to operationalize it across your entire workflow design. That’s not a technical question — it’s a judgment call about which decisions actually require you.

How to Get Started

Auto-mode is available now as a research preview for Claude Team plan users. Enterprise and API users will get access in the coming days.

To enable it from the CLI:

claude --enable-auto-mode

Then cycle to it using Shift+Tab within a session.

On Desktop or in the VS Code extension: Auto-mode is disabled by default on the desktop app, so you’ll need to enable it first. Go to Settings → Claude Code and toggle auto-mode on. Once enabled, you can select it from the permission mode dropdown within any session.

Works with: Claude Sonnet 4.6 and Opus 4.6.

My recommendation: start with a workflow with low stakes and a clear scope. A Notion query that reads but doesn’t write. A summary workflow that drafts a Slack message for your review instead of sending it directly. Get a feel for what the classifier flags and what it passes. Build your own calibration for when to trust it before you put it in front of anything consequential.

That’s the same principle I teach in my agentic AI work: don’t assume the system’s judgment is right for your context. Observe it, then extend trust incrementally.

If you’re building business operations workflows with Claude — and you want a structured way to set up skills, agents, and MCP integrations that actually run your business — that’s exactly what we build in Claude for Builders. The next cohort starts on April 13th.

Stay curious. Stay hands-on.

James

Hannah Pritchett, Chief People Officer at Anthropic, spent six months trying to explain to her team what she wanted them to build. She described it in meetings. She wrote it down. They came back with what they thought they heard. None of it was right.

So over a weekend, she built a rough prototype herself using Claude Code. She showed it to her team. Their response: “Now I understand what you want.”

Six months of misalignment. Resolved the moment she stopped describing and started building.

TL;DR:

• AI executes your ambiguity perfectly — if you can’t articulate what you want, AI won’t figure it out for you

• The two leadership skills that matter most in the AI era: clarity (knowing what to ask for) and discernment (knowing whether you got it)

• You can only develop these skills by building — not by delegating, reviewing decks, or attending demos

• 86% of C-suite leaders are increasing AI investment, but only 20% of employees feel like co-creators in how it changes their work

• The leaders who close that gap are the ones who build alongside their teams — not above them

The Clarity Gap Is a Leadership Gap

Melissa Daimler wrote a piece in Forbes this week that landed for me because she put a name on the exact leader I’ve been teaching for the last two years — at UC Berkeley Executive Education, at Maven, and across every cohort I’ve run. The builder-leader. The leader who gets hands-on before asking others to build.

Her core argument: the biggest problem with AI in organizations isn’t the technology. It’s that leaders haven’t done the hard work of getting clear about what they actually want. And her sharpest line: “AI will execute your ambiguity perfectly.”

Over the last year, I’ve watched this identity emerge in real time across my Maven cohorts. CEOs, entrepreneurs, founders, SVPs, marketing leaders — people who didn’t come from technical backgrounds but who chose to get hands-on anyway. They embody this builder-leader persona: they learn by doing, they build before they delegate, and they develop sharper instincts because of it.

I’ve also met the other kind. Leaders who view hands-on work as beneath them. Who believe their role is to set direction and let technical people figure out the details. A year ago, that was a defensible position. In 2026, those leaders are becoming irrelevant — and fast.

The pattern is always the same. A leader assigns a deliverable. An employee uses AI to produce it. The leader asks one clarifying question. The employee can’t answer it. The leader blames the tools.

But the tools aren’t the problem. The prompt was vague going in. The output was accepted without scrutiny on the way out.

Here’s the harder question Daimler asks — one most leaders don’t want to hear: Could you have answered that clarifying question yourself? Had you ever done the work you just assigned?

If not, you don’t just have a clarity problem with your employee. You have one with yourself.

What Builder-Leaders Do Differently

The builder-leader isn’t a leader who codes for a living. It’s a leader who has done the work at least once, so they know what good looks like. That distinction changes everything about how you lead an AI-augmented team.

A leader who hasn’t built asks: “Why doesn’t this look right?”

A builder-leader asks: “What context did you give it? How specific were your prompts? What did you do when the first output wasn’t right?”

That second conversation is a coaching moment. The first is a dead end.

This is what I’ve been building my entire teaching practice around. When executives in my courses sit down with Claude Code and build something — a workflow, a prototype, a decision tool — the shift is immediate. They stop asking “what can AI do?” and start asking “what do I actually need?” Those are completely different questions, and only the second one leads anywhere useful.

Daimler’s Paris travel app story makes this tangible. She built an app to organize hundreds of restaurant and café recommendations. The first version was functional but flat. Then she got clearer: organize by arrondissement so her family could use it contextually. Then clearer still: design it so her family would actually want to open it. Each round of building forced a new round of clarity. The prototype wasn’t the product. The prototype was the clarity.

The Two Skills AI Demands But Can’t Give You

Daimler identifies two skills that separate builder-leaders from everyone else: clarity and discernment.

Clarity is the front end. What you ask for, how you scope it, what quality looks like before AI generates anything. This is harder than it sounds. So much of what makes a great leader lives in their head — instincts, pattern recognition, the “I just know.” AI forces you to make that implicit knowledge explicit. You cannot prompt what you cannot articulate.

Discernment is the back end. The judgment to evaluate whether AI’s output is actually the outcome you wanted. AI produces output confidently. It will write you a board memo that sounds perfect — clean structure, polished prose — while the market data is from 2023, the competitor analysis includes a company that was acquired last year, and the recommendation contradicts your actual strategy.

Discernment is catching that before it goes out. And you can only catch it if you’ve done the work yourself at least once.

This maps directly to what I see in my courses. I developed a framework called Business-First AI that walks leaders through three steps: Analyze the workflows that matter, Deconstruct them into the detail required to build, and Build the actual solution.

Step two — Deconstruct — is where the a-ha happens. Every time.

Leaders walk in thinking they understand their workflows. Then I give them 30 minutes to break one down: every decision point, every input, every handoff, every edge case.

When we reconvene, the reactions are always the same. They’re amazed by the edge cases they’d never considered, the details they’d forgotten, the steps they’d been carrying in their heads without ever making explicit. They leave with a new appreciation for the level of clarity truly required for a machine to carry out the workflow that lives in their head.

That’s the clarity gap Daimler is writing about, experienced in real time.

By the time they reach step three — Build — the hard work is already done. The prototype comes together faster because the thinking is sharper. The clarity came from the deconstruction, not from the tool.

You can’t develop taste by reading a menu. You develop it by cooking.

What’s at Stake

Here’s what leaders are risking by staying hands-off.

Your credibility is at stake. BCG found that when leaders demonstrate strong support for AI, the share of employees who feel positive about it rises from 15% to 55%. But “support” isn’t sending a company-wide email or mandating adoption. It’s leaders who are experimenting with the tools, working through the same challenges, and building alongside their teams. Your employees know the difference between a leader who has built something and one who’s read the executive summary.

Your strategic vision is at stake. If you haven’t used AI to build, you’re forming strategy based on vendor demos and consultant decks. You’re making the biggest workforce decisions in a generation — investing and cutting — without the firsthand understanding those decisions require. Accenture’s 2026 data is stark: 86% of C-suite leaders are increasing AI investment, but only 20% of employees feel like active co-creators. That gap doesn’t close with better tools. It closes when leaders develop the clarity to know what they want and the discernment to know when they’ve got it.

Your ability to lead is at stake. The leader who hasn’t built can’t coach their team through AI challenges. They can’t ask the right follow-up questions. They can’t distinguish between AI slop and genuine insight. And here’s the uncomfortable truth Daimler surfaces: “AI slop” isn’t the AI’s fault. Human slop is accepting it. If you can’t tell the difference, that’s not a technology problem. That’s a leadership problem.

Your competitive position is at stake. The organizations moving fastest with AI aren’t the ones with the biggest budgets. They’re the ones where leaders have built enough to articulate a clear vision, set specific quality standards, and recognize when output meets them. Every week you wait to get hands-on is a week your competitors are developing the clarity and discernment you’re still outsourcing.

If you think getting hands-on is beneath you, you’re wrong. It’s beneath you to lead a team through a transformation you haven’t experienced yourself.

Start Here

Pick one deliverable you’ve been about to assign. A report, a strategy doc, an analysis. Do it yourself first. Take 30 minutes. Open Claude, ChatGPT, or whatever tool your company uses, and start with a real problem you’ve been putting off.

Be specific going in. Don’t say “give me an analysis of our metrics.” Say “I want a metrics report that tells me the story behind the numbers, identifies the top two or three gaps we need to address, and ends with agreed-upon next actions we can bring to the team.” Upload relevant documents. Give examples of what good looks like. Set constraints.

Evaluate what comes back with real critical thinking. AI doesn’t signal uncertainty. It sounds confident whether it’s right or wrong. That’s your job to catch.

Then bring what you learned back to your team. Show them what you built. That conversation — where you share your process, your prompts, your mistakes — is the work. That’s how you become a builder-leader.

Want a structured way to start? I built a Business-First AI plugin for Claude Code that guides you through all three steps of the framework — Analyze, Deconstruct, and Build. Install the plugin and it walks you through identifying the right workflow, breaking it down to the level of clarity AI requires, and constructing the solution. It’s the same process my cohort students use, available as a set of skills you can run on your own.

You won’t get it right the first time. As Daimler puts it: “The question is whether you’ll get the Eiffel Tower or the Egyptian pyramids. And whether you’ll know the difference.”

Master AI. Master Yourself. Build What Matters.

This article reinforced something I believe deeply: the AI era doesn’t reward the leaders who adopt the fastest. It rewards the leaders who get clear the fastest. And clarity only comes from building.

The great leaders I work with aren’t just learning AI. They’re fusing AI with their own leadership identity — reimagining what it means to set vision, to coach teams, to make decisions. They see the opportunity and they’re embracing it, reshaping who they are as leaders at the intersection of technology and judgment.

That’s the real work. Not mastering AI as a tool. Mastering yourself as a leader — and building what matters from that foundation. The two are inseparable now.

Stay curious. Stay hands-on.

-James

Going deeper. If this resonates and you want to go from reading about builder-leadership to practicing it, my Maven courses are built for exactly that. Claude for Builders teaches you to build real workflows with Claude Code and Cowork. Hands-on Agentic AI for Leaders takes you from building blocks to full AI-powered business workflows. Both have April cohorts open for enrollment. No slides. No theory. You build.

TL;DR:

• There are 10 building blocks organized into 3 layers: Intelligence, Orchestration, and Integration

• Most workflows only need 2-4 blocks — you don’t need all ten

• The starter combo is Prompt + Context. Add blocks as complexity demands

• Skills teach HOW. Agents EXECUTE. Together, they’re the orchestration duo

• This framework gives you a shared vocabulary to design, discuss, and improve every AI workflow you touch

• Deep-dive reference for each block: Agentic AI Building Blocks on the Hands-on AI Cookbook

Why a Framework Matters

Here’s the problem I see across executive education cohorts: teams jump straight into tools without a shared vocabulary. One person says “agent” and means a chatbot. Another means an autonomous system. A third means a Project workspace with uploaded files.

The result? Misaligned expectations, over-engineered solutions, and workflows that break when the person who built them goes on vacation.

Across 6,000+ professionals I’ve taught, the organizations that move fastest with AI share one trait: they have a common language for what they’re building. These 10 building blocks are that language.

One more thing before we dive in. The blocks are tools — but the person wielding them determines the outcome. A framework without judgment produces noise. Judgment without a framework wastes time. The goal is both.

The Three Layers

The building blocks stack into three layers. Each layer builds on the one below it.

Intelligence (foundation) — the persistent engine, knowledge, and workspace powering every interaction.

Orchestration (middle) — the instructions, routines, and autonomous agents that direct and do the work.

Integration (top) — the protocols, interfaces, and frameworks that bridge AI to external systems and code.

Think of it like a building. Intelligence is the foundation and utilities. Orchestration is the people and processes inside. Integration is the doors, windows, and connections to the outside world.

Let’s walk through each block with real examples you can apply this week.

Layer 1: Intelligence (The Foundation)

These four blocks are the persistent infrastructure beneath every AI interaction.

1. Model

The AI engine — a system trained on data that takes input and produces output through learned patterns.

Choosing the wrong model is like hiring a senior architect to answer the front desk phone. You waste money on overkill or get poor results from underkill. The key decision is always speed vs. depth vs. cost.

Use a fast model (Claude Haiku, Gemini Flash) to auto-tag 500 support tickets overnight — cheap and fast. Use a reasoning model (ChatGPT, Claude Opus, Gemini Pro) to analyze patterns across those tickets and recommend process changes — slower and more expensive, but worth it for strategic insight.

Try this: Pick one recurring task and ask — am I using the right model tier? Most people default to the most powerful model for everything. That’s like taking a helicopter to the grocery store.

2. Context

This is the one that separates useful AI from impressive-but-useless AI.

Context is the unique knowledge your workflow requires that isn’t baked into the model — your files, docs, databases, proprietary data. It comes in three forms: uploaded files (PDFs, spreadsheets), referenced documents (Google Docs, Notion pages), and connected data (databases, live systems).

Here’s the test: “Analyze recurring themes in customer feedback and suggest which product feature to prioritize next quarter.” Generic prompt, generic answer. Now add your last three quarterly reports as uploaded PDFs. Completely different output — grounded in your reality, not the model’s training data.

I see this gap constantly in executive education. People complain that AI gives them “generic” answers. Nine times out of ten, they haven’t given it anything specific to work with. Context is the fix.

Try this: If you’re trying to find customers for your business, write up your buyer persona in a markdown file — who they are, what they care about, what problems they’re solving. Now attach that file any time you ask AI to draft outreach, write copy, or brainstorm campaigns. Same file, every time, dramatically better output.

3. Memory

Memory is what turns AI from a stranger into a colleague who knows how you work.

After several sessions, your AI assistant remembers that you structure reports as executive summaries. It knows you prefer bullet points over paragraphs. It recalls that your team uses OKRs, not KPIs. You didn’t configure any of this. It learned from working with you. Claude, ChatGPT, and Gemini all support memory — the implementations differ, but the concept is the same.

People confuse Memory and Context constantly. Here’s the distinction: you curate context (you choose which files to upload). The system curates memory (it observes your patterns and stores them automatically). One is your briefcase. The other is institutional knowledge.

Try this: Use the same AI tool for 3-4 sessions this week. Then ask: “What have you learned about my preferences?” The answer reveals how memory compounds with use. And here’s a trick — you don’t have to wait for the AI to pick up on patterns organically. You can tell it directly: “Remember that my team reports on a quarterly cadence” or “Remember that I prefer concise executive summaries over detailed narratives.” That fact gets stored in memory and applied in future sessions.

4. Project

If you’ve ever started a new AI conversation and spent the first five minutes re-explaining who you are and how you work — you need a Project.

Projects are self-contained workspaces with their own chat histories, knowledge bases, and custom instructions. Think of them as folders that actively shape the AI’s behavior. Create a “Q4 Investor Updates” project, upload your financial data and competitive landscape docs, set the tone and format rules once — and every conversation in that workspace inherits it all.

The killer feature is isolation. Your investor update project doesn’t leak into your marketing project. Different rules, different context, different memory — same tool.

Try this: Identify the AI workflow where you paste the same instructions every time. Create a Project for it — add your custom instructions, upload the files you always reference, and set the rules once. Next conversation in that workspace, notice how much setup time disappears.

Layer 2: Orchestration (The Execution Layer)

This is where work actually gets done. Three blocks that range from simple instructions to autonomous execution.

5. Prompt

Everyone knows this one. Natural language instructions you provide during a conversation — ephemeral, conversational, reactive.

“Review this customer email and suggest three response options: 1) Apologetic and immediate, 2) Professional and measured, 3) Empowered with alternatives.” That’s a prompt. Close the chat and it’s gone. For a one-off request, it’s the right tool.

The mistake people make isn’t at the prompt level — it’s staying there too long. If you find yourself writing the same prompt for the third time, you’ve outgrown this building block.

Try this: Start saving your best prompts as markdown files. The ones that produce great results — save them, refine them, reuse them. This simple habit is the first step toward Skills, which is exactly where we’re headed next.

6. Skill

This is the building block I’m most passionate about, because it’s where most people get the biggest immediate ROI.

A Skill is a reusable instruction package that an AI discovers and loads dynamically when relevant. Think of skills as training manuals, not employees — they teach the AI how to do something without executing autonomously. They’re portable, composable, and loaded progressively.

Here’s what that looks like: you say “Research our competitor Acme and write a competitive brief aligned with my brand guidelines.” The AI discovers the relevant skills on its own — researching-competitors, writing-competitive-brief, applying-brand-guidelines — and loads them. You didn’t tell it which skills to use. It figured that out from the request.

I run my entire content operation this way. I have 68 skills that handle everything from writing LinkedIn posts to preparing cohort sessions. Each one encodes the best practices, templates, and quality standards I’d otherwise have to re-explain every time. Write it once, reuse it everywhere.

Try this: Next time you’re about to work on something you do repeatedly — a weekly report, a client proposal, a content brief — pause and ask AI to help you codify it. “Help me turn this into a repeatable how-to manual with steps, quality criteria, and examples of good output.” That manual is your first Skill. Every time you do that task going forward, it gets faster and more consistent.

7. Agent

Agents are where the hype lives — and where the most misunderstanding happens.

An agent is a system where an LLM controls workflow execution to achieve a goal. It plans, uses tools, reflects on progress, and operates with varying autonomy: semi-autonomous (proposes steps, you approve), autonomous (executes fully, reports when done), or continuous (runs on a schedule without being asked).

The best way to understand agents is to contrast them with skills using the same task:

With a Skill: “Write a LinkedIn post about AI building blocks.” The skill loads your brand voice, post structure, and engagement hooks. It produces the post. You review and publish. The skill didn’t decide to write a post — you did.

With an Agent: “Promote this week’s newsletter across my social channels.” The agent reads the newsletter, decides which platforms to target, identifies the key angles for each, invokes the LinkedIn writing skill for LinkedIn, the X writing skill for X, and drafts all the posts. The agent decided what to do and orchestrated the skills to do it.

Skills teach HOW. Agents EXECUTE. Together they’re the core of the orchestration layer.

I’ll be direct about something: more autonomy isn’t always better. I’ve watched teams spend weeks building autonomous agents for tasks that a simple deterministic workflow would handle in an afternoon. Match the autonomy level to the complexity of the task, not to what sounds most impressive in a demo.

Try this: Create a simple agent as a markdown file. Define its role, the skills it can use, and the task it handles — something like a “Weekly Report Agent” that gathers data, applies your formatting standards, and drafts the report. On platforms like Claude, these markdown-based sub-agents can perform actions, invoke skills, and even coordinate with other agents. No code required — just a well-structured file.

Layer 3: Integration (The Connection Layer)

The first seven blocks can all live inside a chat window. These last three are how AI breaks out of that window and operates inside your actual business systems. For many leaders, this is where the ROI conversation gets real.

8. MCP (Model Context Protocol)

Think of MCP as “USB for AI” — an open standard that lets AI assistants read from and write to your external systems.

Before MCP, AI lived in a chat bubble. You’d copy data from Notion, paste it into the chat, get a result, then copy it back. MCP eliminates that friction. Now AI can check your calendar, update your CRM, post to Slack, and query your database — all within a single conversation.

MCP connections come in three flavors: data sources (read from databases, docs, wikis), action tools (create tasks, send emails, update records), and real-time systems (live data feeds, webhooks).

Here’s a nuance people miss: MCP and Skills serve different purposes. Skills teach the AI what to do. MCP gives the AI access to do it. A “Schedule Team Meeting” agent needs MCP connections to Google Calendar, Slack, and Notion — plus a Skill that teaches it your meeting scheduling preferences. The blocks are designed to work together.

Try this: List the 3 external systems you interact with most during AI workflows. Anywhere you’re manually copying data in and out is an MCP candidate.

9. API

The programmatic interface for accessing AI models from code — stateless, programmable, usage-based. Every AI product you use — from ChatGPT to your favorite writing tool — is built on an API. When you outgrow the chat window and need AI as a service inside your own systems, this is the building block.

A concrete example: a script calls an AI API (Claude, OpenAI, Gemini) to classify 1,000 customer support tickets overnight. Each ticket gets a category, priority, and suggested response. No human in the loop. Cost: a few dollars for work that would take a team member two full days.

Here’s what’s changed recently: you no longer need to be a developer to use APIs. Agentic coding tools like Claude Code and OpenAI Codex let you describe what you want in plain language, and the AI writes and runs the code for you. The API is the building block. The coding tool is how non-developers access it.

Try this: Think of a system you need to access programmatically but don’t know how to call the API — maybe pulling data from your CRM, syncing records between tools, or automating a report. Open an agentic coding tool like Cursor, Claude Code, or OpenAI Codex and describe what you need: “Write a script that pulls all deals closed this month from HubSpot and formats them as a CSV.” The coding tool builds the API integration for you. You don’t need to know the API — you just need to know what you want.

10. SDK

SDKs sit on top of APIs and add the orchestration plumbing — agent loops, tool calling, error recovery, multi-agent coordination. If the API is a raw interface (send request, get response), the SDK is a framework that handles the patterns you’d otherwise build yourself.

Example: using an agent SDK (Anthropic’s Agent SDK, OpenAI’s Agents SDK, or Google’s ADK) to build a research agent that searches the web, reads PDFs, cross-references sources, and produces a structured report. The SDK handles orchestration, iteration, and error recovery. You focus on defining outcomes.

Same story as APIs — you don’t need to be a developer. The same agentic coding tools that unlock APIs also unlock SDKs. Describe the agent you want to build — its goal, tools, and workflow — and let Claude Code or Codex scaffold it. You define the strategy; the coding tool handles the implementation.

Try this: Open an agentic coding tool and describe a simple agent: “Build me an agent that reads a CSV of customer feedback, categorizes each entry, and writes a summary report.” Watch how fast the SDK goes from concept to working prototype.

How Building Blocks Compose

You don’t use all 10 blocks. You compose the ones your workflow needs — and knowing the right combination is the real skill.

Prompt + Context — The starter combo. You provide instructions and the knowledge AI needs. Handles most one-off tasks: writing, analysis, summarization. This is where 80% of people stop, and for many tasks, it’s enough.

Prompt + Context + Skill — Add repeatability. Instead of crafting the same long prompt every time, the Skill encodes your best practices. Same quality, every time, without the setup tax.

Skill + Agent — The orchestration duo. The agent decides what to do; skills teach it how. An agent writing a newsletter might invoke a research skill, a brand voice skill, and a formatting skill — all without you specifying which ones.

Skill + Agent + MCP — Add real-world connectivity. The agent can now read from and write to external systems. This is where AI workflows start replacing manual processes end-to-end.

Where People Get Tripped Up

I’ll share the patterns I see repeatedly in my courses and consulting work, because they’ll save you time.

The biggest one: treating agents as the default. More autonomy adds complexity, latency, and cost. A deterministic workflow for predictable tasks is faster, cheaper, and more reliable. I’ve watched teams spend six figures building an autonomous agent when a 20-line script would have done the job. Match autonomy to the task, not to the hype.

The second: confusing Memory and Context. This trips up nearly everyone. Context is knowledge you provide. Memory is knowledge the AI accumulates from working with you. They solve different problems, and mixing them up leads to workflows that re-upload documents the AI should already know — or expect the AI to remember files you never shared.

Third: dismissing Skills as “fancy prompts.” They’re not. Skills are portable, reusable instruction packages with templates, examples, and quality criteria. Prompts are ephemeral. The difference is the difference between a recipe card and a cooking class.

And finally: assuming you need all 10 blocks. Most workflows need 2-4. Starting with Prompt + Context and adding blocks as complexity demands is almost always the right approach. Over-engineering a simple task is worse than under-engineering a complex one.

Your Action Plan

You don’t need to master all 10 blocks. Start where you are:

If you’re using AI for one-off tasks — You’re at Prompt + Context. That’s a solid foundation. Focus on improving your context quality (better files, clearer instructions) before adding more blocks.

If you’re repeating the same prompts — You’re ready for Skills. Convert your best prompts into reusable instruction packages. This single step eliminates the most common source of inconsistent AI output.

If you’re managing multi-step workflows — You’re ready for Agents. Start with semi-autonomous (agent proposes, you approve) before moving to fully autonomous. Build trust incrementally.

If you’re manually copying data between AI and tools — You’re ready for MCP. Connect your most-used systems and watch the copy-paste tax disappear.

If you’re processing data at scale — You’re ready for APIs and SDKs. Move from chat-based interaction to programmatic access.

The framework isn’t a ladder you climb from bottom to top. It’s a toolkit you draw from based on the job in front of you.

Explore each block in detail. The Hands-on AI Cookbook has a dedicated Agentic AI Building Blocks section with guides, comparison tables, and a “Which block should I use?” decision guide for each of the ten blocks.

The building blocks give you the vocabulary. But the real leverage comes from your judgment — knowing which blocks to compose, when to add autonomy, and when to keep it simple. AI amplifies the clarity you bring to it.

Stay curious. Stay hands-on.

James

Ready to build, not just read? In my Maven courses, we don’t just learn the building blocks — we build with them. Students walk away with AI-powered workflows that accelerate business value.

TL;DR:

• Most people skip from “I want AI to do X” straight to the tool — and wonder why the results are mediocre.

• The missing step is decomposition: breaking your workflow into discrete steps before you build anything.

• The Business-First AI Framework (Discover → Deconstruct → Build) is a three-step process that closes this gap.

• Deconstruct is the step everyone skips — and it’s the most important one.

• Everything is open source. Try it right now — links to get started below.

I watched a student spend two hours building something impressive, only for it to completely break.

She’d taken about ten Google Slides — detailed internal procedures her team uses for pipeline analysis — and packed them into a Google Gem. The setup was sophisticated. She’d included scoring rubrics, qualification criteria, and stage-by-stage review processes. Everything her team’s top performers actually do when they evaluate a deal.

The Gem couldn’t deliver.

Not because the AI wasn’t capable. Not because Google Gems are limited. The instructions she’d written described what the pipeline review should accomplish — but not how her team actually does it at the step-by-step level. The scoring rubrics were there, but the decision logic connecting them wasn’t. The criteria were listed, but the sequence for evaluating them — which signals what to check first, when to escalate, and what constitutes a red flag versus a yellow flag — lived in her head, not in the instructions.

When she realized this, you could see the shift. “The AI can’t read my mind,” she said. “I need to describe this the way I’d train a new analyst — not the way I’d summarize it for my boss.”

That’s the aha moment. And I see some version of it every single cohort.

The pattern is always the same. Someone has a clear idea of what they want AI to do. They go straight to the tool. They spend an hour — sometimes several — iterating on prompts, rearranging context, trying different approaches. The output is decent but never quite right. Eventually, they either settle for “good enough” or give up.

The problem isn’t the tool. It’s the step they skipped.

The Idea-to-Implementation Chasm

Most AI education teaches you tools. How to write better prompts. Which model to use for which task? How to set up a GPT, a Gem, or a Project.

Almost nobody teaches the bridge: how to go from “I want AI to do X” to a working, repeatable workflow that actually performs.

This matters because people are trying to reach three very different outcomes with AI — and they often don’t realize which one they need:

1. Collaborative AI — You drive the process, AI contributes. Co-writing a document, brainstorming a strategy, and reviewing code together. The AI is a capable partner, but you’re steering.

2. Deterministic Automation — A repeatable process that AI executes reliably with minimal supervision. Formatting reports, processing forms, and generating standardized communications. You define the rules once; AI follows them every time.

3. Autonomous Agents — AI plans and executes multi-step work independently. Research pipelines, monitoring systems, and multi-stage content production. You set the goal; AI figures out the steps.

Without a structured approach to get there, most people default to option 1 — chatting back and forth — even when what they actually need is option 2 or 3. They’re using AI as a conversation partner when they should be using it as an engine.

The Business-First AI Framework

I built this framework because I kept watching the same failure mode play out.

People would come to my cohorts with real workflows they wanted to automate. Good ideas, real pain points. But they had no standardized way to articulate what the workflow does and why each step matters — at the level of detail AI needs to execute it. There was no business methodology for translating “here’s what my team does” into a specification that an AI could work from.

So they’d skip straight to the how. Open ChatGPT, start writing prompts, iterate for hours. The problem isn’t that they lacked technical skill. The problem is they were trying to build before they’d defined what they were building. It’s like writing code before you’ve written requirements — you’ll produce something, but it won’t be what you actually need.

The Business-First AI Framework puts the what and the why first. Three steps, and the order matters.

Step 1 — Discover.

Audit your workflows and identify which ones are candidates for AI.

Before you can apply AI to anything, you need to know where it fits. Step 1 is a structured audit that scans your role, responsibilities, recurring tasks, pain points, and multi-step processes — then produces a prioritized list of opportunities categorized as Collaborative AI, Deterministic Automation, or Autonomous Agent.

The key insight: don’t start with the technology and ask “where should we use it?” Start with your workflows and ask, “Which of these would benefit most from AI?”

Most people discover 5-15 opportunities they’d never considered. The audit surfaces patterns you miss in the daily grind.

Step 2 — Deconstruct.

Break the chosen workflow into atomic steps.

This is the step everyone skips. And it’s the most important one.

You describe your workflow — rough and incomplete is fine — and then systematically decompose each step using five questions:

1. Discrete steps — Is this actually one step, or multiple steps bundled together?

2. Decision points — Are there if/then branches, quality gates, or judgment calls?

3. Data flows — What goes in? What comes out? Where from and where to?

4. Context needs — What documents, files, or reference materials does this step require?

5. Failure modes — What happens when this step fails?

A workflow that starts as 5-8 rough steps typically expands to 12-20 refined steps after this process. That expansion is the point — it surfaces every hidden sub-step, every implicit decision, every assumption you’d internalized so deeply you forgot it was there.

Remember the Google Gem student? Had she run her pipeline review process through these five questions first, she would have seen immediately that her instructions lacked decision logic. The scoring rubrics were there, but the workflow connecting them — the sequence, the branching, the escalation criteria — wasn’t described at the level of detail the AI needed to execute it.

The deliverable from Step 2 is a Workflow Definition—a structured Markdown file that captures every step in detail. It’s platform-agnostic. It works whether you’re building for ChatGPT, Claude, Gemini, or anything else.

Step 3 — Build.

Design the AI implementation, then construct it.

Step 3 takes your Workflow Definition and turns it into a working AI workflow through three parts:

• Design — Choose your execution pattern. A simple prompt? A skill-powered prompt with reusable routines? A single autonomous agent? A multi-agent pipeline? The right choice depends on what your workflow actually needs — not on what sounds most impressive.

• Construct — Build only what your pattern requires. Map each step to the right AI building block: prompts, context documents, skills, agents, or tool connections. The Building Block Spec from Design tells you exactly what to create and in what order.

• Run — Execute the workflow on a real scenario. Evaluate. Iterate. Most workflows require 2-4 rounds of refinement before producing reliably good output.

The output is a Baseline Workflow Prompt you can paste into any AI tool and run immediately. For more complex workflows, you get agent configurations and skill definitions that you can deploy to Claude or adapt for other platforms.

Why Deconstruct Changes Everything

Two patterns I see repeatedly:

The “I described the what, not the how” pattern. Like the Google Gem student. People describe the outcome they want — “review my pipeline deals and score them” — without describing the process at the level of detail AI needs to actually do it. Deconstruction forces you to articulate every step, which reveals what was implicit.

The “skip to the tool” pattern. People start iterating on prompts immediately. They spend hours refining wording, when the real problem is that they never defined what “done” means at each step. Deconstruction front-loads that thinking, so the build phase goes faster.

When people see the five-question framework applied to their own workflow, two things click:

First, they understand how to go about it. The five questions are a methodology—not a vague “think harder about your process” — but a structured interview that systematically surfaces detail. It replaces guessing with a repeatable approach.

Second, they see the level of detail required for AI to orchestrate something specific to their business. Not generic instructions anyone could write, but the particular decision logic, context documents, quality criteria, and failure handling that make a workflow theirs.

This is the moment the framework earns trust. Not when I explain it — when they use it on their own work and see the difference in output quality.

Try It Right Now

You can start Step 1 — Discover — right now. Go to the Discover Workflows page on the Hands-on AI Cookbook:

handsonai.info/business-first-ai-framework/discover

The page gives you two options:

• Any AI tool — Copy the prompt template and paste it into ChatGPT, Claude, Gemini, M365 Copilot, or whatever you use. It runs a structured audit of your workflows and produces a categorized report of opportunities.

• Claude platform — If you use Claude Code, Cowork, or Claude.ai, install the Business-First AI plugin (/plugin install business-first-ai@handsonai) and the skill runs interactively with file-based deliverables.

Either way, you’ll walk through a guided conversation that takes about 20 minutes. Most people discover 5-15 opportunities they’d never considered. Pick the one that excites you most — that’s your candidate for Step 2.

Already know what you want to build? Skip straight to Step 2 — the step everyone misses:

handsonai.info/business-first-ai-framework/deconstruct

Describe your workflow — rough and incomplete is fine — and the prompt walks you through the five-question deep dive. In 15-25 minutes, you’ll have a Workflow Definition that captures every step, decision point, and failure mode. This is the part that transforms “I want AI to do X” into something AI can actually execute.

What the output actually looks like

To make this concrete, I ran my own Content Calendar Planning workflow through the framework — the process I use every Sunday to plan two weeks of content across LinkedIn, Substack, X, and YouTube.

“I plan content on Sundays” became 10 refined steps across four phases, with decision points, data flows, failure modes, and a dependency map. The framework then produced an AI Building Block Spec that classified each step on the autonomy spectrum, identified four reusable skills, and recommended a build order — starting with the conversational planning flow (no infrastructure needed) and layering in database skills incrementally. Finally, it generated a ready-to-run Baseline Workflow Prompt that orchestrates the entire 10-step process as a collaborative conversation.

See the full example with all three deliverables:

Content Calendar Planning — Full Worked Example

The page shows the complete Workflow Definition, AI Building Block Spec, and Baseline Workflow Prompt — everything the framework generated for a single real workflow, from decomposition through to a working prompt you could paste into any AI tool.

Three Ways to Use the Cookbook

Everything I’ve described — the framework, the prompts, the worked examples — lives in the Hands-on AI Cookbook, an open-source repository anyone can use. Here’s how to get started, depending on how you work:

1. Browse and copy. Visit handsonai.info in your browser. Every framework step has a ready-to-use prompt template. Copy it, paste it into ChatGPT, Claude, Gemini, M365 Copilot — whatever you use. No account required. No vendor lock-in.

2. Connect via MCP (recommended). If your AI tool supports MCP (Model Context Protocol), you can bring the entire cookbook knowledge base directly into your conversations. Add this URL as a connector and your AI assistant can search, read, and reference any cookbook page on your behalf — framework guides, building block definitions, worked examples, everything:

MCP server URL: https://mcp.handsonai.info/mcp

This works in Claude, ChatGPT, Cursor, VS Code, and any MCP-compatible tool. Setup takes about 30 seconds. Once connected, just ask your AI: “Search the Hands-on AI Cookbook for how to deconstruct a workflow” — and it pulls the relevant guide directly into your conversation. No tab-switching, no copy-pasting.

Setup instructions for every supported tool

3. Install the plugin (Claude users). For the full interactive experience in Claude Code or Cowork, install the Business-First AI plugin:

/plugin install business-first-ai@handsonai

The plugin implements all three framework steps as executable skills. Describe what you need — “Help me deconstruct my weekly reporting process” — and the framework runs interactively, saving deliverables as structured files you can iterate on.

Everything is plain-text Markdown. No compiled code, no black boxes. Read the source, understand how it works, and adapt it for your own workflows.

Your Turn

You have a workflow right now that’s costing you hours. You know which one it is — you thought of it while reading this.

Don’t open ChatGPT and start prompting. That’s the trap.

Go to the Discover page and run the audit. Or if you already know the workflow, go straight to Deconstruct and break it down. Twenty minutes of structured decomposition will save you hours of aimless iteration.

What workflow are you going to deconstruct first? Reply and tell me. I read every response and use your feedback to improve the cookbook — your sticking points become new guides, better prompts, and worked examples that help everyone.

Know someone stuck in the idea-to-tool gap? Forward this to them.

— James

P.S. If you want structured guidance through all three steps with a cohort of peers, I teach two live courses: Hands-on Agentic AI for Leaders — for leaders and professionals applying AI to their business workflows using popular tools like ChatGPT, Claude, Gemini, and M365 — and Claude and Claude Code for Builders — for people building workflows and apps on the Claude platform. Every student walks out with at least one fully deconstructed, working AI workflow. See upcoming cohorts at courses.handsonai.info

TL;DR:

• Most people are stuck between “I’ve tried ChatGPT” and “I’m getting real results.” The gap isn’t tools — it’s a system.

• I built the Hands-on AI Cookbook (handsonai.info) — a free, open-source resource for turning AI ideas into production.

• It covers a 3-step framework, six use cases where AI creates value, six building blocks that work across Claude, ChatGPT, Gemini, and M365 Copilot, and ready-made tools you can install with a single command.

• No coding required for the strategy content. Builder content scales from foundational to advanced.

• It’s free, open-source, and always evolving. Visit handsonai.info.

If you have a business workflow you want to make AI-first, the last thing you need is another slick demo. You need clarity — what are the building blocks, how do they fit together, and how do you go from idea to production?

That’s what the Hands-on AI Cookbook is. Complex AI topics distilled into clear frameworks, building blocks, and practical tools so builders can stop experimenting and start operationalizing.

And by builders, I don’t mean developers. If you’re a leader, entrepreneur, or professional with a business idea and the willingness to get hands-on, you’re a builder.

Why I Built This

After working with 6,000+ executives at Berkeley Haas through enterprise AI programs and hands-on cohorts, I kept seeing the same pattern. People would show up excited about AI. They’d tried the tools. They’d written some prompts. But they couldn’t close the distance between experimenting and executing.

The gap wasn’t about prompts. It was about thinking. People didn’t need another “50 prompts for marketers” listicle. They needed a framework for figuring out where AI fits in their work and how to build it into their workflows — systematically, not randomly.

So I started building. Openly, publicly, on GitHub. Because I believe AI knowledge should be free and open to everyone.

Here’s the thing — we all have a finite amount of time. The best gift I can give anyone is time and clarity to maximize their impact. My hope is that this cookbook shortens the distance between where you are and what you’re capable of — bringing the future forward, so you can spend your time on the work that actually matters.

The result is handsonai.info — a living, open-source cookbook with everything I’ve learned about applied AI, organized so you can actually use it.

What’s Inside

The cookbook is built in four layers. Each one takes you deeper.

Layer 1: A Framework for Going from Idea to Production

Most people have a sense of which workflows could benefit from AI. The hard part is going from that idea to something that actually runs — reliably, repeatedly, in the real world.

The Business-First AI Framework guides you through that entire journey:

1. Discover — Run a structured audit of your workflows to identify where AI creates the most value

2. Deconstruct — Break those workflows into discrete steps and map each one to AI building blocks

3. Build — Turn that analysis into a working AI workflow, ready for production

You don’t need to be technical to use any of this. The framework works on paper, in a conversation with any AI tool, or with installable plugins that walk you through it step by step. The Discover step takes 20 minutes and produces a prioritized list of AI opportunities — a tangible output in one sitting.

Layer 2: Use Cases — Where AI Creates Value

The cookbook includes six use case primitives — Content Creation, Research, Coding, Data Analysis, Ideation & Strategy, and Automation — adapted from OpenAI’s analysis of 600+ enterprise AI deployments. These primitives describe what type of work AI actually does in the real world. They give you a classification system so you can look at any workflow and immediately know which category it falls into and which building blocks to reach for.

Layer 3: The Building Blocks

Every AI workflow — from a single prompt to a multi-agent pipeline — is assembled from six building blocks:

• Prompt — Instructions you give the AI

• Context — Background knowledge the AI needs (your data, your docs, your domain)

• Project — A persistent workspace that holds everything together

• Skill — A reusable routine the AI can invoke on demand

• Agent — An autonomous AI that plans and executes multi-step work

• MCP — A connector that lets AI access external tools and data

These are platform-agnostic concepts. The cookbook maps each block across Claude, ChatGPT, Gemini, and M365 Copilot in a single comparison table. So instead of learning four different systems, you learn the six blocks once and apply them everywhere.

This is the vocabulary that makes AI adoption repeatable. Once you understand building blocks, you can look at any workflow and say: “This needs a skill with context and an MCP connection” — regardless of which platform you’re using.

Layer 4: Accelerators — Domain Expertise You Can Install

As I learn, I codify that knowledge into AI agents and skills — pre-built tools you can install in one command to accelerate your own learning and implementation. This is an evolving library, not a finished product.

The cookbook’s Plugin Marketplace is where these live. The Business-First AI plugin alone packages 8 agents, 6 skills, and 3 prompts that implement the entire Business-First AI Framework as executable tools. Tell it, “help me find where AI can improve my workflows,” and it runs a structured audit. Tell it “deconstruct my client onboarding process,” and it walks you through the full analysis.

There’s also a Builder Stack Setup Guide. This is where I see people get stuck — the tools for building and running real AI workflows are unfamiliar to most people. Terminal, Git, AI coding CLIs — many of these will be new. But they’re what unlock the ability to go from idea to production. The guide walks you through 7 steps, roughly 75 minutes, with checkboxes to track your progress. One VP of Product used it to go from zero terminal experience to a fully configured AI builder stack in a single afternoon.

And the cookbook is full of patterns, walkthroughs, and direct answers to the questions that come up most often — from “what is a system prompt?” to “how do I schedule an AI agent to run automatically?”

Who It’s For

Anyone stuck between “experimenting” and “executing” — leaders auditing where AI fits, entrepreneurs building their first AI-powered workflow, professionals who want to get hands-on and take an idea all the way to production.

No coding experience required for the strategy content. The builder content scales from first-time terminal users to teams orchestrating multi-agent pipelines.

Go Build Something

In a world changing this fast, there are no shortcuts. You have to get hands-on with the tools. You have to touch them, experiment, and develop your own sense of what’s possible.

I’ve trained CEOs and C-suite leaders on the same tools covered in this cookbook. Every one of them came out with greater clarity — not because AI gave them answers, but because getting hands-on calibrated their mindset to what’s actually possible.

That’s my challenge to you: start small. Build the muscle of a business-first approach to AI. Value creation isn’t just the power of the tools — it’s your ability to innovate from within and evolve what you’re capable of. That inner transformation is what lets you, together with AI, bring out your full potential to make your ideas come to life.

The Hands-on AI Cookbook is free, open-source, and always evolving.

Start here: Visit handsonai.info and run the Discover step. In 20 minutes, you’ll have a prioritized list of AI opportunities for your team — ranked by impact and ready to act on.

If it helps you, share it with someone who’s stuck between experimenting and executing. That’s exactly who it’s built for.

Stay curious and hands-on,

James

P.S. Know someone who keeps saying “I need to figure out this AI stuff”? Forward them this post. The cookbook is the fastest way to go from curious to capable.

A leader wants to automate prospect research. Or customer outreach. Or content creation. They’ve done the process hundreds of times. They know it works. But when they try to apply AI?

They get stuck.

Not because the AI isn’t capable. But because they’ve never had to explain their process with the kind of precision an AI needs. The workflow lives in their head as intuition—not as clear, repeatable steps.

On Friday, I hosted a Lightning Lesson where we tackled this together. Over 340 leaders and professionals joined me to walk through how to take something you know intimately and break it down so AI can actually execute it.

No theory. Just a real workflow, deconstructed step by step.

The Challenge: Getting What’s in Your Head Into Structure

Think about something you do regularly in your business. Maybe it’s qualifying leads. Analyzing feedback. Preparing reports.

Now imagine explaining every single step to someone who’s smart but has never done it before. Not just the what—the how, the why, the decision points, the nuances.

Suddenly it’s not so simple, right?

That’s the gap. You have expertise that’s second nature. AI needs explicit instructions. Deconstruction is how you bridge that gap.

And honestly? The process of breaking it down often reveals things you didn’t even realize you were doing—which makes your process better, with or without AI.

What We Built Together

In this session, I walked through a workflow I use for LinkedIn prospect research. Nothing fancy—just a practical business process:

• Start with a buyer persona (the kind of prospect you want to find)

• Search LinkedIn for people who match that profile

• Evaluate each prospect against specific criteria

• Generate personalized engagement recommendations

• Output everything in a structured format

The interesting part isn’t the workflow itself. It’s how we approach building it.

Key Concepts You Can Apply Immediately

1. The “What/Why vs. How” Principle

You shouldn’t be writing detailed AI instructions from scratch. That’s the old way.

Instead, you define the business outcome and sketch high-level steps. Then let AI generate the detailed execution instructions.

You bring domain expertise. AI brings execution precision. Stay in your lane.

2. Meta-Prompting: Let AI Write AI Instructions

Here’s the actual technique:

“You are an expert workflow designer and prompt engineer. Please write a prompt for this scenario. The outcome is [your goal]. Here are the high-level steps: [your steps]. Now write the detailed instructions.”

Let the model craft the “how” while you focus on the strategic “what and why.”

I demonstrate this live in the session—you’ll see how much better the AI-generated instructions are than what most people write manually.

3. Skills vs. MCPs: Understanding the Difference

This came up multiple times in Q&A because it’s genuinely confusing.

Skills teach Claude how to do something. Procedural knowledge. “Here’s how to write a LinkedIn post in my style.”

MCPs (Model Context Protocol) give Claude access to something. Tool connectivity. “Here’s how to read from and write to my Notion database.”

They work together. Skills provide the methodology. MCPs provide the capability.

4. Build a Workflow Registry

Don’t just build workflows ad hoc. Create a system.

I show my Notion setup where every workflow is documented with:

• Name and business process assignment

• Description and expected outcome

• Trigger conditions

• The actual steps

• Links to AI assets (prompts, personas, templates)

• Status tracking

This becomes your institutional knowledge. Your competitive moat.

5. The Clarity Test

Here’s how you know if a workflow is ready to automate:

Can you explain it clearly enough that a smart person who’s never done it could execute it successfully?

If not, you’re not ready for AI yet. The work is in the deconstruction, not the automation.

6. Create Reusable AI Assets

In the demo, I use a buyer persona stored as a markdown file. It’s an AI asset I can plug into multiple workflows—prospect research, email outreach, and content creation.

Think in building blocks. What pieces of knowledge or context can you document once and reuse everywhere?

Questions That Came Up

The Q&A was where things got practical. People asked questions like:

“Should I design my Notion database first, or let Claude do it?” (Start simple with what makes sense to you, then let Claude optimize based on your actual workflow)

“When do I need a Skill versus just a good prompt?” (Skills when you’re doing the same thing across multiple workflows and want consistent execution)

“How detailed should my workflow steps be?” (Detailed enough that the AI knows what to do, but not so prescriptive that you lose flexibility)

These weren’t hypothetical. These were people actively working through this in their businesses, hitting real obstacles, finding real solutions.

Why This Matters Right Now

We’re past the “playing around with ChatGPT” phase. The tools are ready. The question isn’t whether AI can help your business—it’s whether you can articulate your processes clearly enough to take advantage of it.

The leaders who figure this out aren’t necessarily the most technical. They’re the ones who can think operationally, break down their expertise, and build systems that scale.

That’s what this Lightning Lesson is about. Not the technical wizardry (though we cover that too). The mindset shift from “What can AI do?” to “What do I need done, and how do I break it down?”

Want to Go Deeper?

This Lightning Lesson gives you the approach. If you want to actually build these systems with hands-on guidance and expert feedback, I’m running two cohort courses:

Claude and Claude Code for Builders – Starts Tomorrow (January 26)

This course is primarily for “builders” - business people who want to go deep on Claude’s capabilities, Claude Code for agentic workflows, and building a prototype application (e.g., website)

25% founder discount for this inaugural cohort.

View syllabus and enroll →

Hands-on Agentic AI for Leaders – Next cohort starts February 2

This is for business leaders and non-technical builders who want to move from experimentation to actually deploying AI in their operations. We build real workflows, deploy them, and develop the literacy to lead AI transformation.

Rated 4.8/5. Over 250 students trained.

View syllabus and enroll →

The best AI implementation starts with clear thinking about your business, not with fancy prompts.

Watch the session. Pick one workflow. Break it down.

That’s where real progress starts.

— James

Subscribe now

Daily Nugget

“The easiest way for us to gain happiness is to learn how to want the things we already have.” - A Guide to the Good Life by William B. Irvine

Hey, everybody. It’s Monday, January 19th, and I want to share something with you.

I love books. Every day, I read from The Daily Stoic by Ryan Holiday and The Daily Laws by Robert Greene. A lot of times, we need reminders of really important things—basic things, even—but we need to hear them again. When I find nuggets, I want to share them with you.

One book that helped me through a difficult period years ago is The Guide to the Good Life. It’s based on Stoic philosophy, and there’s a chapter in here that I keep coming back to. It’s about hedonic adaptation—this very human tendency to be insatiable.

The Satisfaction Treadmill

Here’s what the author says:

“We humans are unhappy in large part because we are insatiable.”

You know this treadmill. We achieve something we’ve worked hard for, and almost immediately, we want more. There’s nothing wrong with being successful or wanting to grow. But it’s when that pursuit starts controlling our lives and making us unhappy that we need to pause.

The author explains it this way:

“We are unhappy when we detect an unfulfilled desire in ourselves. We work hard to fulfill this desire in the belief that on fulfilling it, we will gain happiness. The problem, though, is that once we fulfill a desire for something, we adapt to its presence in our life, and as a result, we stop desiring it—or at any rate, we don’t find it as desirable as we once did. We end up just as dissatisfied as they were before fulfilling the desire.”

Your job. Your relationship. Your home. The things we once dreamed of having, we now take for granted.

The Solution

So what’s the answer?

The author writes:

“One key to happiness is to forestall this adaptation process. We need to take steps to prevent ourselves from taking for granted, once we get them, the things we worked so hard to get.”

And here’s the nugget—I have this highlighted because it’s so true:

“The easiest way for us to gain happiness is to learn to want the things we already have.”

This advice is easy to state. The trick is putting it into practice. How do we convince ourselves to want the things we already have?

Your Assignment Today

I talk to a lot of people who are bitching and complaining about things that, frankly, are irrelevant. I think if we really embrace this idea of loving the things we already have, we’ll not only be happier—we’ll probably be less stressed as we go throughout our days.

So here’s my challenge:

Take a pause and think about all the amazing things you have in your life. Your health. Your family. Your friends. Really embrace those and love them.

And ask yourself: Is there something you’re pursuing that’s driving you astray because you feel unsatisfied? Because you’re insatiable for that thing?

This was the nugget I reminded myself of today. I’m hoping this short reflection can give you a dose of happiness, too.

What’s one thing you already have that you could appreciate more today? Hit reply—I’d love to hear from you.