Last refreshed: May 15, 2026
I run a portfolio of businesses — restoration companies, content properties, creative ventures, a software platform, a comedy site, a few things I haven’t decided what to do with yet — on three legs. Notion. Claude. Google Cloud. That’s it. Everything else either fits inside that triangle or it doesn’t last in my stack.
This article is the doctrine. Not “here’s a list of tools I like.” The actual operating philosophy of why this specific three-piece architecture is what holds the work up, where each leg’s job ends, and what I learned the hard way about which tools belong on the floor instead of the table.
If you’re trying to decide what your own AI-driven operating stack should look like, what follows is what I’d tell you over coffee.
Why three legs and not two, four, or twelve
I tried twelve. I tried four. I lived for a while with two. Three is what’s left after everything else either failed in production, got absorbed into one of the three legs, or became overhead that didn’t pay for itself.
The reason it’s not two is that you need a place where state lives, a place where reasoning happens, and a place where heavy compute runs. If you collapse two of those into one tool, the tool has to be excellent at both jobs and almost nothing is. If you keep them separate, each tool gets to be excellent at its actual job.
The reason it’s not four is that every additional leg multiplies the surface area of what can break, what needs to be monitored, what needs to be paid for, what needs to be learned by every new person you bring in. Four legs sounds like it would be more stable but it isn’t. It’s more rigid. Three legs sit flat on uneven ground.
The reason it’s not twelve is that I tried that and the cognitive cost of remembering which tool did which job was higher than the work the tools were supposed to be saving.
Notion is the system of record
State lives in Notion. That’s the rule. If a piece of information needs to exist tomorrow, it goes in Notion first.
That includes the things you’d expect — clients, projects, content pipelines, scheduled tasks, the Promotion Ledger that governs which autonomous behaviors are running at what tier — and a lot of things you might not. Meeting notes go in Notion. Random ideas at 11pm go in Notion. The reasons I made a particular architectural decision six months ago go in Notion. Anything I might want Claude to read later goes in Notion.
The reason this leg has to be Notion specifically — and not, say, a folder of markdown files, or a Google Doc, or Airtable — is structured queryability paired with human-readable rendering. Notion databases let me describe my business in shapes (a content piece is a row, a project is a row, a contact is a row) while keeping every row a real document I can read and write to like a normal page. That dual nature is rare. Most systems force you to pick between structured and prose. Notion lets the same object be both.
The May 13, 2026 Notion Developer Platform launch made this leg even stronger. Workers, database sync, and the External Agents API mean the system of record can now do active things on its own and host outside agents (including Claude) as native collaborators. Notion stopped being a passive document store and started being a programmable control plane. That’s a big deal for this architecture and I wrote about it in my piece on the platform launch.
Claude is the reasoning layer
Claude does the thinking. That’s the rule on the second leg.
Anywhere I would otherwise have to write something from scratch, decide between options, summarize a long document, generate code, audit content, or do any task that requires a brain rather than just a database query, Claude is the first thing I reach for. The work happens in Claude. The result lands in Notion.
I want to be specific about why Claude and not “an LLM” generically. I have used the others. I have used GPT in production. I have used Gemini in production. They all work. Claude is what I picked, and the reasons aren’t religious.
First, the writing is recognizable. Claude’s voice has a calibration to it that the others don’t quite have for the kind of work I’m doing — long-form content, operator-voice editorial, technical explainers. I can edit a Claude draft to feel like me much faster than I can edit the others.
Second, the agentic behavior is the most stable across long sessions. Claude Managed Agents and Claude Code in particular are willing to think for a long time without losing the plot. For multi-step work that involves reading a lot of context, holding it, and acting on it across many turns, the difference is real.
Third, the tooling around Claude — Claude Code, Cowork, the Agent SDK, MCP — is the most operator-friendly of the bunch right now. The other models will catch up. As of May 2026, Claude is the best fit for how I actually work.
Fourth, and this matters more than people give it credit for: I am willing to bet on Anthropic the company. I am betting my operations on the leg that bears my reasoning load. Whose roadmap I’m comfortable with, whose values I find legible, whose engineering culture I trust to keep shipping the thing without breaking it underneath me — that’s a real input to the decision, not a soft preference.
Google Cloud is the substrate
The third leg is the heavy one. Google Cloud is where the things live that have to be reliable in a way that Notion can’t be and Claude isn’t supposed to be.
The 27 WordPress sites I manage all live on GCP infrastructure. The knowledge-cluster-vm hosts five interconnected sites. The proxy that lets Claude talk safely to WordPress sites runs on Cloud Run. The cron jobs that fire scheduled work, the Python services that handle image pipelines, the AI Media Architect that runs autonomously — all on GCP. Anything that involves real compute, regulated data, behind-a-firewall execution, or sustained reliability lives on the third leg.
The reason this leg has to be a real cloud and not just a laptop or a Hetzner box is that I run autonomous behaviors. Tier C autonomous behaviors run unattended, which means the substrate they run on has to be more reliable than I am. GCP gives me that. It’s also where Anthropic’s Claude is available through Vertex AI, which means there’s a path where the entire stack can run inside one cloud’s perimeter when that becomes operationally necessary.
I picked GCP specifically over AWS or Azure for a few reasons. Vertex AI’s first-party Claude access matters to me. The GCP control surface is the one I’m fastest in. Cost-wise it’s been competitive for the workloads I run. None of those are universal — your third leg might be AWS, or Azure, or a hybrid with on-premise hardware. The doctrine isn’t “use GCP.” The doctrine is “have a real substrate that can carry the heavy work.”
How the three legs hold each other up
The thing that makes this an actual stack and not just three tools is the load each leg puts on the others.
Notion holds Claude’s memory. Claude doesn’t have persistent memory across sessions in any deep way — what it remembers is what’s in the prompt and what it’s allowed to look up. Notion is where I put the things I want Claude to know tomorrow. Project briefs, brand voice docs, the Promotion Ledger, client context, my preferences. When Claude starts a session it looks at Notion. When the session is done, what mattered gets written back to Notion. The memory leg is Notion. Without it, Claude is amnesiac and has to be re-briefed every time.
Claude does the work that Notion can’t and that GCP isn’t shaped for. Notion can hold structured data and run light automation through Workers and database sync. Notion can’t write a 2,000-word article in your voice. GCP can run a reliable cron job and host whatever you want on Cloud Run. GCP isn’t going to read your existing client notes and propose a follow-up email. The reasoning leg is Claude. Without it, you have a database and a server and no one to think.
GCP holds the things that have to keep running when nobody is watching. Notion can’t host a WordPress site. Claude can’t run a cron job by itself. The compute leg is GCP. Without it, the autonomous behaviors that make this a system instead of a tool collection have nowhere to live.
Each leg fails gracefully into the others. If Notion is down, GCP keeps the live workloads running and Claude can still do work in a session. If Claude is down, Notion still holds state and GCP still runs the autonomous infrastructure. If GCP is down, the websites are unreachable but the planning surface (Notion) and the reasoning surface (Claude) still let me figure out what to do about it. No single failure takes the whole operation down.
What I tried that didn’t make the cut
For honesty’s sake, here’s what I had in earlier versions of the stack that’s no longer there:
Zapier and Make for orchestration. They worked. They cost real money at the volumes I was running. The May 13 Notion Developer Platform launch absorbed most of what I was using them for into native Notion functionality. What’s left I do with Cloud Run jobs.
Multiple LLMs for “best tool for the job.” I went through a phase of routing different work to different models. The cognitive overhead of “which one for this task” was higher than any quality gain from the routing. I picked Claude and stayed.
Custom CRMs and project management tools. Tried several. None of them did the job better than a well-structured set of Notion databases with the right templates and views. The CRM is in Notion now. The project management is in Notion. The pipeline tracking is in Notion.
A second cloud “for redundancy.” Sounded smart, was actually overhead. If GCP goes down catastrophically I have bigger problems than my stack. Single-cloud is fine for a small operator portfolio.
Local AI models for cost savings. The math didn’t work for me. I have a powerful workstation that can run open models, but the time cost of running them, debugging them, and maintaining them outweighed the API savings. Claude through the subscription and through Vertex when I need it is what I pay for now.
Why this matters beyond my own operation
I write about this not because anyone is required to copy it but because the shape of the answer — three legs, one for state, one for reasoning, one for compute — generalizes.
If you’re a solo operator, a small agency, a content business, a service business with operational complexity, this shape works. Your specific tool choices for each leg will be different. Maybe your state lives in Airtable instead of Notion. Maybe your reasoning leg is GPT or Gemini. Maybe your substrate is AWS or Vercel or your own bare metal. The three-leg architecture survives the substitutions.
What doesn’t survive substitutions is collapsing the legs. Putting state and reasoning in the same tool (anyone who has tried to use ChatGPT as their CRM knows what I mean) doesn’t work. Putting reasoning and compute in the same tool means you’re either compromising on reasoning to keep compute simple or compromising on compute to keep reasoning fluid. The separation is where the strength is.
Where the stack is going next
Three things I’m watching:
Notion’s platform maturation. The May 13 launch is version 1 of what Notion as a programmable platform looks like. If Workers and database sync continue to grow into real automation surface, more of what I do on GCP could move to Notion. I don’t expect the heavy stuff to migrate, but the lightweight glue is moving in that direction.
Claude’s agentic capabilities. Claude Managed Agents and the Agent SDK are getting better fast. Some of what I currently script in Python on Cloud Run will move into Claude-native agentic loops as the agents become more capable of long-running, reliable work without supervision.
The fortress pattern on GCP. The ability to run Claude inside a private GCP perimeter via Vertex AI is becoming more important as I take on regulated industry work. The substrate leg is staying GCP precisely because of this — the perimeter matters.
The stack will evolve. The three-leg shape probably won’t.
Frequently Asked Questions
Why Notion and not Airtable, Coda, or Obsidian?
Notion’s combination of structured databases and human-readable page rendering is what makes it work as both a database and a knowledge base for Claude. Airtable is more powerful as a database but worse as a document. Coda is similar in spirit but smaller community and tooling around it. Obsidian is excellent for personal knowledge but doesn’t have the multi-user, structured-database surface I need to run businesses on.
Why Claude and not GPT or Gemini?
Voice quality for the kind of writing I do, agentic stability across long sessions, operator-friendly tooling (Claude Code, Cowork, MCP), and Anthropic’s roadmap and culture being legible to me. The other models work; Claude is what I picked.
Why Google Cloud and not AWS?
Vertex AI’s first-party Claude access, GCP’s control surface fitting how I work, competitive cost on my specific workloads. AWS would also work. The doctrine is “have a real substrate,” not “use GCP specifically.”
Can a small operator afford this stack?
Yes. Notion is $10/seat. Claude Pro is $20/month, Max is $100-$200. GCP costs scale with what you actually run — my 27-site infrastructure runs in the low three figures monthly. Total monthly stack cost for a solo operator running this architecture is well under what most people pay for a single SaaS tool that does only one of these jobs.
What if one of the legs goes away or pivots badly?
Each leg is replaceable. The shape of the stack matters more than the specific brands. If Notion pivots away from being useful, the state leg moves somewhere else. If Anthropic pivots, the reasoning leg moves. If I leave GCP, the substrate leg moves. The architecture is durable; the specific tool choices are not load-bearing in the way the architecture is.
How long did it take to settle on this shape?
Roughly two years of trying things. I write the doctrine now because I want my own next iteration to start from this shape rather than rebuilding it from scratch. If you want to skip those two years, this is the shortcut.
Leave a Reply