Create a Notion Hub for Claude Chat, Cowork, and Code

Notion Hub for Claude

Most people wiring an AI assistant into their work stop at the same place: “I connected Notion to Claude.” That move is real, useful, and one search away. There are a dozen tutorials for it, and the number grows every month. It is also not the part that matters. However, what you need is a Notion Hub for Claude.

The part that matters showed up the moment I was working across three Claude surfaces at once. Chat for thinking and drafting, including from my phone. Cowork for acting on my desktop and local files, a capability that only became real in early 2026. Code to build and ship durable assets. Each surface was capable on its own. Together, they had a quiet problem: each forgot what the other knew. The fix was not another connector. It was a decision, repeated for every fact I cared about, about where that fact should live.

I have come to think of it as a routing discipline. It is the most useful operating habit I have built in the last year, and you can stand it up without writing a line of integration code.

Three Claude Surfaces, Three Jobs

Each Claude surface is good at a different kind of work, and the differences are the point.

Chat is where thinking happens. Reasoning through a decision, drafting, asking the dumb question safely, doing it from a laptop or a phone in a hallway between meetings.

Cowork is the agent that acts. It reads and writes my local files, drives desktop applications, and runs multi-step tasks where the work lives. It runs the work on my machine instead of asking me to copy it into a chat window.

Code is where I build things meant to last. Plugins, tools, sites, the assets I ship and maintain over months, not the throwaway output of a single session.

The friction is that each surface has its own memory model, and they do not fully share it. Native memory syncs across Chat, Desktop, and Mobile when I am signed in. Code reads instructions from local files that the web surfaces cannot see. So, a preference I taught one surface to be invisible to another, and a project status I updated in one place went stale everywhere else. I want to name that gap plainly, because it is the reason the rest of this matters. The surfaces are not yet one seamless brain. You have to give them a shared spine, and decide what hangs from it.

Route Context, Not Duplicate Memory

The obvious move is to build one universal memory that holds everything. Pour every fact, preference, and project note into a single store and let every surface read it.

That fails in a specific way. The store bloats. It goes stale because nobody maintains a junk drawer. And worst of all, it leaks the wrong context into the wrong place, putting personal notes in front of a work task or shipping half-formed code conventions into a strategy conversation.

The better model is to treat context like an editor, not a hoarder. Every durable fact has exactly one correct home, and the home is determined by a single question: who needs to see this?

That question resolves into three tiers.

Code-only facts go in the repo: build conventions, release steps, and the architecture of a specific project. These live with the work and are meant to die with it. They have no business traveling to my phone, and they would only add noise to a strategy chat.

How-I-work facts go to a global instructions layer: My standing preferences for how any project should be handled: tone, autonomy, what “done” means to me. These are portable across every project but local to the tool that reads them. They are about me as an operator, not about any one piece of work.

Portable, cross-surface facts go to the hub: Anything I want to be reachable from every screen I use, anything that represents a durable decision or a current status, anything I might need on my phone. This is the universal layer, and in my setup, it is a single Notion page accessible from every surface via the connector.

The setup only takes an afternoon. Once you have a durable decision or a project status changes, the hub gets updated, so the web and mobile surfaces stay current instead of confidently telling me something that stopped being true last week.

The Hub in Practice

The Notion Hub for Claude is deliberately boring. It is a single Notion page, accessible from Chat, Cowork, the web, and mobile through the connector. It is human-readable, durable, and portable, which is exactly why it works as the shared spine the surfaces lack on their own.

Walk one fact through it. Say a project moves from “drafting” to “in review.” This update happens in the hub, once. The next time I am in Chat on my phone and ask where things stand, the connector reads the current state and answers correctly. When Cowork picks up the related files on my desktop, it is working from the same truth. I did not manually sync anything across three tools. I updated one home and let the surfaces read from it.

Why Notion specifically, rather than a purpose-built AI memory product? Because the requirements are solved problems and Notion meets them. It is readable by a human, so I can audit and edit it directly. It is durable, so it outlives any single session. And it is reachable by the connector across every surface, which is the precise workaround for the memory gap I named earlier. The web and mobile surfaces cannot see my local files, but they can see the hub.

Proof: Projects That Span the Ecosystem

The test of an operating system is whether it holds up across genuinely different work. A few of mine sit on different legs of the span.

Product in Acquisitions OS, which I build and ship in Code.

It packages the 90-Day Product Integration Framework as a working operating system for product leaders running post-acquisition integrations, versioned and released like real software. Its conventions, release steps, and structure live in the repo, where they belong, and nowhere else. This is the durable-asset leg: deep, project-bound work that has no reason to travel.

Notes2Notion, the bridging tools that move my notes into the hub.

I built small tools that carry knowledge from Apple Notes into Notion. That is the inbound side of the hub, the plumbing that keeps the shared spine current without manual copying. It is also a reminder that the hub is not just something the surfaces read. It is something the rest of my system feeds.

A Zone 8a gardening site that has nothing to do with work.

public site I run on the side. It matters here precisely because it is personal. The routing rule is what keeps personal data out of public work and professional contexts where it does not belong. The discipline is not only about getting the right context to the right place. It is about keeping the wrong context out.

None of these required a custom memory product or a clever integration. Each one required the same small decision, made consistently: where does this fact belong?

How It Is Wired

Three layers, each with one job.

The repo layer is a `CLAUDE.md` file checked into each project. It holds that project’s conventions and is read by Code when a session starts. The global layer is a single `CLAUDE.md` in my home directory. It holds my cross-project working preferences and is also read by Code. The hub layer is a single Notion page, exposed to Chat, Cowork, and the web and mobile apps via the Notion connector.

The routing rule is the glue. A fact lands in exactly one layer based on who needs to read it, and the hub is the only layer every surface can reach. There is no custom memory service, no vector database, no integration code. The work is the repeated routing decision.

Get the Full Recipe and the Product Plugin

You now have the full argument and the system’s shape: three surfaces, one routing question, and a hub that serves as the shared spine. That is enough to start today.

What I have not handed you yet is my exact wiring. Below see the link for premium subscribers, where the step-by-step build as I actually run it: what goes in the global instructions file and what stays out, how the per-project files and the hub divide the work, the routing rule written so every surface obeys it, the inbound plumbing that keeps the hub current without copying by hand, and the maintenance cadence that keeps a shared spine from quietly going stale.

Premium subscribers also get the Product in Acquisitions OS as an installable Claude plugin, not a PDF. It is this same routing discipline applied to one hard problem: keeping an acquired product team and roadmap coherent through the first 90 days.

If you have been meaning to stop fighting your tools, this is the afternoon to build your Notion Hub for Claude. Click here to subscribe.

Two ways to follow what's next

New writing lands here first, then goes out via Substack. Conversations happen by appointment.