Tygart Media

Tag: Claude Code

  • The Exit Protocol: The Section of Your Digital Life You Haven’t Written Yet

    The Exit Protocol: The Section of Your Digital Life You Haven’t Written Yet

    Every tool you enter, you will someday leave. Most operators don’t plan the exit until the exit is already happening. This is the protocol written before the catastrophe, not after.

    Target keyword: digital exit protocol Secondary: tool exit strategy, digital legacy planning, AI tool offboarding, operator continuity planning Categories: AI Hygiene, AI Strategy, Notion Tags: exit-protocol, ai-hygiene, operator-playbook, continuity, digital-legacy

    Every tool you enter, you will someday leave.

    You don’t know which exit you’ll face first. The breach that ends a Tuesday. The policy change that ends a vendor relationship in thirty days. The voluntary migration to something better. The one nobody plans for — the terminal one, where you’re gone or incapacitated and someone else has to figure out how your digital life was organized.

    The cheapest time to plan any of those exits is at the moment of entry. The most expensive time is the moment the exit is already underway.

    Most operators never write this section of their digital life. They enter tools. They stack data. They accumulate credentials. They build automations that depend on twelve other automations that depend on accounts they don’t remember creating. And if you asked them today, “if this specific tool vanished tomorrow, what happens?” — the honest answer is usually I don’t know, I’ve never looked.

    That’s the section this article is about. The exit protocol. The will-and-testament layer of digital life, written before the catastrophe rather than after.

    I’m going to describe the four exits every operator faces, the runbook for each, and the pre-entry checklist that keeps the whole stack from becoming a trap you can’t get out of. None of this is theoretical — it’s the protocol I actually run, cleaned up enough to be useful to someone else building their own version.

    Why this matters more in 2026 than it did in 2020

    For most of the personal-computing era, “exit” meant closing a browser tab. You used a tool, you were done, you left. The consequences of not planning the exit were small because the surface was small.

    That’s not the shape of digital life in 2026. The operator running a real business now sits on top of a stack that typically includes:

    • A knowledge workspace (Notion, Obsidian, or similar) holding years of operational state
    • An AI layer (Claude, ChatGPT, or similar) with memory, projects, and connections to your workspace
    • A cloud provider account running compute, storage, and services
    • Web properties with published content and user data
    • Scheduling, CRM, and communication tools with their own data stores
    • A password manager sitting behind all of it
    • An identity root (usually a Google or Apple account) holding the keys

    Any one of these can end. By breach. By policy change. By price increase you can’t absorb. By vendor shutdown. By personal rupture that isn’t business at all. By death, which is the scenario nobody wants to write about and exactly the one that makes the planning most valuable.

    And every piece is entangled with the pieces above and below it. Your Notion workspace references your Gmail. Your Gmail authenticates your cloud provider. Your cloud provider runs the services your web properties depend on. Your password manager holds the recovery codes for everything. The stack is a single living system with many failure modes, and the only version of “exit planning” that works is the one that treats the stack as a whole.

    The seven questions

    Before you can plan an exit, you need to be able to answer seven questions about every tool in your stack. If you can’t answer them, the exit plan is a fiction.

    1. What lives there? Data, credentials, intellectual property. Not “everything” — specifically, what is in this tool that doesn’t exist anywhere else?

    2. Who else has access? Human collaborators. Service accounts. OAuth connections. API keys you gave out and forgot about. Every form of access is a potential inheritance path.

    3. How does it get out? The export surface. Format. Cadence. Whether the export includes everything or just some things. Whether the export requires the UI or has an API.

    4. What deletes on what trigger? Vendor retention policies. Your own rotation schedule. End-of-engagement deletion for client work. What happens to data if you stop paying.

    5. Who inherits what? Family. Team. Clients. The answer is usually “nobody, by default” — and that default is the whole problem.

    6. How do downstream systems keep working? If this tool ends, what else breaks? What continuity can be preserved without handing over live credentials to somebody who shouldn’t have them?

    7. How do I know the exit still works? Drill cadence. When was the last time you actually exported the data and opened the export on a clean machine to verify it was intact?

    If you answer these seven questions for every tool in your stack, you will find things that surprise you. Credentials that have been in live rotation for three years. Tools whose “export” button produces a file that can’t be opened by anything else. Dependencies on your Gmail that would make inheritance a nightmare. That’s fine — finding those things is the point. You can’t fix what you haven’t looked at.

    The four exit scenarios

    Every exit fits into one of four shapes. The shape determines the runbook. Getting this taxonomy right is what lets the rest of the protocol be specific.

    Sudden: breach or compromise

    The credential leaked. The account got taken over. A vendor breach exposed data you didn’t know was even there. Minutes matter. The goal is to contain the damage, not to plan the migration.

    Forced: policy or shutdown

    The vendor killed the product. The terms changed in a way you can’t live with. The price went up by an order of magnitude. Days to weeks, usually. The goal is to export cleanly and migrate to a successor before the window closes.

    Terminal: death or incapacity

    You are gone or can’t operate. Someone else has to keep things running or wind them down cleanly. This is the scenario most operators never plan for, and it’s the one with the highest cost if the plan doesn’t exist.

    Voluntary: better option or done

    You chose to leave. Migration to a new tool. End of a client engagement. Lifestyle change. Weeks to months of runway. The goal is a clean handoff with no orphan state left behind.

    Each of these has its own runbook. Running the wrong one for the situation is a common failure — treating a forced shutdown like a voluntary migration wastes the window; treating a breach like a forced shutdown fails to contain the damage.

    Runbook: Sudden

    The situation is: something leaked or got taken over. You find out either because a monitoring alert fired or because something visibly broke. Either way, the clock started before you noticed.

    1. Contain. Pull the compromised credential immediately. Rotate the key. Revoke every token you issued through that credential. Sign out of every active session. This is the first ten minutes.

    2. Scope. List every system the credential touched in the last thirty days. Assume the blast radius is wider than it looks — adjacent systems often share trust in ways you forgot about. The goal is to understand what the attacker could have done, not just what they did do.

    3. Notify. If client or customer data is in scope, notify according to your contracts and any applicable law. Today, not tomorrow. Breach disclosure windows are tight and getting tighter; the legal risk of delay is usually worse than the embarrassment of early notification.

    4. Rebuild. Issue a new credential. Scope it to minimum permissions. Never restore the old credential — the temptation to “reuse it once we figure out what happened” is how re-compromise works.

    5. Postmortem. Write it the same week. Not a blameless postmortem for PR purposes; a real one, for your own internal knowledge. What was the failure mode? What signal did you miss? What changes to the protocol would have caught it earlier? The postmortem is the only way the Sudden scenario makes the rest of the stack safer instead of just more anxious.

    Runbook: Forced

    A vendor is shutting down the product, changing the terms in an unacceptable way, or pricing you out. You have some window of runway — days to weeks — before the tool goes dark.

    1. Triage. How long until the tool goes dark? What is the critical-path data — the stuff that doesn’t exist anywhere else? Separate that from everything else.

    2. Export. Run the full export immediately, even before you’ve decided what to migrate to. A cold archive is cheap; a missed export window is permanent. This is the most common failure mode of the Forced scenario — operators wait until they’ve chosen a successor before exporting, and the window closes.

    3. Verify. Open the export on a clean machine. Not the one you usually work on. A clean machine, with no existing context, so you can confirm that the export is actually usable without the source system. Many “export” features produce files that look complete but reference data that only exists in the source system.

    4. Choose a successor. Match on data shape, not feature list. The data is the asset; the UI is rentable. A successor tool that imports your data cleanly but doesn’t have every feature you liked is a better choice than one with more features and a lossy import path.

    5. Cutover. Migrate. Run both systems in parallel for one full operational cycle. Then decommission the old one. The parallel cycle is where you discover what the export missed.

    Runbook: Terminal

    This is the runbook most operators never write. Writing it is the whole point of this article.

    If you are gone or can’t operate, someone else needs to know: what’s running, who depends on it, and how to either keep things going or wind them down cleanly. The default state — no plan — is a nightmare for whoever inherits the problem.

    The Terminal runbook has five components, and each one can be written in an evening. Don’t let the scope of the topic talk you out of writing the simple version now.

    Primary steward. One named person who becomes the point of contact if you can’t operate. Usually a spouse, partner, or trusted family member. They don’t need to understand how the stack works. They need to know where the instructions are and who the operational steward is.

    Operational steward. A named professional who can keep systems running during the transition. For technical infrastructure, this is typically a trusted developer or consultant who already knows your stack. For legal and financial, this is an attorney and accountant. Name them. Have the conversation with them before you need it.

    What the primary steward gets immediately. A one-page document describing the situation. Access to a password manager recovery kit. A list of active clients and the minimum needed to pause operations gracefully. Contact information for the operational steward. Nothing more than this. Specifically, they do not get live admin credentials to client systems, live cloud provider keys, or live AI project memory — those are inheritance paths that go through the operational steward or the attorney, not into a drawer.

    Trigger documents. A signed letter of instruction, stored with the attorney and copied to a trusted location at home. It references the operational runbook by URL or location. It names who is authorized to do what, under what conditions, for how long.

    Digital legacy settings. Most major platforms have inactive-account or legacy-contact features built in. Configure them. Google has Inactive Account Manager. Apple has Legacy Contact. Notion has workspace admin inheritance. Configuring these is fifteen minutes per platform and they do real work when they’re needed.

    Crucial: do not store live credentials in a will. Wills become public record in probate. The recovery path is a letter of instruction pointing at a password manager whose emergency kit is held by a trusted professional, not credentials written into a legal document.

    Runbook: Voluntary

    You chose to leave. Good. This is the least stressful exit because you have runway, you chose the timing, and the data is not under siege.

    1. Announce the exit window. To yourself. To your team. To any client whose work touches this tool. Set a specific date and commit to it.

    2. Freeze net-new. Stop adding data to the system being retired. New data goes to the successor; old data stays put until migration.

    3. Export and verify. Same as the Forced runbook. Full export, clean machine, integrity check.

    4. Migrate. Move data to the successor. Re-point automations, integrations, and any external references. Update documentation and internal links.

    5. Archive. Keep a cold copy of the old system’s export in durable storage, labeled with the exit date. Do not delete the original account for at least ninety days. Things you forgot about will surface during that window and you will want the ability to recover them.

    6. Decommission. Revoke remaining keys. Cancel billing. Close the account. Remove the tool from your password manager. Update any documentation that still mentioned it.

    The drill cadence (the thing that actually makes the protocol real)

    A protocol nobody practices is a protocol that doesn’t exist. The only way to know your exit plan works is to test it, repeatedly, on a schedule that makes failures cheap.

    Quarterly — thirty minutes. Pick one tool. Run its export. Open the export on a clean machine. Log the result. If the export is broken, fix it now, while there’s no emergency. Thirty minutes, four times a year. That’s two hours of investment to know your stack is actually recoverable.

    Semi-annual — two hours. Rotate every credential in the stack. Prune AI memory down to what’s actually load-bearing. Re-read the exit protocol end-to-end and update anything that’s drifted out of date. The credential rotation alone catches more problems than any other single practice in the hygiene layer.

    Annual — half a day. Run a full Terminal scenario dry run. Sit with your primary steward. Walk through the letter of instruction. Verify that your attorney has the current version. Update the digital legacy settings on every major platform. Confirm that the operational steward is still willing and available.

    These cadences add up to roughly eight hours of exit-related work per year. Eight hours against the cost of a stack that could otherwise catastrophically collapse on the worst day of your life. It’s a trade you want to make.

    The pre-entry checklist

    The most important protocol move is the one that happens before the tool enters the stack at all. Every new tool you adopt creates an exit you’ll eventually need. Planning it at entry is radically cheaper than planning it in crisis.

    Before adopting any new tool, answer these questions:

    What is the export format, and have you opened a sample export? If the vendor doesn’t offer export, or the export is a proprietary format nothing else reads, the tool is a data trap. Accept the tradeoff knowingly or pick a different tool.

    Is there an API that would let you back up without the UI? UI-only exports scale poorly. An API you can call on a schedule gives you durable backup without depending on the vendor to maintain the export feature.

    What is the vendor’s retention and deletion policy? How long does data stick around after you stop paying? What happens to the data if the vendor is acquired? What’s their policy on third-party data processing?

    What credentials or tokens will this tool hold, and where do they rotate? A tool that holds an OAuth token to your primary email is a very different risk profile from one that holds only its own password. Inventory the credentials at entry.

    If the vendor raises the price ten times, what is your Plan B? This question sounds paranoid. Vendors raise prices tenfold more often than you’d expect. Having a Plan B in mind at entry is very different from scrambling for one at the three-week mark of a forced migration.

    If you died tomorrow, how would someone downstream keep this working or shut it down cleanly? If the answer is “they couldn’t,” you haven’t finished adopting the tool. Keep this in mind particularly for anything where you’re the only person with access.

    Does this tool belong in your knowledge workspace, your compute layer, or neither? Not every new tool earns a place in the stack. Some are better rented briefly for a specific project and then left behind. The pre-entry moment is when you decide which tier this tool lives in.

    Seven questions. Fifteen minutes of thinking. The return on those fifteen minutes is everything you don’t have to untangle later.

    What this protocol is not

    Three clarifications to close the frame correctly.

    This isn’t paranoid. It’s ordinary due diligence applied to a category of risk that most operators have not caught up to yet. Every legal entity has a wind-down plan. Every serious business has a disaster recovery plan. The digital life of a one-human operator running a real business has the same obligations; it just hasn’t had them named before.

    This isn’t purely defensive. The exit protocol produces upside beyond catastrophe avoidance. The discipline of knowing what’s in every tool, who has access, and how to get data out makes the whole stack more coherent. Operators who run this protocol find themselves making cleaner choices about new tools, which means less sprawl, which means less hygiene debt. The protocol pays rent every month, not just when things break.

    This isn’t a one-time project. It’s a standing practice. The stack changes. Tools enter. Tools leave. Credentials rotate. Family situations evolve. The protocol is never finished; it’s maintained. That’s why the drill cadence matters. The one-time-project version of this decays into fiction within a year. The standing-practice version stays alive because it gets touched regularly.

    The one thing I’d want you to walk away with

    One sentence. If you only remember one, let it be this:

    Every tool you enter, you will someday leave — and the cheapest time to plan the leaving is at entry.

    If that sentence changes how you approach the next tool you consider adopting, it changed the shape of your stack. Not in a dramatic way. In the small, compounding way that good hygiene always works.

    The operators I know who have survived the roughest exits — the breaches, the vendor shutdowns, the personal emergencies — all share one thing in common. They planned the exit before they needed it. Not because they expected the catastrophe. Because they understood that the exit was coming, eventually, in some form, for every single thing they’d built, and that planning it in calm was radically cheaper than planning it in crisis.

    The exit is coming. For every tool. For every account. For every service. For every credential. Eventually.

    Plan it now.

    FAQ

    What’s the most important piece of this protocol if I only have an hour to spend?

    Write the one-page Terminal scenario letter. Name your primary steward. Name your operational steward. Put the password manager emergency kit in a place they can find. That one hour, invested now, is the highest-leverage thing in the entire protocol.

    I’m a solo operator with no family. Does the Terminal runbook still apply?

    Yes, and it’s more important for you than for operators with a family who would step in by default. You need an operational steward — a professional or trusted peer — who can wind things down if you can’t. Without that named person, client work will orphan in a way that creates real harm for people who depended on you.

    How often should I rotate credentials?

    Every six months at a minimum for anything load-bearing, immediately on any suspected compromise, and whenever someone with access leaves a collaboration. The Quarterly drill cadence catches stale credentials on a regular rhythm; full rotation on Semi-annual catches the long-tail.

    What about AI-specific exits — Claude, ChatGPT, Notion’s AI?

    Treat AI memory as a liability to be pruned, not an asset to be preserved. Export what’s genuinely valuable (artifacts, specific conversations you want as reference), then prune aggressively. AI memory that sits around accumulating is increasing your blast radius in every other exit scenario. The hygiene move is minimal memory, not maximum memory.

    Do I need an attorney for this?

    For the Terminal scenario specifically, yes. The letter of instruction and any trigger documents that grant authority in your absence are legal documents and should be reviewed by a professional. The rest of the protocol (exports, credential rotation, drill cadence) doesn’t need legal help.

    What about my password manager? What happens if I lose access to it?

    Every major password manager has an emergency access feature — a trusted contact who can request access to your vault after a waiting period. Configure it. It’s the single most important configuration item in the entire protocol, because the password manager is the root of recovery for everything else.

    How do I know when my export is actually complete?

    Open it on a different machine, in a different tool, and try to answer three specific questions using only the export: “What was the state of X project?”, “Who had access to Y?”, “When did Z happen?” If you can answer all three, the export is usable. If any question requires reaching back to the source system, the export is incomplete.

    What if my spouse or partner isn’t technical? Can they still be the primary steward?

    Yes. The primary steward’s job is not to operate the systems. Their job is to know where the instructions are and who to call. If you write the operational runbook clearly enough that a non-technical person can follow it to the operational steward, the division of responsibility works.

    Closing note

    The section of your digital life you haven’t written yet is the exit. Almost nobody writes it until they need it, and the moment you need it is the worst moment to write it.

    Write it now, in calm, with time to think. Don’t try to write it perfectly. A rough version that exists is infinitely better than a perfect version that doesn’t. The drill cadence will improve the rough version over years; the blank document never improves at all.

    If this article leads you to spend a single evening on a single runbook — even just the Terminal scenario, even just the one-page letter to your primary steward — it has done its job. The rest of the protocol can build from there.

    Every tool you enter, you will someday leave. Leave on purpose.

    Sources and further reading

    Related pieces from this body of work:

    On the Terminal scenario specifically, the Google Inactive Account Manager and Apple Legacy Contact features are both worth configuring today. Fifteen minutes apiece. Search your account settings for “inactive” or “legacy.”

  • Archive vs Execution Layer: The Second Brain Mistake Most Operators Make

    Archive vs Execution Layer: The Second Brain Mistake Most Operators Make

    I owe Tiago Forte a thank-you note. His book and the frame he popularized saved a lot of people — including a younger version of me — from living entirely inside their email inbox. The second brain concept was the right idea for the era it emerged in. It taught a generation of knowledge workers that their thinking deserved a system, that notes were worth taking seriously, that personal knowledge management was a discipline and not a character flaw.

    But the era changed.

    Most operators still building second brains in April 2026 are investing in the wrong thing. Not because the second brain was ever a bad idea, but because the goal it was built around — archive your knowledge so you can retrieve it later — has been quietly eclipsed by a different goal that the same operators actually need. They haven’t noticed the eclipse yet, so they’re spending evenings tagging notes and building elaborate retrieval systems while the job underneath them has shifted.

    This article is about the shift. What the second brain was for, what it isn’t for anymore, and what it should be replaced with — or rather, what it should be promoted to, because the new goal isn’t the opposite of the second brain; it’s the next version.

    I’m going to use a single distinction that has saved me more architecture mistakes than any other in the last year: archive versus execution layer. Once you can tell them apart, most of the confusion about knowledge systems resolves itself.

    What the second brain actually was (and why it worked)

    Before the critique, credit where credit is due.

    The second brain frame, as Tiago Forte articulated it starting around 2019 and formalized in his 2022 book, was a response to a specific problem. Knowledge workers were drowning in information — articles to read, books to remember, meetings to process, ideas to capture. The brain, the original one, is not great at holding all of that. Things slipped. Valuable thinking got lost. The second brain proposed a systematic external memory: capture widely, organize intentionally (the PARA method — Projects, Areas, Resources, Archives), distill progressively, express creatively.

    It worked because it named the problem correctly. For someone whose job required integrating lots of information into creative output — writers, researchers, analysts, knowledge workers — the capture-organize-distill-express loop produced real leverage. Over 25,000 people took the course. The book was a bestseller. An entire productivity-content ecosystem grew up around it. Notion became popular partly because it was a good place to build a second brain. Obsidian and Roam Research exploded for the same reason.

    I want to be unambiguous: the second brain frame was a good idea, correctly articulated, in the right moment. If you built one between 2019 and 2023 and it served you, it served you. You weren’t wrong to do it.

    You just might be wrong to still be doing it the same way in 2026.

    The thing that quietly changed

    Here’s what shifted between the era the second brain frame emerged and now.

    In 2019, the bottleneck was retrieval. If you had captured a piece of information — an article, a quote, an insight — the question was whether you could find it again when you needed it. Your system had to help the future-you pull the right thing out of the archive at the right time. Tagging mattered. Folder structure mattered. Search mattered. The whole architecture was designed to solve the retrieval bottleneck.

    In 2026, retrieval is no longer a meaningful bottleneck. Claude can read your entire workspace in seconds. Notion’s AI can search across everything you’ve ever put in the system. Semantic search finds things your tagging couldn’t. If you captured it, you can find it — without ever having to think about where you put it or what you called it.

    The retrieval problem got solved.

    So now the question is: what is the knowledge system actually for?

    If its job was to help you retrieve things, and retrieval is a solved problem, then the whole architecture of a second brain — the capture discipline, the PARA hierarchy, the progressive summarization — is solving a problem that is no longer the binding constraint on your productivity.

    The new bottleneck, the one that actually determines whether an operator ships meaningful work, is not retrieval. It’s execution. Can you actually act on what you know? Can your system not just surface information but drive action? Can the thing you built help you run the operation, not just remember it?

    That’s a different job. And a system optimized for the first job is not automatically good at the second job. In fact, it’s often actively bad at it.

    Archive vs execution layer: the distinction

    Let me name the distinction clearly, because the whole article depends on it.

    An archive is a system whose primary job is to hold information faithfully so that it can be retrieved later. Libraries are archives. Filing cabinets are archives. A well-organized Google Drive is an archive. A second brain, in its classical formulation, is an archive — a carefully indexed personal library of captured thought.

    An execution layer is a system whose primary job is to drive the work actually happening right now. It holds the state of what’s in flight, what’s decided, what’s next. It surfaces what matters for current action. It interfaces with the humans and AI teammates who are doing the work. An operations console is an execution layer. A well-designed ticketing system is an execution layer. A Notion workspace set up as a control plane (which I’ve written about elsewhere in this body of work) is an execution layer.

    Both have their place. They are not competing for the same real estate. You need some archive capability — legal records, signed contracts, historical decisions worth preserving. You need some execution layer — for the actual work in motion.

    The mistake most operators make in 2026 is treating their entire knowledge system like an archive, when their bottleneck has become execution. They pour energy into capture, organization, and retrieval. They get very little back because those activities no longer compound into leverage the way they used to. Meanwhile, their execution layer — the thing that would actually move their work forward — is underbuilt, undertooled, and starved of attention.

    The shift isn’t abandoning archiving. It’s recognizing that archiving is now the boring, solved utility layer underneath, and the real system design question is about the execution layer above it.

    Why the second brain architecture actively gets in the way

    This is the part that’s going to be uncomfortable for some readers, and I want to name it directly.

    The classical second-brain architecture doesn’t just fail to produce leverage for operators. It actively fights against what you actually need your system to do.

    Capture everything becomes capture too much. The core discipline of a second brain is wide capture — save anything that might be useful, sort it out later. In a retrieval-bound world this was fine because the downside of over-capture was only disk space. In an AI-read world, over-capture has a new cost: the AI you’ve wired into your workspace now has to reason across a corpus full of things you shouldn’t have saved. Old half-formed ideas. Articles that turned out not to matter. Drafts of thinking you would never let see daylight. Your AI teammate is seeing all of it, weighting it in responses, occasionally surfacing it in ways that are embarrassing.

    PARA optimizes for archive navigation, not current action. Projects, Areas, Resources, Archives. It’s a taxonomy for finding things. A taxonomy for doing things looks different: what’s active, what’s on deck, what’s blocked, what’s decided, what’s watching. Many people’s PARA systems silently morph into graveyards where active projects die because the structure doesn’t surface them — it files them.

    Progressive summarization trains the wrong reflex. The Forte method of progressively bolding, highlighting, and distilling notes is brilliant for a future-retrieval world. The reflex it trains — “I’ll process this later, the value is in the distillation” — is poisonous for an execution world. The value now is in doing the work, not in preparing the notes for the work.

    The system becomes the job. The most common failure mode I’ve watched play out is operators who spend more time tending their second brain than they spend on actual output. Tagging. Reorganizing. Restructuring their PARA hierarchy for the fourth time this year. The second brain becomes a hobby that feels productive because it’s complicated, but produces nothing the world actually sees. This has always been a risk of personal knowledge management, but it compounds dramatically in 2026 because the system-tending is now competing with a different, higher-leverage use of the same time: building the execution layer.

    I am not saying these failure modes are inherent to Tiago’s teaching. He’s explicit that the system should serve the work, not become the work. But the architecture makes the wrong path easier than the right one, and a lot of practitioners take it.

    What an execution layer actually looks like

    If you’ve followed the rest of my writing this month, you’ve seen pieces of it. Let me name it directly now.

    An execution layer is a workspace organized around the actual objects of your business — projects, clients, decisions, open loops, deliverables — rather than around categories of knowledge. Each object has a status, an owner, a next action, and a surface where it lives. The system exists to drive those objects forward, not to hold them for contemplation.

    A functioning execution layer has:

    A Control Center. One page you open first every working day that surfaces the live state — what’s on fire, what’s moving, what needs your call. Not a dashboard in the BI sense. A living summary updated continuously, readable in ninety seconds.

    An object-oriented database spine. Projects, Tasks, Decisions, People (external), Deliverables, Open Loops. Each one a real operational entity. Each one with a clear status taxonomy. Each one answerable to the question “what changed recently and what does that mean I should do?”

    Rhythms embedded in the system itself. A daily brief that writes itself. A weekly review that drafts itself. A triage that sorts itself. The system does the operational rhythm work so the human can do the judgment work.

    A small, deliberate archive underneath. Yes, you still need to preserve some things. Completed project records. Signed contracts. Important decisions for the historical record. But the archive is the sub-basement of the execution layer, not the whole building. You visit it occasionally. You don’t live there.

    Wired-in intelligence. Claude, Notion AI, or whatever intelligence layer you’ve chosen, reading from and writing to the execution layer so it can actually participate in the work rather than just answering questions about your notes.

    Compare that to what a classical second brain prioritizes — capture discipline, PARA hierarchy, progressive summarization — and you can see the difference immediately. The second brain is a library. The execution layer is a workshop.

    Operators need workshops, not libraries. Libraries are lovely. Workshops get things built.

    The migration path (how to change without blowing up what you have)

    If this article has landed and you’re looking at your own carefully-built second brain and realizing it’s mostly an archive, here’s how I’d approach the transition. I’ve done this in my own system, so this isn’t theoretical.

    Don’t delete anything yet. The worst move is to blow up the existing structure and rebuild from scratch. You have years of context in there. You’ll lose some of it even if you try to be careful. The right move is a layered transition, where you build the execution layer above the archive while leaving the archive intact underneath.

    Build the Control Center first. Before you touch any existing content, create the new anchor. One page. Two screens long. Links to the databases you actually work from. Live state at the top. This is the new front door to your workspace.

    Identify the active objects. What are you actually working on? Which clients, projects, deliverables, decisions? Make clean new databases for those, separate from whatever PARA folders you’ve accumulated. Move live work into those new databases. Let dead work stay in the archive where it already is.

    Install one rhythm agent. Pick the one operational rhythm that costs you the most attention — usually the morning context-gathering. Build a Custom Agent that handles it. See what it changes. Add another agent only after the first one is actually working.

    Gradually migrate what matters, archive what doesn’t. Over time, anything in your old second-brain structure that you actually reference will reveal itself by showing up in searches and references. Move those into the execution layer. Anything that doesn’t come up in a year genuinely belongs in the archive, not in your working system.

    Accept that the archive will shrink in importance over time. Not because it’s useless, but because its role changes from “primary workspace” to “occasional reference.” That’s fine. The archive was never the point. You just thought it was because the frame you were working from told you so.

    The whole transition can happen over a month of evenings. It doesn’t require a weekend rebuild. It requires a mental shift from “the system is a library” to “the system is a workshop with a small library attached.”

    What this is not

    A few clarifications before the critique side of this article leaves the wrong impression.

    I’m not saying don’t take notes. Taking notes is still valuable. Capturing thinking is still valuable. The shift isn’t away from writing things down; it’s away from treating the collection of written-down things as the system’s point.

    I’m not saying Tiago Forte was wrong. He was right for the era. He’s also shifted with the era — his AI Second Brain announcement in March 2026 is an explicit acknowledgment that the frame needs to evolve. Anyone still teaching the pure 2022 version of second-brain methodology without integrating what AI changed is the one not keeping up. Tiago himself is keeping up.

    I’m not saying archives are obsolete. Some things deserve archiving. Legal records, contracts, finished projects you might revisit, historical decisions, creative work you’ve produced. Archives are still a useful subcomponent of a functioning operator system. They just aren’t the system anymore.

    I’m not saying everyone who built a second brain made a mistake. If yours is working for you, keep it. The question is whether, if you sat down to design a knowledge system from scratch in April 2026 knowing what you now know about AI-as-teammate, you would build the same thing. My guess is most operators honestly answering that question would say no. If that’s your answer, this article is for you. If it isn’t, you can ignore me and carry on.

    The generalization: every layer eventually gets demoted

    There’s a broader pattern here worth naming because it keeps happening and most operators don’t see it coming.

    Every system that was load-bearing in one era gets demoted to a utility layer in the next. This isn’t a failure of the old system; it’s evidence that something else got built on top.

    Filing cabinets were a primary interface to knowledge work in the mid-20th century. They’re now a sub-basement of most offices. Email was a revolution in the 1990s. It’s now a backchannel for notifications from actual productivity systems. Spreadsheets were the original personal computing killer app. They’re now mostly a data-plumbing layer underneath dashboards and applications.

    The second brain is on the same arc. In 2019 it was revolutionary. In 2026 it’s becoming the quiet plumbing underneath the actual workspace. The frame that wanted it to be the whole system is going to age badly. The frame that treats archiving as a useful utility layer under something more alive is going to age well.

    The prediction that matters: five years from now, the operators who get the most leverage will be running execution layers with archives attached, not archives with execution layers grafted on. The architecture will be inverted from the second-brain orientation, and the second-brain era will look like the phase where people learned they needed a system — before the system learned what it was for.

    The one thing I want you to walk away with

    If you only remember one sentence from this article, let it be this:

    Your system’s job is to drive action, not to preserve context.

    Preserving context is a useful secondary function. The whole point of the system — the thing that justifies the time, the maintenance, the architectural decisions, the discipline — is that it helps you act. Not remember. Not retrieve. Not feel organized. Act.

    Every design decision you make about your knowledge system should be tested against that criterion. Does this help me act on what matters? If yes, keep it. If no, archive it or remove it. The discipline is ruthless about what earns its place, because everything that doesn’t earn its place is stealing attention from the thing that would.

    Most second brains I see in 2026 fail that test for most of their bulk. That’s the polite version. The honest version is that many operators have built elaborate systems that feel productive to maintain but produce nothing measurable in the world.

    The execution layer is the fix. Not as a replacement for archiving, but as the shift in orientation: from “preserve knowledge” to “drive work,” from library to workshop, from the discipline of capture to the discipline of action.

    If you take one evening this week and spend it rebuilding your workspace around that question, you will get more leverage from that evening than from a month of tagging.

    FAQ

    Is the second brain dead? No. The frame — “build a system that serves as external memory for your thinking” — is still useful. What’s changed is that the architecture Tiago Forte taught was optimized for a retrieval-bound world, and retrieval is no longer the binding constraint. The concept lives on; the implementation has evolved.

    What about Tiago’s new AI Second Brain course? It’s an honest update to the frame. Tiago announced his AI Second Brain program in March 2026 as a response to the same shift this article describes — Claude Code, agent harnesses, and AI that can actually read and act on your files. His version and mine may differ in emphasis, but we’re pointing at the same underlying change.

    Should I delete my existing second brain? No. Build the execution layer on top of it, migrate what matters, let the rest stay archived. Deleting your historical work is a loss you can’t undo. Reorienting what you focus on going forward is a gain that doesn’t require destroying what you have.

    What if I’m not an operator? What if I’m a student, writer, or creative? The archive-versus-execution-layer distinction still applies but weights differently. Students and creatives may still benefit from an archive orientation because their work actually does involve deep research and synthesis that’s retrieval-bound. Operators running businesses have a different bottleneck. Match the system to the actual bottleneck in your specific work.

    What do you use for your own execution layer? Notion, with Claude wired in via MCP, and a handful of operational agents running in the background. The specific stack is described in my earlier articles in this series; the pattern is tool-independent. Any capable workspace plus a capable AI layer can implement it.

    What about systems like Obsidian, Roam, or Logseq? All excellent archives. Less suited to the execution-layer role because they were designed around the knowledge-graph-and-retrieval use case. You can build execution layers in them, but you’re fighting the grain of the tool. Notion’s database-and-template orientation is a better fit for the operator pattern.

    Isn’t this just reinventing project management? Partially, yes. The execution layer shares DNA with project management systems. The difference is that project management systems are typically built for teams coordinating across many people, while the operator execution layer is built for one human (or a very small team) leveraged by AI. The priorities and design choices differ accordingly.

    How long does this transition take? The minimum viable version — Control Center, object-oriented databases, one rhythm agent — is a week of part-time work. The full transition from a classical second brain to a working execution layer is usually two to three months of gradual iteration. You don’t have to do it all at once.

    Closing note

    I wrote this knowing some readers will push back, and pushback on this one will be easier to dismiss than to engage with. That’s worth flagging up front.

    The easy dismissal: “You’re attacking Tiago Forte.” I’m not. I’m updating the frame he built, using tools he didn’t have access to, for problems that weren’t the binding constraint when he built it. If he’s updated his own frame — and he has — then updating mine is just keeping honest.

    The harder dismissal: “My second brain works for me.” Great. Keep it. If it actually produces leverage you can measure, the article doesn’t apply to you. If you’re being defensive because you’ve invested time in something you suspect isn’t paying rent, sit with that honestly before rejecting the argument.

    The operators I most want to reach with this piece are the ones who have a working second brain but feel a quiet sense that it isn’t quite delivering what they thought it would. That feeling is signal. It’s telling you the bottleneck has moved. The system you built was right for the problem it was solving; the problem has shifted underneath it.

    Promote the archive to a utility. Build the execution layer above. Let the system drive the work instead of holding it for review. That’s the whole move.

    Thanks for reading. If this one lands for you, the rest of this body of work goes deeper into how to actually build what I’m describing. If it doesn’t, no harm — there are plenty of places to read the traditional frame, and I’m not trying to convert anyone who’s still getting value from that version.

    The point is to have the argument out loud, because most operators haven’t heard it yet, and knowing what the argument is gives you the ability to decide for yourself.

    Sources and further reading

    Related pieces from this body of work:

  • What Notion Agents Can’t Do Yet (And When to Reach for Claude Instead)

    What Notion Agents Can’t Do Yet (And When to Reach for Claude Instead)

    Last refreshed: May 15, 2026

    Update — May 15, 2026: On May 13, 2026, Notion shipped the Notion Developer Platform (version 3.5), with Claude as a launch partner. The platform adds Workers, database sync, an External Agents API, and a Notion CLI. The patterns described in this article still work, but there is now a native, sanctioned alternative for some of what previously required custom MCP wiring or third-party automation. For the full breakdown of what changed and what it means for the Notion + Claude stack, see Notion Developer Platform Launch (May 13, 2026). For the underlying operating philosophy, see The Three-Legged Stack.

    I run both Notion Custom Agents and Claude every working day. I have opinions about when each one earns its place and when each one doesn’t. This article is those opinions, named clearly, with no vendor fingers on the scale.

    Most comparative writing about AI tools is written by people with an incentive to recommend one over the other — affiliate programs, platform partnerships, the writer’s own consulting practice specializing in one side. This piece doesn’t have that problem. I use both, I pay for both, and if one of them got replaced tomorrow, the pattern I run would survive with a different tool slotted into the same role. The tools are interchangeable. The judgment about which one to reach for is not.

    Here’s the honest map.

    The short version

    Use Notion Custom Agents when: the work is a recurring rhythm, the context lives in Notion, the output is a Notion page or database change, and you’re willing to spend credits on it running in the background.

    Use Claude when: the work needs real judgment, the context is complex or contested, the output is something that needs a human’s voice and review, or the workflow crosses enough systems that the agent’s world is too small.

    Those two sentences will save most operators ninety percent of the architecture mistakes I see people make. The rest of this article is specificity about why, because general rules only take you so far before you need to know what’s actually going on under the hood.

    Where Notion Custom Agents genuinely shine

    I’m going to start with the positive because anyone who only reads the critical part of a comparative article will walk away with a warped picture. Custom Agents are genuinely impressive when they fit the job.

    Recurring synthesis tasks across workspace data. The daily brief pattern I’ve written about works better in a Custom Agent than in Claude. The agent runs on schedule, reads the right pages, writes the synthesis back into the workspace, and is done. Claude can do this too, but Custom Agents do it without you remembering to prompt them. That’s the whole point of the “autonomous teammate” framing, and for rhythmic synthesis work, it genuinely delivers.

    Inbox triage. An agent watching a database with a clear decision tree — categorize incoming requests, assign a priority, route to the right owner — is a sweet-spot Custom Agent. It does the boring sort every day, flags the ones it’s unsure about, and keeps the pile from growing. Real teams are reportedly triaging at over 95% accuracy on inbound tickets with this pattern.

    Q&A over workspace knowledge. Agents that answer company policy questions in Slack or provide onboarding guidance for new hires are quietly some of the most valuable agents in production. They replace hours of repetitive answer-the-same-question work, and because the answers come from actual workspace content, the accuracy is high when the workspace is well-maintained.

    Database enrichment. An agent that watches for new rows in a database, looks up additional context, and fills in fields automatically is a beautiful fit. The agent is doing deterministic-adjacent work with just enough judgment to handle edge cases. This is exactly what Custom Agents were designed for.

    Autonomous reporting. Weekly sprint recaps, monthly OKR reports, Friday retrospectives. Reports that would otherwise require someone to sit down and write them, now drafted automatically from the workspace state.

    For these categories, Custom Agents are the right tool, and Claude is the wrong tool even though Claude would technically work. The wrong-tool-even-though-it-works framing matters because operators often default to Claude for everything, which is expensive in different ways.

    Where Notion Custom Agents break down

    Now the honest part. Custom Agents have real limits, and pretending otherwise is how operators get burned.

    1. Anything that requires serious reasoning across contested information

    Custom Agents are capable of synthesis, but the quality of their synthesis degrades when the inputs disagree with each other, when the right answer isn’t on the page, or when the task requires actually thinking through a problem rather than summarizing existing context.

    The signal that you’ve hit this limit: the agent produces an output that sounds plausible, reads well, and is subtly wrong. If you need to double-check every agent output in a category of work because you can’t trust the judgment, that category of work shouldn’t be going through an agent. Use Claude in a conversation where you can actually interrogate the reasoning.

    Specific examples where this shows up: strategic decisions, conflicting client feedback, legal or compliance-adjacent questions, anything that involves weighing tradeoffs. The agent will produce an answer. The answer will often be wrong in a specific way.

    2. Long-horizon work that needs to hold nuance across steps

    Custom Agents are designed for bounded tasks with clear inputs and clear outputs. When you try to use them for work that requires holding nuance across many steps — drafting a long document, executing a multi-stage strategic plan, navigating a complex workflow — the wheels come off.

    Part of this is architectural: agents have limited ability to carry state across runs in the way an extended Claude conversation can. Part of it is practical: the “one agent, one job” principle Notion itself recommends is a hard constraint, not a style guideline. When you try to make an agent do multiple things, you get an agent that does each of them worse than a single-purpose agent would.

    If the job you’re thinking about is genuinely one coherent thing that happens to have many steps, and the steps inform each other, it’s probably a Claude conversation, not a Custom Agent.

    3. Work that needs a specific human voice

    This one is more important than most operators realize. Agents write in a synthesized style. It’s a perfectly fine style. It’s also recognizable as a perfectly fine style, which is the problem.

    If the output is going to have your name on it — client communications, thought leadership, outbound that should sound like you — the agent’s default voice will flatten whatever was distinctive about your writing. You can push back on this with instructions, and good instructions help a lot. But the underlying truth is that Custom Agents optimize for “sounds like a competent business writer,” and competent business writing is a commodity. If you sell distinctiveness, the agent is a liability.

    Claude in a conversation, with your active voice-shaping, produces writing that can actually sound like you. Custom Agents optimize for a different thing.

    4. Anything requiring real-time web context

    Custom Agents can reach external tools via MCP, but they don’t have a general ability to browse the live web and integrate what they find into their reasoning. If the work requires recent news, real-time market data, or anything that isn’t in a known database the agent can query, the agent will either fail, hallucinate, or return stale information from whatever workspace snapshot it had.

    Claude — with web search enabled, with the ability to fetch arbitrary URLs, with research capabilities — handles this class of work dramatically better. The right architectural response: use Claude for anything with a live-web dependency, let Custom Agents handle the parts that don’t.

    5. Deep technical work

    Custom Agents can technically do technical work. They should mostly not be asked to. Writing code, debugging failures, analyzing logs, reasoning through system architecture — these live in Claude Code’s territory, not Custom Agents’ territory. The Custom Agent framework was built for operational workflows, and while it will attempt technical tasks, it attempts them at the quality of a generalist, not a specialist.

    The sign you’ve crossed this line: the agent is producing code or technical reasoning that a competent human reviewer would push back on. Move the work to Claude Code, which was built for exactly this.

    6. High-stakes writes with permanent consequences

    Agents execute. They don’t second-guess themselves. An agent configured to send emails will send emails. An agent configured to update client records will update client records. An agent configured to delete rows will delete rows.

    When the cost of the agent doing the wrong thing is high — sending a message you can’t unsend, overwriting data you can’t recover, triggering a payment you can’t reverse — the discipline is: don’t let the agent do it without human approval. Use “Always Ask” behavior. Use a draft-and-review pattern. Use anything that puts a human in the loop before the irreversible action.

    Operators who ship fast and iterate freely tend to underweight this category. The day you discover it’s been quietly overwriting the wrong database field for two weeks is the day you wish you’d built the review gate.

    7. Credit efficiency for genuinely reasoning-heavy work

    This one is practical rather than architectural. Starting May 4, 2026, Custom Agents run on Notion Credits at roughly $10 per 1,000 credits. Internal Notion data suggests Custom Agents run approximately 45–90 times per 1,000 credits for typical tasks — meaning tasks that require more steps, more tool calls, or more context cost proportionally more credits per run. That means simple recurring tasks are cheap. Complex reasoning-heavy tasks add up.

    If you’re building an agent that does heavy reasoning work many times per day, the credit cost can exceed what the same work would cost through Claude’s API directly, especially on higher-capability Claude models called directly without the Notion overhead. For high-frequency reasoning work, run the math before you commit to the agent architecture.

    Where Claude genuinely wins

    The other side of the honest comparison. Claude earns its place in categories where Custom Agents either can’t operate or operate poorly.

    Strategic thinking conversations. When you’re working through a decision, evaluating a tradeoff, or thinking through a strategy, Claude in an extended conversation is the right tool. The back-and-forth is the whole point. You can interrogate reasoning, push back on conclusions, reframe the problem mid-conversation. An agent that produces a one-shot answer, no matter how good, is the wrong shape for this kind of work.

    Drafting with voice. Writing that needs to sound like a specific person is Claude’s territory. You can load up Claude with context about your voice — past writing, tonal preferences, things to avoid — and get output that actually reads as yours. Notion Custom Agents will always produce generic-flavored writing. That’s fine for internal reports. It’s a problem for anything external.

    Code and technical work. Claude Code specifically is built for technical depth. It reads codebases, executes in a terminal, calls tools, iterates on failures. Custom Agents will flail at the same work.

    Research synthesis across live sources. Claude with web search and fetch capabilities handles “go read this, this, and this, and tell me what the current state actually is” in a way Custom Agents structurally can’t. Anything that requires reaching outside a known data universe is Claude.

    Work that crosses many systems. When a workflow needs to touch code, Notion, a database, an external API, and a human review, Claude Code with the right MCP servers connected coordinates across them better than a Custom Agent inside Notion does. The agent’s world is Notion-plus-connected-integrations. Claude’s world is wider.

    Anything requiring judgment about whether to proceed. Agents execute. Claude in a conversation can pause, check with you, and ask “should I actually do this?” That judgment layer is frequently the most important part of the workflow.

    The pattern that actually works (both, in the right places)

    The operators who get this right aren’t choosing one tool over the other. They’re running both, in specific roles, with clear handoffs.

    The pattern I run:

    Rhythmic operational work lives in Custom Agents. Morning briefs, triage, weekly reviews, database enrichment, Q&A over workspace knowledge. Things that happen repeatedly, have clear inputs, and produce workspace-shaped outputs.

    Judgment-heavy work lives in Claude conversations. Strategic decisions, drafting with voice, research, anything requiring back-and-forth. I do this work in Claude chat sessions with the Notion MCP wired in, so Claude has real context when I need it to.

    Technical work lives in Claude Code. Building scripts, managing infrastructure, debugging, writing code. Custom Agents don’t touch this.

    Handoffs are explicit. When I make a decision in Claude that needs to become operational, it lands as a task or brief in a Notion database, and from there a Custom Agent can pick it up. When a Custom Agent surfaces something that needs judgment, it creates an escalation entry that shows up on my Control Center, where I engage Claude to think through it.

    The two systems pass work back and forth through the workspace. Neither tries to do the other’s job. The seams are the Notion databases where state lives.

    This is not the vendor-shaped pattern. The vendor-shaped pattern says “Custom Agents can handle everything.” The operator-shaped pattern says “Custom Agents handle what they’re good at, and when the work exceeds their reach, another tool takes over with a clean handoff.”

    The decision tree, when you’re not sure

    For a specific piece of work, run these questions in order. Stop at the first “yes.”

    Does this task need a specific human voice, or could it be written by any competent person? If it needs your voice, reach for Claude. If it doesn’t, move on.

    Does this task require reasoning across contested or ambiguous information? If yes, Claude. If no, move on.

    Does this task need real-time web context, live external data, or information not already in a known database? If yes, Claude. If no, move on.

    Does this task involve code, system architecture, or technical depth? If yes, Claude Code. If no, move on.

    Does this task have high-stakes irreversible consequences? If yes, wrap it in a human-approval gate — either run it through Claude where the human is in the loop, or use Custom Agents with “Always Ask” behavior.

    Does this task happen repeatedly on a schedule or in response to workspace events? If yes, Custom Agent. This is the sweet spot.

    Is the output a Notion page, database row, or something that stays in the workspace? If yes, Custom Agent is usually the right call.

    Is the task bounded enough that it could be described in a couple of clear sentences? If yes, Custom Agent. If it’s sprawling, it’s probably too big for an agent.

    If you’re through the tree and still not sure, default to Claude. Claude is more expensive in money and cheaper in hidden cost than a Custom Agent running the wrong job.

    The failure modes I’ve seen

    Specific patterns that go wrong, in my observation:

    The “agent for everything” operator. Someone who just got access to Custom Agents and is building agents for tasks that don’t need agents. The agents mostly work. The ones that mostly work waste credits on tasks a template or a simple automation would handle. The ones that partially work produce quiet low-grade mistakes that accumulate.

    The “Claude for everything” operator. The inverse. Someone who got comfortable with Claude and hasn’t made the leap to letting agents handle the rhythmic work. They’re paying the context-loss tax every morning, doing the triage manually, writing every brief from scratch. Claude is too expensive a tool — in attention, if not dollars — to run routine work through.

    The operator who built one giant agent. Custom Agents are meant to be narrow. Someone violates the “one agent, one job” principle by building an agent that does inbox triage and database updates and weekly reports and client communications. The agent becomes hard to debug, expensive to run, and unreliable across its many hats. The fix is almost always breaking it into three or four single-purpose agents.

    The operator who didn’t build review gates. An agent sending emails without human approval. An agent deleting rows based on inferred criteria. An agent updating client-facing pages from an unchecked data source. The cost of the first real mistake exceeds the cost of the review gate that would have prevented it, every time.

    The operator who never checked credit consumption. Custom Agents consume credits based on model, steps, and context size. An operator who built ten agents and never looked at the dashboard ends up surprised when the monthly bill is much higher than expected. The fix is easy — Notion ships a credits dashboard — but it has to actually get checked.

    The timing honest note

    A piece of this article that ages. These comparisons are true in April 2026. Custom Agents are new enough that the feature set will expand significantly over the next year. Claude is evolving rapidly. The specific gaps I’ve named may close; new gaps may open in different directions.

    What won’t change is the pattern: some work wants a specialized tool, some work wants a general-purpose one. Some work is rhythmic, some is judgment-driven. Some work lives inside a workspace, some crosses systems. The vocabulary for when to use which tool will evolve; the underlying truth that different shapes of work deserve different tools will not.

    If you’re reading this in 2027 and Custom Agents have shipped fifteen new capabilities, the specific “can’t do” list will be shorter. The decision tree at the top of this article will still work. That’s the part worth holding onto.

    What I’m not saying

    A few clarifications because I want to be clear about what this article is and isn’t.

    I’m not saying Custom Agents are bad. They’re genuinely good at what they’re good at. They’re saving me hours per week on work I used to do manually.

    I’m not saying Claude is strictly better. Claude is more capable at a broader set of tasks, but it also costs more, requires active operator engagement, and can’t sit in the background running overnight rhythms the way Custom Agents can.

    I’m not saying there’s one right answer for every operator. Different operators with different businesses and different workflows will land on different splits. The decision tree helps, but it’s a starting point, not a conclusion.

    I’m not saying this is permanent. Tool landscapes change fast. Six months from now there may be categories where Custom Agents beat Claude that don’t exist today, and vice versa. What matters is developing the habit of asking “which tool is this work actually shaped for?” instead of defaulting to whichever one you learned first.

    The one thing I’d want you to walk away with

    If you read nothing else in this article, this is the sentence I’d want in your head:

    Rhythmic operational work wants an agent; judgment-heavy work wants a conversation.

    That distinction — rhythm versus judgment — cuts through almost every architecture question you’ll have when deciding what to route where. It’s not the only dimension that matters, but it’s the one that settles the most decisions correctly.

    Work that happens on a schedule or in response to an event, with bounded inputs and clear outputs? That’s rhythm. Build a Custom Agent.

    Work that requires thinking through tradeoffs, integrating disparate information, or producing output with specific voice and judgment? That’s a conversation. Engage Claude.

    Get that right for most of your workflows and the rest of the architecture tends to sort itself out.

    FAQ

    Can’t Custom Agents do everything Claude can do, just inside Notion? No. Custom Agents are optimized for bounded, rhythmic, workspace-shaped tasks. They can technically attempt work that requires deep reasoning, specific voice, or live external context, but the results degrade in predictable ways. Claude — in a conversation or in Claude Code — handles those categories better.

    Should I just use Claude for everything then? No. Rhythmic operational work — morning briefs, triage, weekly reports, database enrichment — is genuinely better in Custom Agents than in Claude, because the “autonomous teammate running while you sleep” property matters. The right answer is running both, in their respective sweet spots.

    What’s the cost comparison? Starting May 4, 2026, Custom Agents cost roughly $10 per 1,000 Notion Credits. Internal Notion data suggests agents run approximately 45–90 times per 1,000 credits depending on task complexity. Claude’s subscription pricing is flat. For high-frequency simple tasks, Custom Agents are usually cheaper. For heavy reasoning work done many times per day, running Claude directly can be more cost-efficient.

    What about Notion Agent (the personal one) versus Claude? Notion Agent is Notion’s on-demand personal AI — you prompt it, it responds. It’s fine for in-workspace tasks where you need AI help with content you’re already looking at. For deeper reasoning, complex drafting, or cross-tool work, Claude is more capable. Notion Agent is a good ambient utility; Claude is a general-purpose intelligence layer.

    Which should I learn first if I’m new to both? Claude. Learn to think with an AI as a thinking partner before you try to build autonomous agents. Once you understand what AI can and can’t do in a conversation, the design decisions for Custom Agents become much clearer. Jumping to Custom Agents without the Claude foundation is how operators end up with agents that don’t work as expected.

    Can Custom Agents use Claude models? Yes. Custom Agents let you pick the AI model they run on. Claude Sonnet 4.6 and Claude Opus 4.7 are both available, along with GPT-5 and various other models. This means the underlying intelligence of a Custom Agent can be Claude — you’re choosing between Claude-as-conversation (claude.ai, Claude Desktop, Claude Code) and Claude-as-embedded-agent (Custom Agent running Claude). Different interfaces, same underlying model in that case.

    What if I want Claude to work autonomously on a schedule like Custom Agents do? Possible, but requires more work. Claude Code can be scripted; you can run it on a cron job; you can set up headless workflows. But the “out of the box autonomous teammate” experience is Notion’s current strength, not Anthropic’s. If you want autonomous-background-work without building your own infrastructure, Custom Agents are easier.

    How do I decide for my specific situation? Run the decision tree in the article. If you’re still unsure, default to Claude — it’s the more general-purpose tool, and the cost of using the wrong tool for judgment-heavy work is higher than the cost of using the wrong tool for rhythmic work. You can always migrate a recurring workflow to a Custom Agent once you understand the shape.

    Closing note

    The honest comparison isn’t one tool versus the other. It’s understanding that different shapes of work want different shapes of tool, and that most operators lose more time to the mismatch than to any individual tool’s limitations.

    Custom Agents are good at being Custom Agents. Claude is good at being Claude. Neither is good at being the other. Use both, in the places each belongs, with clean handoffs between them, and the stack hums.

    Skip the vendor narratives. Read your own workflows. Route each piece to the tool it’s actually shaped for. That’s the whole game.

    Sources and further reading

    Related Tygart Media pieces:

  • The Agency Stack in 2026: Notion + Claude + One Human

    The Agency Stack in 2026: Notion + Claude + One Human

    I’m going to describe the stack I actually run, and then I’m going to tell you honestly whether you should copy it.

    Most writing about “AI agencies” in April 2026 is either pitch deck vapor or hedged-everything consultant speak — pieces that tell you “AI is transforming agencies” without telling you which tools, which workflows, which tradeoffs. This article is the opposite. I’m going to name specifics. I’m going to say what’s working. I’m going to say what isn’t. I’m going to skip the part where I pretend this is a solved problem, because it isn’t, and pretending is how operators who listened to the pitch deck end up eighteen months into a rebuild.

    The stack that follows is what a real, paying-bills agency runs to manage dozens of active properties, real client relationships, and a content production operation that ships every day — with one human in the operator chair. It is not hypothetical. It is also not recommended for everyone, which is the part most of these articles leave out.

    Here’s the real version. You can decide whether it’s for you when we get to the bottom.

    The one-line version of the stack

    Notion is the control plane. Claude is the intelligence layer. A handful of operational services run the work. One human makes the calls.

    That’s it. That’s the whole stack at the summary level. Everything that follows is specificity about what each of those pieces does, why it’s there, and what happens when you try to run a real business through it.

    The four pieces are load-bearing in different ways. Notion holds the state of the business — what’s happening, what’s decided, what’s next. Claude provides the judgment and the synthesis when judgment is needed. The operational services (publishers, research tools, deployment pipelines) do the deterministic work that judgment shouldn’t be wasted on. The human reads, decides, approves, and occasionally gets out of the way.

    Fifteen years ago the same agency would have needed forty people. Ten years ago it would have needed twenty. Five years ago it would have needed eight. In April 2026 it needs one human plus the stack. That’s the thesis. The question is whether you can actually run it that way.

    What “AI-native” actually means in this context

    The phrase “AI-native” has been worn out enough that I need to be specific about what I mean.

    AI-native doesn’t mean “uses AI tools.” Every agency uses AI tools. Every freelancer uses AI tools. That bar is on the floor.

    AI-native means the operating model of the business assumes AI is a teammate, not a productivity tool. AI is in the loop on strategic thinking. AI is reading the state of the workspace and synthesizing it. AI is drafting, reviewing, triaging, and sometimes deciding — with human oversight, but as a continuous participant, not an occasional assistant you turn to when you get stuck.

    The practical difference: an agency that uses AI tools works the way agencies have always worked, but with ChatGPT open in a tab. An AI-native agency has rebuilt its workflows around the assumption that there’s a persistent intelligence layer in the substrate of the business.

    The stack below is what the second version looks like when you commit to it.

    The control plane: Notion

    Notion is where I live during the working day. Not where I put things when I’m done with them — where I actually do the work.

    The workspace is organized around the Control Center pattern I’ve written about before. A single root page that surfaces the live state of the business: what’s on fire today, what’s progressing, what’s waiting on me, what the week’s focus is. Under it sits a database spine that maps to the actual operational objects — properties, clients, projects, briefs, drafts, published work, decisions, open loops. Each database answers a specific question someone running the business would ask regularly.

    Every meaningful page in the workspace has a small JSON metadata block at the top — page type, status, summary, last updated. That metadata block is for the AI, not for me. It lets Claude read the state of a page in a hundred tokens instead of three thousand. Across a workspace of thousands of pages, the compounding context savings are enormous, and it changes what Claude can realistically see in a session.

    The workspace is sharded deliberately. The master context index lives as a small router page that points to larger domain-specific shards. When Claude needs to reason about a specific area of the business, it fetches the shard for that area. When it needs the whole picture, it fetches the router. This is not a product feature anyone has written about — it’s a pattern I arrived at after the main index page got too large to fit into Claude’s context window without truncation. It works. It’s probably what a lot of operators will end up doing.

    What Notion is great at: holding operational state, being legible to both humans and AI, letting you traverse the business by asking questions of the workspace rather than navigating folders, integrating cleanly with Claude via MCP, running background rhythms through Custom Agents.

    What Notion is not great at: being a database in the performance sense (anything heavy goes somewhere else), being the source of truth for code (version control is), being the source of truth for financial transactions (a real accounting system is), being reliable as the only source for anything mission-critical (it has an outage SLA, not an uptime guarantee).

    The rule I follow: Notion holds the operating company. It does not hold the substrate the operating company depends on. That distinction is what keeps the pattern stable.

    The intelligence layer: Claude

    Claude is the AI I actually run the business with. Not because Claude is strictly better than the alternatives at every task — at this point in 2026 the frontier models are all highly capable — but because Claude’s design posture matches what an operator actually needs.

    Specifically: Claude is thoughtful about uncertainty, tells me when it doesn’t know, asks for clarification instead of fabricating, and has a deep integration with Notion via MCP that makes the workspace-and-AI pattern actually work. Those qualities are worth more to me than any single-task benchmark. An AI that sometimes gets things wrong but tells me when it’s uncertain is far more useful than an AI that confidently hallucinates.

    The intelligence layer shows up in three configurations:

    Chat Claude — what I use for strategic thinking, drafting, review, and synthesis. A conversation on claude.ai or the desktop app with the Notion MCP wired in, so Claude can reach into the workspace to ground its answers in real context. This is where the high-judgment work happens. When I’m making a decision, I work through it in a Claude conversation before I commit to it.

    Claude Code — the terminal-based version that lives at the intersection of code and agent. This is where the more technical work happens — building publishers, writing scripts, managing infrastructure, executing multi-step workflows that touch multiple systems. Claude Code reads my codebase, reaches into Notion when it needs to, calls external services through MCP, and writes back run reports.

    Notion’s in-workspace AI (Custom Agents and Notion Agent) — the on-demand and autonomous agents that live inside Notion itself. These handle the rhythms: the daily brief that’s written before I wake up, the triage agent that sorts whatever lands in the inbox, the weekly review that gets drafted on Friday. I didn’t build these to be clever. I built them because I was doing the same small synthesis tasks over and over, and Custom Agents let me stop.

    Three configurations, three different jobs. Each one’s strengths map to a different kind of work. Together they cover the whole territory.

    What Claude is great at: synthesis across real context, drafting with judgment, reasoning through decisions, catching inconsistencies in my thinking, executing defined workflows with honest failure modes.

    What Claude is not great at: being the last line of defense on anything (always have a human gate), handling workflows where one error compounds (use deterministic tools for those), long-horizon autonomy without oversight (agents drift, supervise accordingly), making decisions that require context it doesn’t have access to.

    The mental model I use: Claude is a thoughtful senior teammate who happens to be infinitely patient and always awake. That framing gets the relationship right. Over-rely on it and you get hurt. Under-rely on it and you’ve hired a senior teammate and asked them to run errands.

    The operational services: the things that do the work

    The third layer is the part most agency-AI writeups skip, because it’s unglamorous. It’s the set of operational services that do the actual deterministic work. Publishing. Research. Deployment. Monitoring. The stuff that shouldn’t require judgment once you’ve set it up correctly.

    I’m going to describe the shape without naming specific tools, because the shape is what’s durable and the specific tools will change.

    Publishers — services that take content prepared upstream and push it to the properties where it needs to live. WordPress for editorial content, social media scheduling for distribution, email tools for outbound. The publisher’s job is to execute reliably and log honestly. When it fails, it fails loudly enough that I notice.

    Research infrastructure — services that pull structured data about keywords, competitors, search volumes, backlink profiles, and so on. This is where AI-native agencies diverge most sharply from traditional ones. Traditional agencies do research manually. AI-native agencies run research as a pipeline: the structured data comes in, gets processed, and lands in the workspace as briefs and intelligence reports that the human and the AI both read.

    Background pipelines — the scheduled services that keep the workspace fresh. New briefs get generated. Stale content gets flagged. Traffic data gets ingested. The kinds of things that an agency would traditionally ask a human to do on a weekly rhythm, running autonomously in the background.

    Deployment and monitoring — how the technical side ships. Version control holds the source of truth. Deployments run on triggers. When something breaks, it breaks to a channel I actually read.

    The principle that holds all of this together: deterministic work belongs in deterministic systems. Don’t use an AI agent to do something a script can do. An AI agent adds judgment, which is valuable when you need judgment, and costly when you don’t. The operational services do the work that has a right answer every time. The AI handles the work that requires judgment.

    Most agency-AI failures I’ve watched happen are cases where someone tried to use an AI agent for the deterministic work. The agent mostly succeeds, occasionally hallucinates, and introduces a class of silent failure that didn’t exist in the deterministic version. It feels like you’re being clever. You’re introducing unreliability.

    The one human in the chair

    This is the part the vendor writeups never include, and it’s the most important piece.

    There is one human in the operator chair. That human is non-optional. Every workflow, every agent, every pipeline eventually terminates at a human decision or a human review gate. The AI stack does not run the business. The AI stack is a lever that makes one human capable of running what used to take many.

    What the human does in this configuration is different from what they would have done in a traditional agency. The human is not writing every post. The human is not doing every bit of research. The human is not executing every workflow. The human is:

    Setting the posture. What are we working on this week? What’s the priority? What’s the theme? The AI is exceptional at executing against clarity. It is not exceptional at deciding what to be clear about.

    Reading the synthesis. The AI surfaces what matters. The human decides what to do about it. Every morning brief, every weekly review, every escalation flags lands in front of the human, who makes the call.

    Making the judgment calls. When a client needs a difficult conversation. When a strategy needs to change. When something the AI suggested is actually wrong. These are the moments the AI can’t be left alone with. The operator role is increasingly concentrated around exactly these moments.

    Holding the relationships. Clients don’t want to talk to an AI. They want to talk to a human who happens to be very well-supported by AI. The difference matters enormously in trust, tone, and staying power of the engagement.

    Maintaining the stack itself. The stack doesn’t maintain itself. Every week there are small adjustments, small rewirings, small improvements. The operator is also the architect of the operating company, and the architecture is a living thing.

    A person who thought they were buying “AI that runs my agency for me” is going to be disappointed. A person who understood they were buying “a lever that makes them ten times more effective at the parts of agency work that actually matter” is going to be delighted. The difference is what you think you’re getting.

    The daily rhythm (what it actually looks like)

    Let me describe a real working day in this stack, because the abstract description doesn’t convey what using it feels like.

    Morning. I open Notion. The Morning Brief Agent ran overnight; the top of today’s Daily page already has a three-paragraph synthesis of the state of the business, pulled from the active projects, the task database, yesterday’s run reports, and the overnight changes. I read it in ninety seconds. I know what’s on fire, what’s progressing, what’s waiting on me. The context tax that used to cost me the first hour of every day is already paid.

    Morning block. I work through the highest-leverage thing on the day’s priority list. If it’s strategic, I work through it in a Claude conversation with the Notion workspace wired in, because grounding the AI in real context produces dramatically better thinking than working in isolation. If it’s technical, I work in Claude Code, because the terminal version handles multi-step technical work better. Either way, I’m working with the AI as a thinking partner, not a tool I reach for occasionally.

    Mid-day. The triage agent has processed whatever landed in the inbox. I scan its decisions, override the ones I disagree with, and dispatch anything important into its real database. The escalation agent has flagged the three things that need my attention today. I make the calls. These are the moments the stack needs a human for — no amount of clever configuration replaces them.

    Afternoon block. Content operations. Research intelligence lands as structured data in the workspace. Briefs get drafted. I review them. Approved briefs flow to the publishing pipeline. The pipeline runs, logs back to the workspace, and I get notified of anything that failed. I don’t write every post. I write the ones where my voice specifically matters, and I review the rest. The ratio is maybe one in ten that I write from scratch these days.

    Evening. Five minutes of close. Anything that didn’t get done gets re-dated. Tomorrow’s priority list pre-stages. I close Notion. The overnight agents will handle the rhythms while I sleep.

    That’s the day. It is dramatically different from running a traditional agency, and dramatically more sustainable. The cognitive load is substantially lower even while the operational throughput is substantially higher. That’s the whole promise of the pattern, and it’s the part that’s real.

    What this stack actually costs (and doesn’t)

    The direct tool costs for the stack in April 2026, at the level I run it:

    • Notion Business plan with AI add-on
    • Claude subscription (Max tier for the agent budget)
    • A cloud provider account for the operational services (running pennies to small dollars per day at my volume)
    • A handful of research and analysis tool subscriptions
    • Domain, email, and the usual small-business infrastructure

    Total monthly direct tool cost is the equivalent of what a traditional agency would spend on a single junior employee’s salary for one week. The leverage ratio is extreme, and it will get more extreme.

    What it costs that isn’t money:

    • Setup time. Weeks to stand up the initial version, months to iterate it into something that runs smoothly. This is not a weekend project.
    • Ongoing attention to the stack itself. Maybe ten percent of my week is spent on the operating company rather than on client work. That ratio is load-bearing; if I let it go below that, the stack rots.
    • Discipline about not adding cleverness. Every new tool, every new agent, every new integration is a tax on the coherence of the system. Most weeks I’m resisting the urge to add something, not looking for something to add.
    • Loneliness of the role. One-human agencies are lonely. You don’t have a team meeting. You don’t have a coffee conversation with a coworker. The stack is not a substitute for colleagues. This is the part nobody writes about and it’s genuinely significant.

    What this stack is not good for

    If I’m being honest about who should not run this pattern, it includes:

    Agencies that want to scale headcount. This stack is designed to make one human capable of more. It’s not designed to coordinate ten humans. A ten-person agency on this stack would have chaos problems I haven’t solved.

    Businesses where the work is primarily relational. Sales-heavy businesses, high-touch consulting, therapy practices. The stack is strong at operational and production work. It is weak at anything where the work is fundamentally “I am present with this other person.”

    Anyone uncomfortable with AI making meaningful decisions. The stack assumes you’re willing to let AI make decisions that have real consequences — triage, synthesis, drafting under your name. If that crosses your line philosophically, don’t force it. The stack won’t be fun for you.

    People looking for a plug-and-play system. This is a living architecture. It requires ongoing maintenance. It never stops being built. If you want something that works out of the box and stays working, buy software; don’t build an operating company.

    Early-stage businesses without a clear shape yet. The stack rewards clarity about what your business is. If you’re still figuring that out, the stack will accelerate whatever direction you’re going — which is great if the direction is right and brutal if it isn’t. Figure out the direction first, then build the stack.

    Who this stack is good for

    The operators I’ve seen get the most out of this pattern share a specific profile:

    • Running businesses with high operational complexity but small team size. Multi-property content operations, advisory practices, specialist agencies. The kind of business where one capable person with leverage beats a team without it.
    • Comfortable with systems thinking. The stack rewards people who think in terms of flows, interfaces, and substrates. If that vocabulary feels alien, the stack will feel alien.
    • Honest about what they’re good at and what they aren’t. The stack amplifies the operator. If the operator is strong at strategy and weak at execution, the stack handles the execution. If the operator is strong at execution and weak at strategy, the stack does not magically produce strategy. Know which version you are.
    • Willing to maintain the architecture. The stack is a long commitment to the operating company, not a one-time setup. Operators who enjoy tending the system do well. Operators who resent tending the system should not run it.

    If you recognize yourself in the good-fit list and not the bad-fit list, this pattern is probably worth the investment. If you’re on the fence, it probably isn’t yet — come back when the decision is clearer.

    The part I want to be brave about

    Here’s the part this article is supposed to be honest about.

    This pattern works for me. It might not work for you. The vendor-shaped narrative says every business should be AI-native, every agency should be running this stack, every operator should be ten times leveraged. That narrative is wrong. It’s wrong in the boring, everyday way that industry narratives are always wrong: it oversells, it under-discloses the costs, and it creates an expectation gap that a lot of operators are going to run into eighteen months from now.

    The accurate narrative is this: for a specific kind of operator running a specific kind of business, this stack produces a kind of leverage that was not previously available. For everyone else, it’s a distraction from what they should actually be doing, which is the hard work of their specific business with the tools that fit their specific situation.

    I am describing what I run because I think honest examples are more useful than vague generalities. I am not recommending you run it. I am recommending you look at your actual business, your actual operating constraints, and your actual relationship with AI tools, and decide whether a version of this pattern — adapted, simplified, or rejected — makes sense for you.

    There’s a version of this article that promises that if you copy my stack, you’ll get my outcomes. That article is lying to you. The outcomes come from matching the stack to the business, not from the stack itself.

    If you read this and it resonates, take the pieces that apply. If you read this and it doesn’t, take what you learned about what’s possible and leave the rest. Either response is correct.

    The five things I’d tell someone thinking about building something like this

    Start with the Control Center, not the agents. The Control Center is the anchor everything else builds against. If you build agents before you have the Control Center, the agents have nothing to write to. Build the workspace shape first. The rest follows.

    Resist the urge to add complexity. The operators who succeed with this pattern run simpler versions than they could. The operators who fail run more elaborate versions than they need. Every piece of the stack should be earning its place every week.

    Write everything down as you go. The operating company is a living architecture. Six months from now you will have forgotten why you made a specific configuration choice. Document the choices in the workspace as you make them. Future-you will thank present-you.

    Don’t over-trust the AI. It’s a teammate, not an oracle. It’s wrong sometimes. It’s confident when it shouldn’t be sometimes. Build review gates. Assume failure. The stack is resilient when you don’t assume otherwise.

    Accept that you are building an operating company, not deploying software. This is a long game. It doesn’t work in the first week. It starts working in the second month. It starts compounding in the sixth month. If you’re not willing to tend it for that long, don’t start.

    A closing observation

    I’ve been running variations of this stack for long enough to have opinions that don’t match what I thought I believed when I started. The biggest surprise has been how much of the work is operational hygiene rather than AI cleverness. Building an agent was the easy part. Running an agency on the operating company pattern has mostly been a discipline problem — staying consistent about metadata, about documentation, about review gates, about when to let the AI decide and when to intervene.

    The AI is not the interesting part anymore. The interesting part is the operating model the AI makes possible. That’s the part this article has tried to describe honestly, and that’s the part worth thinking about if you’re considering something similar.

    If you do build a version of this, I’d genuinely like to hear how it turns out. The frontier here is being figured out by operators sharing what works and doesn’t, and every honest report makes the next person’s build better. This is my report. I hope it helps.

    FAQ

    Can I run this stack solo? Yes. The stack is explicitly designed for solo operators or very small teams. One-human operation is the whole point. Multi-person teams work too but introduce coordination complexity the pattern doesn’t directly solve.

    How long does it take to build? The minimum viable version — Control Center, a handful of databases, one Custom Agent, Claude wired in — is a week of part-time work. The version that actually earns its place takes two to three months of iteration. It never stops getting built; it compounds over time.

    Do I need to know how to code? For the minimum viable version, no. Notion + Claude + Notion Custom Agents gets you a long way without writing code. For the operational services layer, some technical comfort is needed or you’ll need a technical collaborator. Claude Code dramatically lowers the bar here.

    What if Notion gets replaced by a competitor? The pattern survives. The Control Center, the database spine, the metadata discipline, the workspace-as-control-plane posture — all of those port to any capable workspace tool. If something displaces Notion in 2027, the migration is real work but the operating model is durable. The durable asset is the pattern, not the specific tool.

    What if Claude gets replaced by a competitor? Also fine. The pattern assumes there’s an intelligence layer wired into the workspace; Claude is the current implementation of that layer. If another frontier model becomes more suitable, swap it. The MCP standard that connects everything is model-agnostic. This is deliberate.

    Can I use ChatGPT or another AI instead of Claude? Mostly yes. The MCP-to-Notion pattern works with any AI that supports MCP, including ChatGPT, Cursor, and others. I use Claude for the reasons described above, but the stack pattern is compatible with other frontier models. Don’t let tool preferences get in the way of the architecture.

    How much does this cost to run? The tool subscription stack costs roughly what one junior employee’s weekly salary would cost per month, total. The non-monetary costs (setup time, maintenance attention, lifestyle tradeoffs of solo operation) are more significant and worth thinking about before committing.

    Is this sustainable for a growing business? Yes, up to a point. The pattern scales smoothly to a certain operational volume per human. Beyond that, you need more humans, and coordinating multiple humans on this stack introduces problems that the solo version doesn’t have. Most operators hit the natural ceiling before they hit the growth limit.

    Sources and further reading

    Related reading from the broader ecosystem:

  • How to Wire Claude Into Your Notion Workspace (Without Giving It the Keys to Everything)

    How to Wire Claude Into Your Notion Workspace (Without Giving It the Keys to Everything)

    Last refreshed: May 15, 2026

    Update — May 15, 2026: On May 13, 2026, Notion shipped the Notion Developer Platform (version 3.5), with Claude as a launch partner. The platform adds Workers, database sync, an External Agents API, and a Notion CLI. The patterns described in this article still work, but there is now a native, sanctioned alternative for some of what previously required custom MCP wiring or third-party automation. For the full breakdown of what changed and what it means for the Notion + Claude stack, see Notion Developer Platform Launch (May 13, 2026). For the underlying operating philosophy, see The Three-Legged Stack.

    The step most tutorials skip is the one that actually matters.

    Every guide to connecting Claude to Notion walks you through the same mechanical sequence — OAuth flow, authentication, running claude mcp add, and done. It works. The connection lights up, Claude can read your pages, write to your databases, and suddenly your AI has the run of your workspace. The tutorials stop there and congratulate you.

    Here’s the part they don’t mention: according to Notion’s own documentation, MCP tools act with your full Notion permissions — they can access everything you can access. Not the pages you meant to share. Everything. Every client folder. Every private note. Every credential you ever pasted into a page. Every weird thing you wrote about a coworker in 2022 and forgot was there.

    In most setups the blast radius is enormous, the visibility is low, and the decision to lock it down happens after something goes wrong instead of before.

    This is the guide that takes the extra hour. Wiring Claude into your Notion workspace is straightforward. Wiring Claude into your Notion workspace without giving it the keys to everything takes a few additional decisions, a handful of specific configuration choices, and a mental model for what should and shouldn’t flow across the connection. That’s the hour worth spending.

    I run this setup across a real production workspace with dozens of active properties, real client work, and data I genuinely don’t want an AI to have unbounded access to. The pattern below is what works. It is also honest about what doesn’t.

    Why Notion + Claude is worth doing carefully

    Before the mechanics, it’s worth being clear about what you get when you wire this up correctly.

    Claude with access to Notion is not Claude with a better search function. It is a Claude that can read the state of your business — briefs, decisions, project status, open loops — and reason across them to help you run the operation. It can draft follow-ups to conversations it finds in your notes. It can pull together summaries across projects. It can take a decision you’re weighing, find every related piece of context in the workspace, and give you a grounded opinion instead of a generic one.

    That’s the version most operator-grade users want. And it’s only valuable if the trust boundary is drawn correctly. A Claude that has access to your relevant context is a superpower. A Claude that has access to everything you’ve ever written is a liability waiting to catch up with you.

    The whole article is about drawing that boundary on purpose.

    The two connection options (and which one you actually want)

    There are two ways to connect Claude to Notion in April 2026, and the right one depends on what you’re doing.

    Option 1: Remote MCP (Notion’s hosted server). You connect Claude — whether that’s Claude Desktop, Claude Code, or Claude.ai — to Notion’s hosted MCP endpoint at https://mcp.notion.com/mcp. You authenticate through OAuth, which opens a browser window, you approve the connection, and it’s live. Claude can now read from and write to your workspace based on your access and permissions.

    This is the officially-supported path. Notion’s own documentation explicitly calls remote MCP the preferred option, and the older open-source local server package is being deprecated in favor of it. For most operators, this is the right answer.

    Option 2: Local MCP (the legacy / open-source package). You install @notionhq/notion-mcp-server locally via npm, create an internal Notion integration to get an API token, and configure Claude to talk to the local server with your token. You then have to manually share each Notion page with the integration one by one — the integration only sees pages you explicitly grant access to.

    This path is more work and is being phased out. But there’s one genuine reason to still use it: the local path uses a token and the remote path uses OAuth, which means the local path works for headless automation where a human isn’t around to click OAuth buttons. Notion MCP requires user-based OAuth authentication and does not support bearer token authentication. This means a user must complete the OAuth flow to authorize access, which may not be suitable for fully automated workflows.

    For 95% of setups, remote MCP is the right answer. For the 5% running true headless agents, the local package is still the pragmatic choice even though it’s on its way out.

    The rest of this guide assumes remote MCP. I’ll flag the places the advice differs for local.

    The quiet part Notion tells you out loud

    Before we get to the setup, one more thing you need to internalize because it shapes every decision below.

    From Notion’s own help center: MCP tools act with your full Notion permissions — they can access everything you can access.

    Read that sentence twice.

    If you are a workspace member with access to 140 pages across 12 databases, your Claude connection can access 140 pages across 12 databases. Not the 15 you’re working on today. All of them. OAuth doesn’t scope you down to “this project.” It says yes or no to “can Claude see your workspace.”

    This is fine when your workspace is already organized the way you’d want an AI to see it. It is catastrophic when it isn’t, because most workspaces have accumulated years of drift, private notes, credential-adjacent content, sensitive client data, and old experiments that nobody bothered to clean up.

    So before you connect anything, you do the workspace audit. Not because Notion says so. Because your future self will thank you.

    The pre-connection audit (the step tutorials skip)

    Fifteen minutes with the workspace, before you click the OAuth button. Here’s the checklist I run through:

    Find anything that looks like a credential. Search your workspace for the words: password, API key, token, secret, bearer, private key, credentials. Read the results. Move anything sensitive to a credential manager (1Password, Bitwarden, a password-protected vault — not Notion). Delete the Notion copies.

    Find anything you wouldn’t want an AI to read. Search for: divorce, legal, lawsuit, personal, venting, complaint, therapist. Yes, really. People put things in Notion they’ve forgotten are in Notion. An AI that has access to everything you can access will find those things and occasionally surface them in responses. This is embarrassing at best and career-ending at worst.

    Look at your database of clients or contacts. Is there anything in there that shouldn’t travel through an AI provider’s servers? Notion processes MCP requests through Notion’s infrastructure, not yours. Sensitive legal matters, medical information, financial details about third parties — these may deserve a workspace or sub-page that stays outside of what Claude is allowed to see.

    Identify what Claude actually needs. Make a short list: your active projects, your working databases, your briefs page, your daily/weekly notes. This is what you actually want Claude to have context on. The rest is noise.

    Decide your posture. Two options here. You can run Claude against your main workspace and accept the blast radius, or you can create a separate workspace (or a teamspace) that contains only the pages and databases you want Claude to see, and connect Claude to that one. The second option is more work upfront. It is also the only version that actually draws the boundary.

    I run the second option. My Claude-facing workspace is genuinely a subset of what I work with, and the rest of my Notion is on a different membership. It took an hour to set up. It was worth it.

    Connecting remote MCP to Claude Desktop

    Now the mechanics. Starting with Claude Desktop because it’s the simplest.

    Claude Desktop gets Notion MCP through Settings → Connectors (not the older claude_desktop_config.json file, which is being phased out for remote MCP). This is available on Pro, Max, Team, and Enterprise plans.

    Open Claude Desktop. Settings → Connectors. Find Notion (or add a custom MCP server with the URL https://mcp.notion.com/mcp). Click Connect. A browser window opens, Notion asks you to authenticate, you approve. Done.

    The connection now lives in your Claude Desktop. You can start a new conversation and ask Claude to read a specific page, summarize a database, or draft something based on workspace content, and it will.

    One hygiene note: Claude Desktop connections are per-account. If you have multiple Claude accounts (say, a personal Pro and a work Max), each one needs its own connection to Notion. The good news is you can point each one at a different Notion workspace — personal Claude at personal Notion, work Claude at work Notion. This is the operator pattern I recommend for anyone running more than one business context through Claude.

    Connecting remote MCP to Claude Code

    Claude Code is the path most operators actually run at depth, because it’s the version of Claude that lives in your terminal and can compose MCP calls into real workflows.

    The command is one line:

    claude mcp add --transport http notion https://mcp.notion.com/mcp

    Need this set up for your team?

    I set up Claude integrations, GCP infrastructure, and AI workflows for businesses. If you’d rather ship than configure — will@tygartmedia.com

    Then authenticate by running /mcp inside Claude Code and following the OAuth flow. Browser opens, Notion asks you to authorize, you approve, and the connection is live.

    A few options worth knowing about at setup time:

    Scope. The --scope flag controls who gets access to the MCP server on your machine. Three options: local (default, just you in the current project), project (shared with your team via a .mcp.json file), and user (available to you across all projects). For Notion, user scope is usually right — you’ll want Claude to reach Notion from any project you’re working in, not just the current one.

    The richer integration. Notion also ships a plugin for Claude Code that bundles the MCP server along with pre-built Skills and slash commands for common Notion workflows. If you’re doing this seriously, install the plugin. It adds commands like generating briefs from templates and opening pages by name, and saves you from writing your own.

    Checking what’s connected. Inside Claude Code, /mcp lists every MCP server you’ve configured. /context tells you how many tokens each one is consuming in your current session. For Notion specifically, this is useful because MCP servers have non-zero context cost even when you’re not actively using them — every tool exposed by the server sits in Claude’s context, eating tokens. Running /context occasionally is how you notice when an MCP connection is heavier than you expected.

    The permissions pattern that actually protects you

    Now we’re past the mechanics and into the hygiene layer — the part that most guides don’t cover.

    Once Claude is connected to your Notion workspace, there are three specific configuration moves worth making. None of them are hard. All of them pay rent.

    1. Scope the workspace, don’t scope the connection

    The OAuth connection doesn’t let you say “Claude can see these pages but not those.” It lets you say “Claude can see this workspace.” So the place to draw the boundary is at the workspace level, not at the connection level.

    If you have sensitive content in your main workspace, move it. Create a separate workspace for Claude-facing content and keep the sensitive stuff out. Or use Notion’s teamspace feature (Business and Enterprise) to isolate access at the teamspace level.

    This feels like over-engineering until the first time Claude surfaces something in a response that you had forgotten was in your workspace. After that, it doesn’t feel like over-engineering.

    2. For Enterprise: turn on MCP Governance

    If you’re on the Enterprise plan, there’s an admin-level control worth enabling even if you trust your team. From Notion’s docs: with MCP Governance, Enterprise admins can approve specific AI tools and MCP clients that can connect to Notion MCP — for example Cursor, Claude, or ChatGPT. The approved-list pattern is opt-in: Settings → Connections → Permissions tab, set “Restrict AI tools members can connect to” to “Only from approved list.”

    Even if you only approve Claude today, the control gives you the ability to see every AI tool anyone on your team has connected, and to disconnect everything at once with the “Disconnect All Users” button if you ever need to. That’s the kind of control you want to have configured before you need it, not after.

    3. For local MCP: use a read-only integration token

    If you’re using the local path (the open-source @notionhq/notion-mcp-server), you have more granular control than the remote path gives you. Specifically: when you create the integration in Notion’s developer settings, you can set it to “Read content” only — no write access, no comment access, nothing but reads.

    A read-only integration is the right default for anything exploratory. If you want Claude to be able to write too, enable write access later when you’ve decided you trust the specific workflow. Don’t give write access by default just because the integration setup screen presents it as an option.

    This is the one place the local path is actually stronger than remote — you can shape the integration’s capabilities before you grant it access, and the integration only sees the specific pages you share with it. For high-sensitivity setups, this granularity is worth the tradeoff of running the legacy package.

    Prompt injection: the risk nobody wants to talk about

    One more thing before we leave the hygiene section. It’s the thing the industry is least comfortable being direct about.

    When Claude has access to your Notion workspace, Claude also reads whatever is in your Notion workspace. Including pages that came from outside. Including meeting notes that were imported from a transcript service. Including documents shared with you by clients. Including anything you pasted from the web.

    Every one of those is a potential vector for prompt injection — hidden instructions buried in content that, when Claude reads the content, hijack what Claude does next.

    This is not theoretical. Anthropic itself flags prompt injection risk in the MCP documentation: be especially careful when using MCP servers that could fetch untrusted content, as these can expose you to prompt injection risk. Notion has shipped detection for hidden instructions in uploaded files and flags suspicious links for user approval, but the attack surface is larger than any detection system can fully cover.

    The practical operator response is three-part:

    Don’t give Claude access to content you didn’t write, without reading it first. If a client sends you a document and you paste it into Notion and Claude has access to that database, you have effectively given Claude the ability to be instructed by your client’s document. This might be fine. It might be a problem. Read the document before it goes into a Claude-accessible location.

    Be suspicious of workflows that chain untrusted content into actions. A workflow where Claude reads a web-scraped summary and then uses that summary to decide which database row to update is a prompt injection target. If the scraped content can shape Claude’s action, the scraped content can be weaponized.

    Use write protections for anything consequential. Anything where the cost of Claude doing the wrong thing is real — sending an email, deleting a record, updating a client-facing page — belongs behind a human-approval gate. Claude Code supports “Always Ask” behavior per-tool; use it for writes.

    This sounds paranoid. It’s not paranoid. It’s the appropriate level of caution for a class of attack that is genuinely live and that the industry has not yet figured out how to fully defend against.

    What this actually enables (the payoff section)

    Once you’ve done the setup and the hygiene work, here’s what you now have.

    You can sit down at Claude and ask it questions that require real workspace context. What’s the status of the three projects I touched last week? Pull together everything we’ve decided about pricing across the client work this quarter. Draft a response to this incoming email using context from our ongoing conversation with this client. Claude reads the relevant pages, synthesizes across them, and responds with actual grounding — not a generic answer shaped by whatever prompt you happen to type.

    You can run Claude Code against your workspace for development-adjacent operations. Generate a technical spec from our product page notes. Create release notes from the changelog and feature pages. Find every page where we’ve documented this API endpoint and reconcile the inconsistencies.

    You can set up workflows that flow across tools. Claude reads from Notion, acts on another system via a different MCP server, writes results back to Notion. This is the agentic pattern the industry keeps talking about — and with the right permissions hygiene, it actually becomes usable instead of scary.

    None of this is theoretical. I use this pattern every working day. The value is real. The hygiene discipline is what keeps the value from turning into a liability.

    When this setup goes wrong (troubleshooting honestly)

    Five failure modes I’ve seen, in order of frequency.

    Claude doesn’t see the page you asked about. For remote MCP, this almost always means the page is in a workspace you’re not a member of, or in a teamspace you don’t have access to. For local MCP, it means the integration hasn’t been granted access to that specific page — you have to go to the page, click the three-dot menu, and add the integration manually.

    OAuth flow doesn’t complete. Usually a browser issue — popup blocker, wrong Notion account signed in, session expired. Clear auth, try again. If Claude Desktop, disconnect the connector entirely and re-add.

    The connection succeeds but Claude doesn’t seem to be using it. Run /mcp in Claude Code to verify the server is listed and connected. If it’s there and Claude still isn’t invoking it, the issue is usually in how you’re asking — Claude won’t reach for MCP tools just because they exist; you need to phrase the request in a way that makes it obvious the tool is relevant. Find the page about X in Notion works better than tell me about X.

    MCP server crashes or returns errors. For remote, this is rare and usually resolves itself — Notion’s hosted server has the standard cloud-reliability profile. For local, check your Node version (the server requires Node 18 or later), your config file syntax (JSON is unforgiving about trailing commas), and your token format.

    Context token budget goes through the roof. Every MCP server in your connected list contributes tools to Claude’s context on every request. If you have five MCP servers configured, that’s five sets of tool descriptions being loaded into every conversation. Run /context in Claude Code to see the cost. If it’s painful, disconnect the servers you’re not actively using.

    The mental model that keeps you sane

    Here’s the mental model I use for the whole setup. It’s short.

    Claude plus Notion is like giving a new, very capable employee access to your business. You wouldn’t hand a new hire every password, every file, every client record, every private note on day one. You’d give them access to the specific things they need to do the job, watch how they use that access, and expand trust over time based on track record.

    The MCP connection works exactly that way. You decide what Claude gets to see. You decide what Claude gets to write. You watch how it uses that access. You expand the boundary as trust earns itself.

    The operators who get hurt by this kind of setup are the ones who skip the first step and give Claude everything on day one. The operators who get the real value out of it are the ones who treat the connection the way they’d treat any other employee — with deliberate scope, real oversight, and the willingness to revoke access if something goes wrong.

    That’s the discipline. That’s the whole thing.

    FAQ

    Do I need to install anything to connect Claude to Notion? For remote MCP (the recommended path), no installation is required — you connect via OAuth through Claude Desktop’s Settings → Connectors or Claude Code’s claude mcp add command. For local MCP (legacy), you install @notionhq/notion-mcp-server via npm and create an internal Notion integration.

    What’s the URL for Notion’s remote MCP server? https://mcp.notion.com/mcp. Use HTTP transport (not the deprecated SSE transport).

    Can Claude see my entire Notion workspace by default? Yes. MCP tools act with your full Notion permissions — they can access everything you can access. The boundary is set by your workspace membership and teamspace access, not by the MCP connection itself. If you need finer-grained control, isolate Claude-facing content into a separate workspace or teamspace.

    Can I use Notion MCP with automated, headless agents? Remote Notion MCP requires OAuth authentication and doesn’t support bearer tokens, which makes it unsuitable for fully automated or headless workflows. For those cases, the legacy @notionhq/notion-mcp-server with an API token still works, but it’s being phased out.

    What plans support Notion MCP? Notion MCP works with all plans for connecting AI tools via MCP. Enterprise plans get admin-level MCP Governance controls (approved AI tool list, disconnect-all). Claude Desktop MCP connectors are available on Pro, Max, Team, and Enterprise plans.

    Can my company’s admins control which AI tools connect to our Notion workspace? Yes, on the Enterprise plan. Admins can restrict AI tool connections to an approved list through Settings → Connections → Permissions tab. Only admin-approved tools can connect.

    Is Notion MCP secure for confidential business data? The MCP protocol itself respects Notion’s permissions — it can’t bypass what you have access to. However, content flowing through MCP is processed by the AI tool you’ve connected (Claude, ChatGPT, etc.), which has its own data handling policies. For highly sensitive content, the right move is to isolate it in a workspace that Claude doesn’t have access to, rather than relying on the protocol alone to contain it.

    What about prompt injection attacks through Notion content? Real risk. Anthropic explicitly flags it in their MCP documentation. Notion has shipped detection for hidden instructions and flags suspicious links, but no detection system catches everything. The operator response: don’t give Claude access to content you didn’t write without reviewing it first, be suspicious of workflows where untrusted content shapes Claude’s actions, and put human-approval gates on anything consequential.

    What’s the difference between Notion’s built-in AI and connecting Claude via MCP? Notion’s built-in AI (Notion Agent and Custom Agents) runs inside Notion and uses Notion’s integration with frontier models. Connecting Claude via MCP brings Claude — your chosen model, in your chosen interface, with its full capability — to your workspace as an external client. The built-in option is simpler; the MCP option is more powerful and composable across other tools.

    Closing note

    Most tutorials treat the connection as the goal. The connection is the easy part. The hygiene is the part that matters.

    If you wire Claude into your Notion workspace thoughtlessly, you’ve given a capable AI access to every corner of your operational history, and you’ll be surprised how much of what’s in there you’d forgotten. If you wire it in deliberately — with a scoped workspace, with the permissions you’ve thought about, with the posture of giving a new employee measured access — you’ve built something that pays rent every day without ever becoming the liability it could have been.

    One hour of setup. One hour of cleanup. And then one of the most useful AI configurations currently possible in April 2026.

    The intersection of Notion and Claude is where the operator work actually happens now. Worth setting up right.

    Sources and further reading

  • The CLAUDE.md Playbook: How to Actually Guide Claude Code Across a Real Project (2026)

    The CLAUDE.md Playbook: How to Actually Guide Claude Code Across a Real Project (2026)

    Last refreshed: May 15, 2026

    Most writing about CLAUDE.md gets one thing wrong in the first paragraph, and once you notice it, you can’t unsee it. People describe it as configuration. A “project constitution.” Rules Claude has to follow.

    It isn’t any of those things, and Anthropic is explicit about it.

    CLAUDE.md content is delivered as a user message after the system prompt, not as part of the system prompt itself. Claude reads it and tries to follow it, but there’s no guarantee of strict compliance, especially for vague or conflicting instructions. — Anthropic, Claude Code memory docs

    That one sentence is the whole game. If you write a CLAUDE.md as if you’re programming a machine, you’ll get frustrated when the machine doesn’t comply. If you write it as context — the thing a thoughtful new teammate would want to read on day one — you’ll get something that works.

    This is the playbook I wish someone had handed me the first time I set one up across a real codebase. It’s grounded in Anthropic’s current documentation (linked throughout), layered with patterns I’ve used across a network of production repos, and honest about where community practice has outrun official guidance.

    If any of this ages out, the docs are the source of truth. Start there, come back here for the operator layer.

    The memory stack in 2026 (what CLAUDE.md actually is, and isn’t)

    Claude Code’s memory system has three parts. Most people know one of them, and the other two change how you use the first.

    CLAUDE.md files are markdown files you write by hand. Claude reads them at the start of every session. They contain instructions you want Claude to carry across conversations — build commands, coding standards, architectural decisions, “always do X” rules. This is the part people know.

    Auto memory is something Claude writes for itself. Introduced in Claude Code v2.1.59, it lets Claude save notes across sessions based on your corrections — build commands it discovered, debugging insights, preferences you kept restating. It lives at ~/.claude/projects/<project>/memory/ with a MEMORY.md entrypoint. You can audit it with /memory, edit it, or delete it. It’s on by default. (Anthropic docs.)

    .claude/rules/ is a directory of smaller, topic-scoped markdown files — code-style.md, testing.md, security.md — that can optionally be scoped to specific file paths via YAML frontmatter. A rule with paths: ["src/api/**/*.ts"] only loads when Claude is working with files matching that pattern. (Anthropic docs.)

    The reason this matters for how you write CLAUDE.md: once you understand what the other two are for, you stop stuffing CLAUDE.md with things that belong somewhere else. A 600-line CLAUDE.md isn’t a sign of thoroughness. It’s usually a sign the rules directory doesn’t exist yet and auto memory is disabled.

    Anthropic’s own guidance is explicit: target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.

    Hold that number. We’ll come back to it.

    Where CLAUDE.md lives (and why scope matters)

    CLAUDE.md files can live in four different scopes, each with a different purpose. More specific scopes take precedence over broader ones. (Full precedence table in Anthropic docs.)

    Managed policy CLAUDE.md lives at the OS level — /Library/Application Support/ClaudeCode/CLAUDE.md on macOS, /etc/claude-code/CLAUDE.md on Linux and WSL, C:\Program Files\ClaudeCode\CLAUDE.md on Windows. Organizations deploy it via MDM, Group Policy, or Ansible. It applies to every user on every machine it’s pushed to, and individual settings cannot exclude it. Use it for company-wide coding standards, security posture, and compliance reminders.

    Project CLAUDE.md lives at ./CLAUDE.md or ./.claude/CLAUDE.md. It’s checked into source control and shared with the team. This is the one you’re writing when someone says “set up CLAUDE.md for this repo.”

    User CLAUDE.md lives at ~/.claude/CLAUDE.md. It’s your personal preferences across every project on your machine — favorite tooling shortcuts, how you like code styled, patterns you want applied everywhere.

    Local CLAUDE.md lives at ./CLAUDE.local.md in the project root. It’s personal-to-this-project and gitignored. Your sandbox URLs, preferred test data, notes Claude should know that your teammates shouldn’t see.

    Claude walks up the directory tree from wherever you launched it, concatenating every CLAUDE.md and CLAUDE.local.md it finds. Subdirectories load on demand — they don’t hit context at launch, but get pulled in when Claude reads files in those subdirectories. (Anthropic docs.)

    A practical consequence most teams miss: in a monorepo, your parent CLAUDE.md gets loaded when a teammate runs Claude Code from inside a nested package. If that parent file contains instructions that don’t apply to their work, Claude will still try to follow them. That’s what the claudeMdExcludes setting is for — it lets individuals skip CLAUDE.md files by glob pattern at the local settings layer.

    If you’re running Claude Code across more than one repo, decide now whether your standards belong in project CLAUDE.md (team-shared) or user CLAUDE.md (just you). Writing the same thing in both is how you get drift.

    The 200-line discipline

    This is the rule I see broken most often, and it’s the rule Anthropic is most explicit about. From the docs: “target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.”

    Two things are happening in that sentence. One, CLAUDE.md eats tokens — every session, every time, whether Claude needed those tokens or not. Two, longer files don’t actually produce better compliance. The opposite. When instructions are dense and undifferentiated, Claude can’t tell which ones matter.

    The 200-line ceiling isn’t a hard cap. You can write a 400-line CLAUDE.md and Claude will load the whole thing. It just won’t follow it as well as a 180-line file would.

    Three moves to stay under:

    1. Use @imports to pull in specific files when they’re relevant. CLAUDE.md supports @path/to/file syntax (relative or absolute). Imported files expand inline at session launch, up to five hops deep. This is how you reference your README, your package.json, or a standalone workflow guide without pasting them into CLAUDE.md.

    See @README.md for architecture and @package.json for available scripts.

# Git Workflow
- @docs/git-workflow.md

    2. Move path-scoped rules into .claude/rules/. Anything that only matters when working with a specific part of the codebase — API patterns, testing conventions, frontend style — belongs in .claude/rules/api.md or .claude/rules/testing.md with a paths: frontmatter. They only load into context when Claude touches matching files.

    ---
paths:
  - "src/api/**/*.ts"
---
# API Development Rules

- All API endpoints must include input validation
- Use the standard error response format
- Include OpenAPI documentation comments

    3. Move task-specific procedures into skills. If an instruction is really a multi-step workflow — “when you’re asked to ship a release, do these eight things” — it belongs in a skill, which only loads when invoked. CLAUDE.md is for the facts Claude should always hold in context; skills are for procedures Claude should run when the moment calls for them.

    If you follow these three moves, a CLAUDE.md rarely needs to exceed 150 lines. At that size, Claude actually reads it.

    What belongs in CLAUDE.md (the signal test)

    Anthropic’s own framing for when to add something is excellent, and it’s worth quoting directly because it captures the whole philosophy in four lines:

    Add to it when:

    • Claude makes the same mistake a second time
    • A code review catches something Claude should have known about this codebase
    • You type the same correction or clarification into chat that you typed last session
    • A new teammate would need the same context to be productive — Anthropic docs

    The operator version of the same principle: CLAUDE.md is the place you write down what you’d otherwise re-explain. It’s not the place you write down everything you know. If you find yourself writing “the frontend is built in React and uses Tailwind,” ask whether Claude would figure that out by reading package.json (it would). If you find yourself writing “when a user asks for a new endpoint, always add input validation and write a test,” that’s the kind of thing Claude won’t figure out on its own — it’s a team convention, not an inference from the code.

    The categories I’ve found actually earn their place in a project CLAUDE.md:

    Build and test commands. The exact string to run the dev server, the test suite, the linter, the type checker. Every one of these saves Claude a round of “let me look for a package.json script.”

    Architectural non-obvious. The thing a new teammate would need someone to explain. “This repo uses event sourcing — don’t write direct database mutations, emit events instead.” “We have two API surfaces, /public/* and /internal/*, and they have different auth requirements.”

    Naming conventions and file layout. “API handlers live in src/api/handlers/.” “Test files go next to the code they test, named *.test.ts.” Specific enough to verify.

    Coding standards that matter. Not “write good code” — “use 2-space indentation,” “prefer const over let,” “always export types separately from values.”

    Recurring corrections. The single most valuable category. Every time you find yourself re-correcting Claude about the same thing, that correction belongs in CLAUDE.md.

    What usually doesn’t belong:

    • Long lists of library choices (Claude can read package.json)
    • Full architecture diagrams (link to them instead)
    • Step-by-step procedures (skills)
    • Path-specific rules that only matter in one part of the repo (.claude/rules/ with a paths: field)
    • Anything that would be true of any project (that goes in user CLAUDE.md)

    Writing instructions Claude will actually follow

    Anthropic’s own guidance on effective instructions comes down to three principles, and every one of them is worth taking seriously:

    Specificity. “Use 2-space indentation” works better than “format code nicely.” “Run npm test before committing” works better than “test your changes.” “API handlers live in src/api/handlers/” works better than “keep files organized.” If the instruction can’t be verified, it can’t be followed reliably.

    Consistency. If two rules contradict each other, Claude may pick one arbitrarily. This is especially common in projects that have accumulated CLAUDE.md files across multiple contributors over time — one file says to prefer async/await, another says to use .then() for performance reasons, and nobody remembers which was right. Do a periodic sweep.

    Structure. Use markdown headers and bullets. Group related instructions. Dense paragraphs are harder to scan, and Claude scans the same way you do. A CLAUDE.md with clear section headers — ## Build Commands, ## Coding Style, ## Testing — outperforms the same content run together as prose.

    One pattern I’ve found useful that isn’t in the docs: write CLAUDE.md in the voice of a teammate briefing another teammate. Not “use 2-space indentation” but “we use 2-space indentation.” Not “always include input validation” but “every endpoint needs input validation — we had a security incident last year and this is how we prevent the next one.” The “why” is optional but it improves adherence because Claude treats the rule as something with a reason behind it, not an arbitrary preference.

    Community patterns worth knowing (flagged as community, not official)

    The following are patterns I’ve seen in operator circles and at industry events like AI Engineer Europe 2026, where practitioners share how they’re running Claude Code in production. None of these are in Anthropic’s documentation as official guidance. I’ve included them because they’re useful; I’m flagging them because they’re community-origin, not doctrine. Your mileage may vary, and Anthropic’s official behavior could change in ways that affect these patterns.

    The “project constitution” framing. Community shorthand for treating CLAUDE.md as the living document of architectural decisions — the thing new contributors read to understand how the project thinks. The framing is useful even though Anthropic doesn’t use the word. It captures the right posture: CLAUDE.md is the place for the decisions you want to outlast any individual conversation.

    Prompt-injecting your own codebase via custom linter errors. Reported at AI Engineer Europe 2026: some teams embed agent-facing prompts directly into their linter error messages, so when an automated tool catches a mistake, the error text itself tells the agent how to fix it. Example: instead of a test failing with “type mismatch,” the error reads “You shouldn’t have an unknown type here because we parse at the edge — use the parsed type from src/schemas/.” This is not documented Anthropic practice; it’s a community pattern that works because Claude Code reads tool output and tool output flows into context. Use with judgment.

    File-size lint rules as context-efficiency guards. Some teams enforce file-size limits (commonly cited: 350 lines max) via their linters, with the explicit goal of keeping files small enough that Claude can hold meaningful ones in context without waste. Again, community practice. The number isn’t magic; the discipline is.

    Token Leverage as a team metric. The idea that teams should track token spend ÷ human labor spend as a ratio and try to scale it. This is business-strategy content, not engineering guidance, and it’s emerging community discourse rather than settled practice. Take it as a thought experiment, not a KPI to implement by Monday.

    I’d rather flag these honestly than pretend they’re settled. If something here graduates from community practice to official recommendation, I’ll update.

    Enterprise: managed-policy CLAUDE.md (and when to use settings instead)

    For organizations deploying Claude Code across teams, there’s a managed-policy CLAUDE.md that applies to every user on a machine and cannot be excluded by individual settings. It lives at /Library/Application Support/ClaudeCode/CLAUDE.md (macOS), /etc/claude-code/CLAUDE.md (Linux and WSL), or C:\Program Files\ClaudeCode\CLAUDE.md (Windows), and is deployed via MDM, Group Policy, Ansible, or similar.

    The distinction that matters most for enterprise: managed CLAUDE.md is guidance, managed settings are enforcement. Anthropic is clear about this. From the docs:

    Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude’s behavior but are not a hard enforcement layer. — Anthropic docs

    If you need to guarantee that Claude Code can’t read .env files or write to /etc, that’s a managed settings concern (permissions.deny). If you want Claude to be reminded of your company’s code review standards, that’s managed CLAUDE.md. If you confuse the two and put your security policy in CLAUDE.md, you have a strongly-worded suggestion where you needed a hard wall.

    Building With Claude?

    I’ll send you the CLAUDE.md cheat sheet personally.

    If you’re in the middle of a real project and this playbook is helping — or raising more questions — just email me. I read every message.

    Email Will → will@tygartmedia.com

    The right mental model:

    Concern Configure in
    Block specific tools, commands, or file paths Managed settings (permissions.deny)
    Enforce sandbox isolation Managed settings (sandbox.enabled)
    Authentication method, organization lock Managed settings
    Environment variables, API provider routing Managed settings
    Code style and quality guidelines Managed CLAUDE.md
    Data handling and compliance reminders Managed CLAUDE.md
    Behavioral instructions for Claude Managed CLAUDE.md

    (Full table in Anthropic docs.)

    One practical note: managed CLAUDE.md ships to developer machines once, so it has to be right. Review it, version it, and treat changes to it the way you’d treat changes to a managed IDE configuration — because that’s what it is.

    The living document problem: auto memory, CLAUDE.md, and drift

    The thing that changed most in 2026 is that Claude now writes memory for itself when auto memory is enabled (on by default since Claude Code v2.1.59). It saves build commands it discovered, debugging insights, preferences you expressed repeatedly — and loads the first 200 lines (or 25KB) of its MEMORY.md at every session start. (Anthropic docs.)

    This changes how you think about CLAUDE.md in two ways.

    First, you don’t need to write CLAUDE.md entries for everything Claude could figure out on its own. If you tell Claude once that the build command is pnpm run build --filter=web, auto memory might save that, and you won’t need to codify it in CLAUDE.md. The role of CLAUDE.md becomes more specifically about what the team has decided, rather than what the tool needs to know to function.

    Second, there’s a new audit surface. Run /memory in a session and you can see every CLAUDE.md, CLAUDE.local.md, and rules file being loaded, plus a link to open the auto memory folder. The auto memory files are plain markdown. You can read, edit, or delete them.

    A practical auto-memory hygiene pattern I’ve landed on:

    • Once a month, open /memory and skim the auto memory folder. Anything stale or wrong gets deleted.
    • Quarterly, review the CLAUDE.md itself. Has anything changed in how the team works? Are there rules that used to matter but don’t anymore? Conflicting instructions accumulate faster than you think.
    • Whenever a rule keeps getting restated in conversation, move it from conversation to CLAUDE.md. That’s the signal Anthropic’s own docs describe, and it’s the right one.

    CLAUDE.md files are living documents or they’re lies. A CLAUDE.md from six months ago that references libraries you’ve since replaced will actively hurt you — Claude will try to follow instructions that no longer apply.

    A representative CLAUDE.md template

    What follows is a synthetic example, clearly not any specific project. It demonstrates the shape, scope, and discipline of a good project CLAUDE.md. Adapt it to your codebase. Keep it under 200 lines.

    # Project: [Name]

## Overview
Brief one-paragraph description of what this project is and who uses it.
Link to deeper architecture docs rather than duplicating them here.

See @README.md for full architecture.

## Build and Test Commands
- Install: `pnpm install`
- Dev server: `pnpm run dev`
- Build: `pnpm run build`
- Test: `pnpm test`
- Type check: `pnpm run typecheck`
- Lint: `pnpm run lint`

Run `pnpm run typecheck` and `pnpm test` before committing. Both must pass.

## Tech Stack
(Only list the non-obvious choices. Claude can read package.json.)
- We use tRPC, not REST, for internal APIs.
- Styling is Tailwind with a custom token file at `src/styles/tokens.ts`.
- Database migrations via Drizzle, not Prisma (migrated in Q1 2026).

## Directory Layout
- `src/api/` — tRPC routers, grouped by domain
- `src/components/` — React components, one directory per component
- `src/lib/` — shared utilities, no React imports allowed here
- `src/server/` — server-only code, never imported from client
- `tests/` — integration tests (unit tests live next to source)

## Coding Conventions
- TypeScript strict mode. No `any` without a comment explaining why.
- Functional components only. No class components.
- Imports ordered: external, internal absolute, relative.
- 2-space indentation. Prettier config in `.prettierrc`.

## Conventions That Aren't Obvious
- Every API endpoint validates input with Zod. No exceptions.
- Database queries go through the repository layer in `src/server/repos/`. 
  Never import Drizzle directly from route handlers.
- Errors surfaced to the UI use the `AppError` class from `src/lib/errors.ts`.
  This preserves error codes for the frontend to branch on.

## Common Corrections
- Don't add new top-level dependencies without discussing first.
- Don't create new files in `src/lib/` without checking if a similar 
  utility already exists.
- Don't write tests that hit the real database. Use the test fixtures 
  in `tests/fixtures/`.

## Further Reading
- API design rules: @.claude/rules/api.md
- Testing conventions: @.claude/rules/testing.md
- Security: @.claude/rules/security.md

    That’s roughly 70 lines. Notice what it doesn’t include: no multi-step procedures, no duplicated information from package.json, no universal-best-practice lectures. Every line is either a command you’d otherwise re-type, a convention a new teammate would need briefed, or a pointer to a more specific document.

    When CLAUDE.md still isn’t being followed

    This happens to everyone eventually. Three debugging steps, in order:

    1. Run /memory and confirm your file is actually loaded. If CLAUDE.md isn’t in the list, Claude isn’t reading it. Check the path — project CLAUDE.md can live at ./CLAUDE.md or ./.claude/CLAUDE.md, not both, not a subdirectory (unless Claude happens to be reading files in that subdirectory).

    2. Make the instruction more specific. “Write clean code” is not an instruction Claude can verify. “Use 2-space indentation” is. “Handle errors properly” is not an instruction. “All errors surfaced to the UI must use the AppError class from src/lib/errors.ts” is.

    3. Look for conflicting instructions. A project CLAUDE.md saying “prefer async/await” and a .claude/rules/performance.md saying “use raw promises for hot paths” will cause Claude to pick one arbitrarily. In monorepos this is especially common — an ancestor CLAUDE.md from a different team can contradict yours. Use claudeMdExcludes to skip irrelevant ancestors.

    If you need guarantees rather than guidance — “Claude cannot, under any circumstances, delete this directory” — that’s a settings-level permissions concern, not a CLAUDE.md concern. Write the rule in settings.json under permissions.deny and the client enforces it regardless of what Claude decides.

    FAQ

    What is CLAUDE.md? A markdown file Claude Code reads at the start of every session to get persistent instructions for a project. It lives in a project’s source tree (usually at ./CLAUDE.md or ./.claude/CLAUDE.md), gets loaded into the context window as a user message after the system prompt, and contains coding standards, build commands, architectural decisions, and other team-level context. Anthropic is explicit that it’s guidance, not enforcement. (Source.)

    How long should a CLAUDE.md be? Under 200 lines. Anthropic’s own guidance is that longer files consume more context and reduce adherence. If you’re over that, split with @imports or move topic-specific rules into .claude/rules/.

    Where should CLAUDE.md live? Project-level: ./CLAUDE.md or ./.claude/CLAUDE.md, checked into source control. Personal-global: ~/.claude/CLAUDE.md. Personal-project (gitignored): ./CLAUDE.local.md. Organization-wide (enterprise): /Library/Application Support/ClaudeCode/CLAUDE.md (macOS), /etc/claude-code/CLAUDE.md (Linux/WSL), or C:\Program Files\ClaudeCode\CLAUDE.md (Windows).

    What’s the difference between CLAUDE.md and auto memory? CLAUDE.md is instructions you write for Claude. Auto memory is notes Claude writes for itself across sessions, stored at ~/.claude/projects/<project>/memory/. Both load at session start. CLAUDE.md is for team standards; auto memory is for build commands and preferences Claude picks up from your corrections. Auto memory requires Claude Code v2.1.59 or later.

    Can Claude ignore my CLAUDE.md? Yes. CLAUDE.md is loaded as a user message and Claude “reads it and tries to follow it, but there’s no guarantee of strict compliance.” For hard enforcement (blocking file access, sandbox isolation, etc.) use settings, not CLAUDE.md.

    Does AGENTS.md work for Claude Code? Claude Code reads CLAUDE.md, not AGENTS.md. If your repo already uses AGENTS.md for other coding agents, create a CLAUDE.md that imports it with @AGENTS.md at the top, then append Claude-specific instructions below.

    What’s .claude/rules/ and when should I use it? A directory of smaller, topic-scoped markdown files that can optionally be scoped to specific file paths via YAML frontmatter. Use it when your CLAUDE.md is getting long or when instructions only matter in part of the codebase. Rules without a paths: field load at session start with the same priority as .claude/CLAUDE.md; rules with a paths: field only load when Claude works with matching files.

    How do I generate a starter CLAUDE.md? Run /init inside Claude Code. It analyzes your codebase and produces a starting file with build commands, test instructions, and conventions it discovers. Refine from there with instructions Claude wouldn’t discover on its own.

    A closing note

    The biggest mistake I see people make with CLAUDE.md isn’t writing it wrong — it’s writing it once and forgetting it exists. Six months later it references libraries they’ve since replaced, conventions that have since shifted, and a team structure that has since reorganized. Claude dutifully tries to follow instructions that no longer apply, and the team wonders why the tool seems to have gotten worse.

    CLAUDE.md is a living document or it’s a liability. Treat it the way you’d treat a critical piece of onboarding documentation, because functionally that’s exactly what it is — onboarding for the teammate who shows up every session and starts from zero.

    Write it for that teammate. Keep it short. Update it when reality shifts. And remember the part nobody likes to admit: it’s guidance, not enforcement. For anything that has to be guaranteed, reach for settings instead.

    Sources and further reading

    Community patterns referenced in this piece were reported at AI Engineer Europe 2026 and captured in a session recap. They represent emerging practice, not Anthropic doctrine.

  • Knowledge Cluster VM Setup — 5-Site WordPress Network on GCP Compute Engine

    Knowledge Cluster VM Setup — 5-Site WordPress Network on GCP Compute Engine

    The Lab · Tygart Media
    Experiment Nº 707 · Methodology Notes
    METHODS · OBSERVATIONS · RESULTS

    What Is a Knowledge Cluster VM?
    A Knowledge Cluster VM is a single GCP Compute Engine instance running five WordPress sites on a shared LAMP stack — each site with its own domain, SSL certificate, and WordPress installation, all managed from one server with Claude Code deployed for AI-assisted content operations. Five sites, one VM, unified content architecture, fraction of the cost of five separate hosting accounts.

    Running five WordPress sites on five separate managed hosting accounts costs $200–$500/month and gives you five completely isolated environments with no shared infrastructure, no shared AI tooling, and no economies of scale. A dedicated GCP VM changes the math: one e2-standard-2 instance runs all five sites for around $30–$50/month, with Claude Code deployed directly on the server for zero-latency AI content operations.

    We run our own 5-site knowledge cluster this way — restorationintel.com, riskcoveragehub.com, continuityhub.org, bcesg.org, and healthcarefacilityhub.org are all on one VM. The hub-and-spoke content architecture connects them intentionally: each site covers a different facet of a shared knowledge domain, and internal cross-linking amplifies authority across all five.

    Who This Is For

    Operators building a network of related WordPress sites — knowledge hubs, geo-local networks, topic clusters across related domains — who want shared infrastructure, lower hosting costs, and a unified AI content operation rather than five separate managed accounts.

    What We Build

    • GCP Compute Engine VM — e2-standard-2 (2 vCPU, 8GB RAM) or larger depending on traffic requirements, configured in us-west1 or your preferred region
    • Shared LAMP stack — Apache with virtual hosts, MySQL with separate databases per site, PHP 8.x configured for WordPress
    • Five WordPress installations — Each in its own directory, individual wp-config, separate database credentials
    • SSL certificates — Certbot/Let’s Encrypt for all five domains with auto-renewal configured
    • Claude Code deployment — Anthropic API key stored in GCP Secret Manager, Claude Code installed and configured for WP-CLI integration
    • Hub-and-spoke content map — Architecture document defining which site is the hub, which are spokes, and the interlinking strategy
    • WP-CLI batch scripts — Common operations (plugin updates, bulk post operations, taxonomy management) scripted for all five sites

    What We Deliver

    Item Included
    GCP VM provisioning and configuration ✅
    5 WordPress installations with SSL ✅
    Shared LAMP stack with Apache virtual hosts ✅
    Claude Code deployment + GCP Secret Manager integration ✅
    Hub-and-spoke content architecture document ✅
    WP-CLI batch operation scripts ✅
    Monitoring + auto-restart configuration ✅
    Technical handoff documentation ✅

    Ready to Consolidate 5 Sites onto One Smart Server?

    Share the 5 domains you want to host and your current monthly hosting cost. We’ll scope the VM build and show you the cost reduction.

    → will@tygartmedia.com

    Email only. No commitment to reply.

    Frequently Asked Questions

    What happens if the VM goes down?

    GCP Compute Engine has 99.9% uptime SLA. We configure automatic restart policies and GCP’s built-in monitoring with alerting. For production sites with stricter uptime requirements, we can add a load balancer with health checks.

    How is this different from WordPress Multisite?

    WordPress Multisite shares a single WordPress installation across all sites — changes to plugins or core affect all sites simultaneously and customization is limited. The cluster uses five independent WordPress installations that share only the server hardware. Each site is fully independent.

    Can more than 5 sites run on one VM?

    Yes — an e2-standard-2 instance comfortably handles 8–10 low-to-medium traffic WordPress sites. We scale the VM size based on your traffic requirements. The architecture pattern works for 3–15 sites.


    Last updated: April 2026

  • Claude Code vs Cursor: Which AI Coding Tool Is Better in 2026?

    Claude Code vs Cursor: Which AI Coding Tool Is Better in 2026?

    Last refreshed: May 15, 2026

    Claude AI · Fitted Claude

    Claude Code and Cursor are both AI coding tools with serious developer followings — but they’re built on fundamentally different models. Cursor is an AI-powered IDE fork. Claude Code is a terminal-native agent. The right choice depends on how you work.

    Short answer: Cursor wins for in-editor experience — autocomplete, inline suggestions, and staying inside VS Code’s familiar interface. Claude Code wins for autonomous multi-step tasks — it operates at the system level, can run commands, manage files across the whole project, and doesn’t require you to be watching. Most serious developers end up using both.

    Claude Code vs Cursor: Head-to-Head

    Capability Claude Code Cursor Edge
    In-editor autocomplete Limited ✅ Native Cursor
    Autonomous multi-file tasks ✅ Strong ✅ Good Claude Code
    Terminal / shell command execution ✅ Yes Limited Claude Code
    Remote / cloud sessions ✅ Yes — Claude Code
    VS Code compatibility Via MCP ✅ Built on VS Code Cursor
    Model choice Claude only Multi-model Cursor (flexibility)
    Instruction-following precision ✅ Strong Good Claude Code
    Price Included in Pro ($20/mo)+ ~$20/mo (Pro) Tie
    Setup complexity Moderate Easy Cursor
    Not sure which to use?

    We’ll help you pick the right stack — and set it up.

    Tygart Media evaluates your workflow and configures the right AI tools for your team. No guesswork, no wasted subscriptions.

    What Cursor Does Better

    In-editor experience. Cursor is a fork of VS Code with AI baked in — autocomplete, inline suggestions, cmd+K to edit code in place, and the full VS Code extension ecosystem. If you live in an editor and want AI suggestions as you type, Cursor is the more polished experience.

    Familiar interface. If your team already uses VS Code, Cursor requires almost no adjustment. Claude Code requires getting comfortable with an agentic workflow that’s fundamentally different from autocomplete.

    Multi-model flexibility. Cursor lets you choose between Claude, GPT-4o, and other models depending on the task. Claude Code is Claude-only.

    What Claude Code Does Better

    System-level autonomy. Claude Code runs commands, manages files across the entire project, executes tests, and operates at the OS level — not just inside an editor window. It can do things Cursor can’t, like run a test suite, see the results, fix the failures, and re-run without you touching anything.

    Remote and background sessions. Claude Code supports remote sessions that continue on Anthropic’s infrastructure even after you close the app. Cursor requires you to be present.

    Complex multi-step tasks. Agentic tasks that span many files, require running code, and iterate based on output are where Claude Code’s architecture shines. Cursor handles this through its Composer feature, but Claude Code’s terminal-native approach gives it more flexibility.

    Instruction precision. On multi-constraint tasks — “refactor this to match our conventions, add error handling, keep it backward compatible, and don’t use async” — Claude Code holds all the constraints more reliably through a long operation.

    Price Comparison

    Claude Code is included (at limited levels) with a Claude Pro subscription at $20/month. Claude Code Pro at $100/month gives full access for developers using it as a primary tool. Cursor Pro is approximately $20/month. Both are in the same price tier for comparable usage levels.

    The Practical Setup

    Most developers using both tools run Cursor for in-editor work — autocomplete, inline edits, quick questions about code — and Claude Code for larger autonomous tasks: refactors, test generation across a codebase, debugging sessions that require running code. They’re complementary, not mutually exclusive.

    For a broader comparison, see Claude vs GitHub Copilot and Claude Code vs Windsurf. For Claude Code pricing specifically, see Claude Code Pricing: Pro vs Max.

    Frequently Asked Questions

    Is Claude Code better than Cursor?

    They’re different tools. Claude Code is better for autonomous multi-step tasks, system-level operations, and complex refactors that require running code and iterating. Cursor is better for in-editor autocomplete and inline suggestions within the VS Code interface. Most serious developers use both.

    Can I use Claude Code inside VS Code or Cursor?

    Claude Code primarily runs as a terminal agent or through Claude Desktop’s Code tab. You can connect it to VS Code via MCP integration. Cursor has its own Claude integration built in — you can use Claude models inside Cursor without Claude Code.

    How much does Cursor cost vs Claude Code?

    Cursor Pro is approximately $20/month. Claude Code is included at limited levels with Claude Pro ($20/month) or at full access with Claude Code Pro ($100/month). For occasional use, Claude Pro gives you both a full Claude subscription and limited Claude Code access for the same $20.

    Need this set up for your team?
    Talk to Will →

  • How to Use Claude Code: Getting Started, Workflows, and Best Practices

    How to Use Claude Code: Getting Started, Workflows, and Best Practices

    Last refreshed: May 15, 2026

    Model Accuracy Note — Updated May 2026

    Current flagship: Claude Opus 4.7 (claude-opus-4-7). Current models: Opus 4.7 · Sonnet 4.6 · Haiku 4.5. Claude Opus 4.7 (claude-opus-4-7) is the current flagship as of April 16, 2026. Where this article references Opus 4.6 or earlier models, those references are historical. See current model tracker →. See current model tracker →

    Claude AI · Fitted Claude

    Claude Code is an agentic coding tool that works directly inside your codebase — reading files, writing code, running tests, and making changes with your approval. It’s fundamentally different from asking Claude questions about code in chat. Here’s how to use it effectively from your first session.

    Access: Claude Code is in the Code tab of Claude Desktop, or via the CLI (claude command). Both require a Pro, Max, Team, or Enterprise subscription. For installation, see How to Install Claude Code.

    Starting a Session

    Open the Code tab in Claude Desktop (or run claude in your terminal), then select your session type:

    • Local — Claude works on your machine with direct file access. Changes happen locally. Best for everyday development.
    • Remote — Claude runs on Anthropic’s infrastructure. The session continues even if you close the app. Best for long autonomous tasks.
    • SSH — Claude connects to a remote server over SSH. Best for server-side or cloud VM development.

    Select your project folder and choose a model — Sonnet 4.6 for most work, Opus 4.6 for the most complex tasks. You can’t change the model after the session starts.

    Free — no pitch

    Get the Claude workflow that actually sticks.

    Practical Claude setup tips from someone running it across 27 client sites daily — not marketing, not theory. Email Will directly and he’ll share what’s working.

    Get the tips →

    What to Ask Claude Code to Do

    Claude Code works best with clear, specific tasks. Unlike chat, it has your full codebase as context — so you can refer to actual files, functions, and patterns without explaining them.

    Strong prompts:

    • “Fix the bug in auth.py where users aren’t logged out after session expiry”
    • “Add input validation to all API endpoints in routes/ — check for SQL injection”
    • “Refactor UserService to use dependency injection”
    • “Write tests for all public methods in utils/parser.js“
    • “Explain the data flow from the API call in main.py to the database”

    How Claude Code Makes Changes

    Claude Code doesn’t modify your files silently. When it wants to make a change, it shows you a diff — the exact lines it plans to add, remove, or edit — and waits for your approval before writing anything. You can accept the change, reject it, or ask Claude to revise its approach.

    This review-before-write pattern means Claude Code is safe to use even on code you’re not fully familiar with. You see every change before it happens.

    CLAUDE.md: Persistent Project Instructions

    Create a CLAUDE.md file in your project root to give Claude Code persistent context about your codebase — coding conventions, architecture decisions, testing patterns, libraries to prefer or avoid. Claude Code reads this file at the start of every session, so you don’t re-explain your project each time.

    # CLAUDE.md example

## Stack
- Python 3.11, FastAPI, PostgreSQL, SQLAlchemy
- Tests use pytest with fixtures in conftest.py

## Conventions
- Functions should have type hints
- No bare except clauses — always catch specific exceptions
- Use Pydantic models for all request/response schemas

## Do not modify
- legacy/ directory — kept for backward compatibility

    Common Workflows

    Debugging: Paste the error message and stack trace, ask Claude to find and fix the root cause. It reads the relevant files and proposes a fix.

    Refactoring: Describe the refactor goal — “extract this into a separate service,” “replace all these conditionals with a strategy pattern” — and Claude Code walks through the changes systematically.

    Test writing: “Write unit tests for all functions in this file” or “add edge case tests for the payment processing flow.” Claude reads your existing test patterns and matches them.

    Code review: “Review this PR for security issues, missing error handling, and anything that violates our conventions.” Claude reads the changed files and gives structured feedback.

    Documentation: “Add docstrings to all public functions” or “generate a README that explains this project’s architecture.”

    Tips for Getting the Most Out of It

    • Start small. First session, give it a small, contained task in a file you know well. Calibrate your trust before handing it larger work.
    • Be specific about constraints. “Don’t use async/await,” “keep changes backward compatible,” “match the style of the existing tests.” Claude Code holds these throughout the session.
    • Use CLAUDE.md. Any convention you find yourself re-explaining belongs in this file.
    • Review every diff. Claude Code is capable but not infallible. Read each proposed change before approving — especially on production code.
    • Use Remote for long tasks. Autonomous multi-file refactors or test generation across a large codebase work better in a Remote session that won’t be interrupted.

    For pricing details, see Claude Code Pricing: Pro vs Max. For how it compares to other tools, see Claude vs GitHub Copilot and Claude Code vs Windsurf.

    Tygart Media

    Getting Claude set up is one thing.
    Getting it working for your team is another.

    We configure Claude Code, system prompts, integrations, and team workflows end-to-end. You get a working setup — not more documentation to read.

    See what we set up →

    Frequently Asked Questions

    How does Claude Code work?

    Claude Code reads your project files, executes tasks like debugging, refactoring, and test writing, and shows you a diff of every proposed change before modifying anything. You approve or reject each change. It operates in your actual development environment, not in a chat window.

    Can Claude Code modify my files without permission?

    No. Claude Code shows you a diff of every proposed change and waits for your approval before writing to any file. You remain in full control of what gets modified.

    What languages does Claude Code support?

    Claude Code works with any programming language. It’s particularly strong on Python, JavaScript, TypeScript, and Go, but handles most modern languages and frameworks well. It reads and writes whatever files are in your project directory.

    Need this set up for your team?
    Talk to Will →

  • How to Install Claude Code: Desktop App and CLI Setup Guide

    How to Install Claude Code: Desktop App and CLI Setup Guide

    Last refreshed: May 15, 2026

    Looking for quick answers? The FAQ version covers every common question directly.

    → Claude Code FAQ

    Quick Answer

    Yes. Claude Code is generally available as of 2026. It installs via npm in under 2 minutes.

    Full installation walkthrough below — CLI and Desktop app.

    Claude AI · Fitted Claude

    Claude Code is available two ways: as the Code tab inside Claude Desktop (with a graphical interface), or as a CLI tool you install and run from your terminal. Here’s how to get either one set up from scratch.

    Requirement: Claude Code requires a Pro, Max, Team, or Enterprise subscription. It is not available on the free plan. The Claude Desktop app (which includes a graphical Claude Code interface) is free to download but the Code tab requires a paid subscription.

    Option 1: Claude Desktop (Recommended for Most Users)

    The easiest way to get Claude Code is through Claude Desktop — no terminal required.

      Installing Claude?

      If you run into setup issues or want to know how to get the most out of it from day one, just email me.

      Email Will → will@tygartmedia.com

    1. Download Claude Desktop from claude.ai/download — available for macOS and Windows (x64 or ARM64). Linux is not supported.
    2. Install — on Mac, open the PKG and drag to Applications; on Windows, run the installer.
    3. Sign in with your Anthropic account (Pro, Max, Team, or Enterprise).
    4. Click the Code tab in the top navigation.
    5. Select Local to work with files on your machine, or Remote to run on Anthropic’s cloud infrastructure.
    6. Click “Select folder” and choose your project directory. You’re ready.

    On Windows, Git must be installed for local sessions to work. Most Macs include Git by default — check by running git --version in Terminal.

    Free — no pitch

    Get the Claude workflow that actually sticks.

    Practical Claude setup tips from someone running it across 27 client sites daily — not marketing, not theory. Email Will directly and he’ll share what’s working.

    Get the tips →

    Option 2: Claude Code CLI

    For developers who prefer working in the terminal, Claude Code is also available as a command-line tool.

    # Install via npm
npm install -g @anthropic-ai/claude-code

# Authenticate
claude login

# Start in your project directory
cd your-project
claude

    The CLI requires Node.js. After running claude login, you’ll authenticate with your Anthropic account in a browser window. The session starts automatically in the current directory.

    Local vs. Remote Sessions

    Session type What it does Best for
    Local Runs on your machine, accesses your files directly Everyday development work
    Remote Runs on Anthropic’s cloud, continues if you close the app Long-running tasks, autonomous work
    SSH Connects to a remote machine over SSH Server or cloud VM development

    Common Setup Issues

    Code tab not appearing in Desktop: Confirm your account is on a paid plan. Claude Code requires Pro, Max, Team, or Enterprise — it’s not available on the free tier.

    Windows Git error: Claude Code needs Git for local sessions on Windows. Download Git from git-scm.com, install with default settings, then restart the desktop app.

    CLI authentication failing: Run claude logout then claude login again. Make sure your Anthropic account has an active paid subscription.

    Permission errors on first run: Claude Code will ask permission to access your files when you first select a folder. Click Allow — it needs read/write access to work with your project.

    First Session: What to Expect

    When you start your first Claude Code session, Anthropic recommends starting with a small, familiar project. Ask Claude to explain the codebase, fix a specific bug, or add a small feature. This gives you a calibrated sense of how it works before tackling larger tasks. Claude will read relevant files, propose changes, and ask for your approval before modifying anything.

    For an overview of what Claude Code can do once you’re set up, see How to Use Claude Code. For pricing details, see Claude Code Pricing: Pro vs Max.

    Tygart Media

    Getting Claude set up is one thing.
    Getting it working for your team is another.

    We configure Claude Code, system prompts, integrations, and team workflows end-to-end. You get a working setup — not more documentation to read.

    See what we set up →

    Frequently Asked Questions

    How do I install Claude Code?

    Download Claude Desktop from claude.ai/download and use the Code tab — no terminal required. Or install the CLI with npm install -g @anthropic-ai/claude-code and run claude login to authenticate.

    Is Claude Code free to install?

    Claude Desktop (which includes Claude Code) is free to download. Using Claude Code requires a paid subscription — Pro ($20/month), Max ($100/month), Team, or Enterprise. It is not available on the free plan.

    Does Claude Code work on Linux?

    The Claude Desktop app does not support Linux. The Claude Code CLI does run on Linux — install via npm and use it from your terminal.

    What’s the difference between Claude Code Desktop and the CLI?

    Claude Code Desktop (the Code tab in the Claude Desktop app) gives you a graphical interface with visual file diffs, a built-in preview panel, and no terminal required. The CLI runs in your terminal and supports the same core operations. Both share configuration files and can run simultaneously on the same project.

    Need this set up for your team?
    Talk to Will →

    📎 Book for Bots — Free

    Take this article on steroids.

    The Claude Implementation Playbook is a dense 9-section PDF you can attach directly to any AI conversation — pricing tables, model API strings, routing logic, context engineering rules. Verified May 2026.

    Get Free PDF →

    2026 Performance Boost: Higher Limits, No Peak-Hour Throttling

    Added May 9, 2026

    If you installed Claude Code before May 2026 and have noticed it running faster during previously-slow periods, this is why.

    What Changed: SpaceX Colossus 1 Capacity Expansion

    On May 6, 2026, Anthropic announced expanded compute capacity via a partnership with SpaceX’s Colossus 1 data center. The practical effect for Claude Code users:

    • Pro and Max subscribers: Peak-hours throttling eliminated entirely. Claude Code no longer slows down during high-demand periods. 5-hour rate limits doubled.
    • Team Premium seats: 5-hour rate limits doubled. Claude Code access included (Team Premium seats only — Standard seats do not include Claude Code).
    • Free plan: No change. Explicitly excluded from all capacity increases.

    This is the single most meaningful performance change to Claude Code since its GA release. If you’ve been hitting rate limits mid-session during long agentic coding runs, the ceiling is now twice as high. Source: anthropic.com/news/higher-limits-spacex

    Claude Code Pro Pricing (Current)

    Claude Code access is included in the following Claude subscription tiers — there’s no separate Claude Code subscription fee:

    • Pro ($20/month): Claude Code included. 5-hour rate limits now doubled. Peak-hours throttling eliminated.
    • Max ($100/month — 5× usage): Claude Code included. Same doubled limits, no peak throttling.
    • Max ($200/month — 20× usage): Claude Code included. Highest usage ceiling available to individuals.
    • Team Premium ($100/seat/month annually): Claude Code included. 5-hour limits doubled.
    • Team Standard ($25/seat/month annually): Claude Code NOT included.
    • Free plan: Claude Code NOT included.

    Claude Code and Student / Amazon Prime Discounts

    There is no Claude Code-specific discount program and no Amazon Prime Student bundle that includes Claude Code as of May 2026. Claude Pro ($20/month) is the lowest-cost tier that includes Claude Code. For students: Anthropic does not offer a verified student discount on subscriptions. The most cost-effective path to Claude Code for students is the standard Pro plan. See our Claude student discount guide for the full breakdown of what options exist.

    Claude Code Version: Stay Current

    Claude Code releases frequently. As of May 9, 2026, the latest version is v2.1.133 (released May 7). Key fix in this version: subagents now correctly discover project, user, and plugin skills via the Skill tool — a silent failure in prior versions that broke multi-agent pipelines without obvious error. Update with:

    npm update -g @anthropic-ai/claude-code