Over years and years of using HubSpot, my fingers have developed some muscle memory. When I sit down in the morning and open up chrome, my fingers instinctively start typing “app.hubspot.com”
I know, I know, I should probably have it bookmarked. But I always prefer the keyboard to the mouse.
This week, I noticed that muscle memory had changed. I sat down, opened chrome, and without even thinking about it, my fingers typed “claude.ai”
And I know exactly why that happened. HubSpot is still my primary system of action and system of record, but it’s no longer my primary system of interaction. And I think that's the most important change happening in go-to-market tech right now.
The Interface and the Infrastructure Are Splitting
For twenty years, the CRM made an implicit promise: the place where your data lives is also the place where you work. One login, one screen, one system. Record-keeping and execution were the same product.
Today, Claude is where I spend most of my working day.
It's connected to HubSpot through MCP (HubSpot ships an official connector for Claude, plus a developer CLI server for terminal-based workflows in Claude Code). It's also connected to my AI notetaker, my Slack workspace, my Google workspace, and the newsletter platform where you are reading this.
When I need to update deal records, build a segment, or pull pipeline numbers, I don't open HubSpot. I ask for it in the same window where I'm already doing everything else.
Every one of those Claude actions terminates in HubSpot. The contact records live there. The deal stages live there. The workflows, the lifecycle logic, the attribution touchpoints, all live in HubSpot. And, it works the other way as well. Context from within HubSpot informs actions I take in Claude. I have multiple skills and recurring tasks set up that rely on HubSpot data to inform the output.
HubSpot didn't become less important. It just became differently important.
The GTM Operating System
Once you see the interface splitting off from the system, a new architecture becomes obvious. Modern GTM teams aren't building a tech stack anymore. A stack implies layers sitting passively on top of each other. They're building an operating system, where every component has a job and the components talk to each other constantly.
At its most basic, mine looks like this:
HubSpot for data and deep automation. The system of record for every contact, company, and deal, and the system of action for anything that needs to run reliably at scale: lifecycle stage logic, lead rotation, nurture sequences, attribution. The deterministic stuff you never want an LLM improvising.
AI notetaker for context. Every sales call, customer conversation, and internal meeting becomes searchable, structured context. This is the layer that knows why a deal is stuck, not just that it's stuck. I use AskElephant, which connects natively to the other 3 tools in this stack.
Slack for communication. Where the humans coordinate, and increasingly where the system surfaces what needs human attention. Alerts, summaries, approvals, sent from Claude to my DMs.
Claude as the execution layer. The interface where work gets initiated, and the reasoning engine that connects the other three. It reads context from the notetaker, takes action in HubSpot, and reports back in Slack.
Think of it like an actual operating system. HubSpot is the file system and the kernel where state lives and where the low-level processes run. The notetaker is memory. Slack is the notification layer. Claude is the shell: the place where you type what you want and the system figures out which components to invoke.
Here's a concrete example from my own setup:
My newsletter research pipeline runs as a scheduled Claude agent. It pulls recent meeting transcripts from AskElephant to see what practitioners I have met with are struggling with, cross-references HubSpot product updates and community forums, checks my Beehiiv archive so I don't repeat myself, then drafts, QAs, and stages the issue in Beehiiv. Five systems, one workflow, zero tabs opened by me.
A year ago, that workflow was me, a Sunday afternoon, and eleven browser tabs. Today, I wrote this very newsletter on the couch using Claude on my phone between episodes of Netflix’s The Ultimatum (P.S. are people in Las Vegas okay???).
One Silo Breaks the Whole System
An operating system only works if every component can talk to every other component. The moment one system is siloed (no MCP server, no API access, no connector) the whole architecture degrades back into a stack. You're back to exporting and uploading CSVs, and the human becomes the integration layer again.
I've watched this happen in three specific ways:
The siloed notetaker. Your call recordings live in a tool that doesn't expose transcripts to anything else. This is unfortunately how most people use them. They are functionally transcripts you can revisit and nothing else. That means, your deal stages aren’t updating automatically based on call context. Your Claude conversations aren’t being informed by customer conversations. You are limiting the utility of that data.
The siloed CRM. Less common with HubSpot given the MCP investment they've made, but I still see teams lock down API access so tightly that the CRM becomes read-only to the rest of the system. A system of record that nothing can write to is a filing cabinet, not a system of action.
The siloed comms layer. If your alerts and approvals live in various apps while the rest of your day-to-day collaboration runs through Slack, the human-in-the-loop step becomes the bottleneck. The system does an hour of work in four minutes, then waits two days for someone to notice the approval request.
The weakest connection sets the ceiling for the entire system. Your GTM operating system is only as good as its most isolated component.
This should change how you evaluate software. The question is no longer "does this tool have a good interface?" The interface is increasingly not where your team will meet the tool. The question is: does this tool expose everything it knows and everything it can do to the rest of my system? An MCP server, a well-documented API, webhook support. A gorgeous UI on a closed system is a liability dressed up as a feature.
What This Means If You Run a HubSpot Portal
If you're a HubSpot admin or RevOps lead, I'd argue this shift makes your job more important, not less. Three implications:
Data quality stops being a hygiene project and becomes load-bearing. When humans were the interface, a messy portal was annoying. A person could eyeball a duplicate record and work around it. When Claude is the interface, the model acts on whatever the data says. Garbage in the CRM can result in wrong actions, executed confidently, at scale.
Deep automation and AI execution are complements, not competitors. Don't rip out your workflows because Claude can do things now. HubSpot workflows are deterministic: the same input produces the same output, every time, at no marginal reasoning cost. Use them for everything that should be deterministic. Save the AI execution layer work that requires judgment, context, or synthesis across systems. Human-in-the-loop beats full automation, and deterministic automation beats LLM improvisation for anything rule-shaped.
Connectivity is now a portal architecture decision. Scoping the HubSpot connector, deciding what Claude can read versus write, structuring properties so an AI can interpret them without tribal knowledge is is admin work in 2026. If your naming conventions only make sense to the person who built them, they don't make sense to Claude either.
I don't want to discount the uncertainty here. This architecture is early, the tooling has rough edges, and I still audit what Claude does in my portal. But the direction is not ambiguous.
HubSpot spent twenty years winning the battle to be the screen your GTM team stares at all day. The new battlefield is to become the system that AI uses instead. The HubSpot portal isn't where you work anymore. It's what makes the work possible.
Best,
Ryan
