Why AI bolted onto HubSpot breaks, and how to fix it
AI automations on HubSpot rarely fail because the model is bad. They fail because nobody owns them, nothing logs what they did, and the prompt lives in one person's account. Here is how to tell if yours is brittle, and what a durable build does differently.
AI automation bolted onto HubSpot breaks for boring reasons. The model is usually fine. What fails is everything around it: a Zapier chain nobody remembers building, a prompt saved in one person's ChatGPT account, an API limit nobody planned for, and no log of what the automation changed or why.
A durable build has four things. One named owner. A log of every action it takes, with an alert when something stops. Prompts and code kept under version control inside HubSpot or your own accounts. And a tested fallback for when the AI is unavailable or wrong.
If you cannot point to all four for an automation that touches your CRM today, treat it as brittle. It may be working right now. You just will not know when it stops.
Both versions do the same job on a good day. The difference shows on the day something changes, and on the day the person who built it leaves.
What does "brittle" actually look like?
Here is how one client described it to us on a sprint call, about a Zapier integration that kept misfiring:
I don't know whether or not when we've fixed one problem, we've inadvertently created another.
That is the whole problem in one line. When an automation is a chain of tools held together by settings in five different places, every fix is a guess. Nobody can see the full chain, so nobody can predict what a change will do.
The other giveaway is silence. On one portal we looked after, a set of Zaps stopped running in mid September and nobody noticed for weeks, because nothing was watching them. No error went to anyone. Leads just stopped arriving where they were supposed to.
The six ways AI on HubSpot breaks
These are the patterns we see most on discovery calls and audits. Most portals that come to us have at least three.
| What you see | Why it breaks | What a durable build does instead |
|---|---|---|
| Records stop updating and nobody notices for weeks | The automation runs outside HubSpot, in Zapier or Make, and failures go to an inbox nobody reads | Failures alert a named person in Slack or email the same day, and the run history is checked weekly |
| "It worked yesterday" | An upstream tool changed its format. A property listing portal changes its enquiry email layout and every text parser downstream breaks | Read structured data from an API where one exists, and validate every input before acting on it |
| Bulk updates fail halfway through | HubSpot's API limits. Private apps on Professional and Enterprise get 190 requests every 10 seconds, and a bulk job that sends its calls in one burst hits that ceiling and gets throttled | Queue and batch the work, back off and retry on a 429 error, and schedule big jobs overnight |
| The AI agent gives a different answer every time | It is pulling from several knowledge sources that contradict each other | One source of truth per fact, and a test set of real questions run before every change |
| Nobody knows how it works | The person who built it left, and took the logins, the prompts and the context with them | Prompts and code live in the company's own accounts and a shared repository, with a one-page runbook |
| You cannot tell what changed a record | The integration writes with no user attached, so the property history shows a blank | Every write is made by a named integration user and logged with what it changed and why |
That last one comes up more than you would expect. On one portal we audited, the connection to the online store had been uninstalled at 8pm one night the previous June, and no store data had reached HubSpot since. Nobody knew who had removed it, or that it had happened at all.
The "nobody knows how it works" row is just as common. Here is how one client put it, talking about an integration another provider had built for them:
it's literally the integration that I don't have access and that's the thing that I don't know how to use.
Why does this keep happening?
Because the first version of most AI automation is a prototype that worked, so it never got rebuilt.
Somebody in marketing or ops gets a good result from ChatGPT, saves the prompt, connects it to HubSpot with Zapier, and it saves the team ten hours a week. That is a real win. Then it becomes something the business depends on, and it is still running on one person's account and one person's memory.
The account problem is worse than it looks. One client trying to close down a paid ChatGPT workspace before moving to Claude told us:
I can't export anything.
Months of prompts, files and context, sitting in a tool the business was paying for and could not get back out. If those prompts were running a customer-facing process, that process would have gone with them.
None of this is a reason to stop people experimenting. Experimenting is how you find the ten hours. The mistake is promoting the experiment to production without changing how it is built.
The four things a durable build has
1. One named owner
A person, named, who gets told when it fails and is expected to do something about it. A team name does not count. An agency counts only if the contract says so, and our post on who owns the AI system after we leave covers what that contract needs to say in Australia, where the default is the opposite of what most people assume.
2. A log of every action, and an alert when it stops
Every record the automation creates or changes should be traceable to a run: when it ran, what it read, what it wrote, which prompt version it used. HubSpot's own workflow history and integration logs cover part of this. Anything running outside HubSpot needs its own.
Then alert on two things: errors, and silence. An automation that usually processes 40 leads a day and processed zero yesterday is broken, even if it threw no errors. We go further into monitoring an agent that is running but no longer useful in the failure nobody builds for.
The Australian Signals Directorate says the same thing about AI agents in its May 2026 guidance on agentic AI, written with its US, UK, Canadian and New Zealand counterparts. It recommends logging agent actions by default and to "clearly assign responsibility and accountability for errors or adverse outcomes caused by the system".
If those logs hold customer data, decide where they are stored and for how long before anyone writes a line of code. For an Australian business that usually means an Australian region, such as AWS Sydney (ap-southeast-2), and a retention period written down next to your privacy policy.
3. Prompts and code in your accounts, under version control
A prompt that changes how your CRM behaves is code. Treat it like code. It lives in a repository the company owns, every change has a date and a reason, and you can roll back to last week's version in minutes.
The same goes for API keys. They should belong to a company account with a company email, so nothing depends on one person's login. If someone leaves, you rotate the key and nothing breaks.
4. A tested fallback
Decide in advance what happens when the AI is slow, down, or wrong. Usually the answer is boring: the record goes to a person's queue with a task attached. The point is that it was decided and tested before launch, and not worked out on the day.
For anything that writes to records, also decide how you undo it. That is a bigger topic, and we cover it in can you undo what an AI agent just did?, including the August case ASD wrote up where an AI assistant changed an Australian gym's booking system and could not reverse it.
Got an AI automation nobody wants to touch?
Tell us which one your team would miss most. We will trace what it reads, writes and depends on, and tell you what would break first and how to make it last.
What does a durable build look like in practice?
Gro Clinics is a prescription hair care business that was running across four systems: Shopify for checkout, Stripe for payments, Zenoti for appointments, and a pharmacy for fulfilment. We moved all of it into HubSpot while the business kept trading.
The parts that connect Stripe, Zenoti and the pharmacy to HubSpot are custom-coded workflows and integrations. Before any automation went live, we reconciled 17,000 Zenoti appointment records that had fallen out of sync, so every automation acts on data that matches the source. The build was designed so Gro's own team can add a practitioner, change a product or cover leave without calling a developer.
The test of a durable build is what happens when something needs to change in a hurry. When Gro needed a checkout security upgrade, it shipped in under 16 hours on a live service carrying around $116,000 a month in subscription revenue, with no downtime. The full case study has the rest.
Is yours brittle? A five-minute check
Pick the AI automation your team would miss most if it stopped tomorrow, and answer these:
- Can you name the one person who gets told when it fails?
- If it stopped running yesterday, would anyone know by lunchtime today?
- Is the prompt saved somewhere the company owns, with a history of changes?
- Are the API keys on a company account, not a person's?
- Can you see which records it changed last week, and why?
- If the AI service was down for a day, does the work go to a person, or does it just not happen?
- If the person who built it left on Friday, could someone else fix it on Monday?
Two or more answers of "no" means it is brittle.
Two or more "no" answers means it is brittle. That does not mean rip it out. It usually means moving it into HubSpot's own workflows and custom code actions, or into a small service you own, and adding the log, the alert and the owner. Our post on when to stop configuring HubSpot and start writing code helps with which way to go.
Frequently asked questions
Is Zapier or Make the problem? No. Both are fine for low-volume, low-stakes jobs, and both have run histories and error alerts if you switch them on. The problem is using them for something business critical with no owner and no alerts. Our guide to connecting HubSpot and Zapier covers where the line sits.
Should AI automation run inside HubSpot or outside it? Inside, where HubSpot can do the job, because the logs, permissions and record history come with it. HubSpot's custom code actions and Breeze agents cover more than most teams use. Go outside when you need more than HubSpot's limits allow, a model HubSpot does not offer, or logic that spans several systems. Then build it as a proper service with its own logging.
How do we connect Claude or ChatGPT to HubSpot without making it brittle? Use the official connections. HubSpot's MCP server lets Claude and other tools read and write CRM data with permissions you control. Scope what it can touch, give it its own identity, and keep anything destructive behind a person. We wrote up the controls we built first in connecting HubSpot to Claude through MCP.
What should we look for in a managed AI automation partner for HubSpot? Ask who owns the code and prompts when the engagement ends, where the logs live, who gets alerted when something fails, and how they test a change before it reaches your live portal. Ask to see a runbook from a build they have already handed over. If they cannot show you one, the build will depend on them forever.
Where to go from here
Pick the one automation your team would miss most and run the seven questions above. If you get two or more "no" answers, that is the one to fix first.
Sources
- API usage guidelines, HubSpot, for private app rate limits.
- Careful adoption of agentic AI services, Australian Signals Directorate and partners, May 2026, for logging and accountability.
- When AI agents take unexpected actions, Australian Signals Directorate, 11 August 2026.
- Gro Clinics case study, Neighbourhood, for the Gro figures.
If you want a second pair of eyes, our AI Engineering team builds and looks after AI on HubSpot for Australian businesses.
Who gets told when your automation stops?
Book a call and we will run the seven questions with you on the automation you rely on most.