I let an AI run my HubSpot. It can't change anything until I say yes.

Two things I built

The first is a plugin for Claude Code that runs HubSpot in plain English. You type “find duplicate contacts and merge them,” and it routes the job to one of 44 specialist sub-agents, each scoped to one corner of HubSpot: contacts, deals, workflows, hygiene, that kind of thing. It shows you a preview, you approve, and it confirms the change actually landed. For anything destructive, it makes you type the number of records you expect it to touch, then checks that number again at the moment it executes. A merge that should hit 3 records can’t quietly hit 300. You can also hand it a bigger job, like reconciling stale deals older than 90 days, and it works through it step by step, checks its own work, and picks up where it left off if the session drops.

The second is a HubSpot MCP server. MCP is a standard connector for AI. Build it once, and any assistant that speaks the standard can drive HubSpot through it. I built this one so the same idea could run inside Claude Cowork, where the people who actually own the CRM work, instead of only inside a developer tool. It exposes 79 tools across the usual CRM surface: contacts, companies, deals, tickets, pipelines, owners, search. Then there are 7 more that are the reason it exists. Every write produces a preview. Nothing touches the CRM until you approve it. Every approved change records a snapshot you can undo, and everything lands in an audit log.

Both follow one rule, and it’s the part I care about most: the agent does the work, and a person signs off before anything changes. The Claude Code plugin is further along, with the specialists and the long multi-step jobs. The MCP server is newer and lighter. Both are open source under MIT (plugin, MCP server). Read the code before you take my word for any of it.

And to be clear about what this is: a pilot, not a product. I didn’t build these to sell you anything. I built them to learn something you can’t learn by theorizing: how people and agents actually split up real work. What’s safe to hand off, what isn’t, and when an agent should stop and pull a person back in.

HubSpot ships its own tooling. Why build this?

Now, the fair question, and I asked it myself before writing a line of code: HubSpot ships its own tooling. Why build this?

HubSpot ships two first-party tools in the same two shapes I built. There’s the Agent CLI, in beta, and the remote MCP server, which is now generally available with write access. Both are good, and I used both properly before writing this. But the thing I care about most isn’t in either one. That was true as of July 2026, when I last checked their docs and ran them.

In the Agent CLI, the preview is a --dry-run flag you add to each command. Forget the flag and the writes just run. HubSpot’s own beta warning says it plainly: run it against a production account and you “accept the risk of unintended changes, including data loss.” Its history command logs destructive operations only, and it can’t reverse them. The remote MCP server puts approval somewhere else: in the client. In Claude, for example, you can set write tools to need approval or to always allow. And once someone flips that to always allow for convenience, every write runs unchecked. Neither tool has an undo.

The gate belongs on every single write

That gap is the whole reason mine exist. It comes down to one decision I’d defend anywhere: the gate belongs on every single write, inside the tool itself. Not in a flag you have to remember. Not in a client setting someone can switch off. In both of my projects, the only way to change the CRM is to approve that exact change first. The tool assumes an agent will eventually try to do something dumb at scale, and it refuses to let it.

None of this matters if you just want to look up a contact. It starts to matter when the job gets bigger than clicking through screens: cleaning up thousands of records, reconciling a messy pipeline, running a migration, merging duplicates at scale. That’s who these are for. Not developers, but the person who owns real work in HubSpot, wants an agent to carry the heavy part, and doesn’t want to find out later that it quietly broke something. The safety layer is what lets that person take the job on without holding their breath.

One conversation, not a relay race

There’s a bigger reason this was worth building, and it’s about how the projects themselves got made.

For years, building something was a relay race. Research hands off to strategy, strategy to copy, copy to design, design to engineering. Every handoff loses a bit of context and adds a bit of delay. These projects had no relay. They were one long conversation with agents that could research, draft, write code, and test, handing off to each other while I stayed in the middle holding the whole thing. There was no planning phase, and then a building phase. It was one session that happened to end with working software.

If you run a company, that should make you look at your org chart. A strategy team, then a copy team, then a design team, then an engineering team, with tickets and reviews at every boundary. That structure made sense when execution was slow, and each stage needed a specialist to do it well. When a small team plus agents can do each stage fast and well, the boundaries you built to manage slowness become the slowest part of the system.

But I hit the wall too, and I won’t pretend otherwise. Agents let me write specs faster and in more detail than I ever could alone. Sounds like a pure win, until the specs start queuing up and waiting for a human to review them. The speed didn’t disappear. It moved downstream and turned into a review problem, and nobody had resized the review step to match.

The answer is not to skip review. The human in the loop is the part of the system I trust most. That’s the bet behind both projects: as agents get faster, raw access to your systems stops being the scarce thing. The scarce thing is a review step that keeps up without turning into a rubber stamp. So I built the gate into the tool as the only way through. It’s an attempt at an answer, not a claim to have solved it. Which calls should an agent make on its own, and which should it bring to a person? That’s what this pilot exists to find out.

One last thing, about the work itself. My background says depth: HubSpot architecture, engineering leadership, AWS. But I didn’t hand-write these two codebases. Agents wrote most of the code. My job was to define what safe means, review what came back, and refuse to ship anything I couldn’t defend. Depth still matters. It’s exactly what made my review worth something. What changed is the leverage. One person who knows their domain deeply and can orchestrate agents across everything else can now ship what used to take a team. That’s not a prediction. It’s how these got built.

So if your business is still organized like a relay, or you still measure your team’s value by how deep each person goes in one lane instead of how much of the whole picture they can hold, that’s the thing worth examining this week. Not the tools. The shape.

Try it, and tell me where I’m wrong

Both projects are in active beta. They work, but they’re rough in places, and I’m still building them. If you run HubSpot, the most useful thing you can do is try one against a sandbox or a free developer test portal, never your live account, and tell me what breaks. You don’t even need real data. Install one, give it a hypothetical use case, and ask it to seed the test portal with sample records, then let it work against that.

And don’t stop at the code. If you think I’ve got any of this wrong, the gate, the review bottleneck, the org chart, I want to hear that too. Tell me where I’m wrong.