HubSpot's Breeze agents are ready to work. The Customer Agent answers tickets, the Prospecting Agent researches accounts and drafts outreach, the Content Agent drafts pages. Where they go wrong on real portals is rarely the model. It is the portal: the data the agent reads, the permissions it acts under, and the absence of anyone checking its work in week one. These are the five problems we find most often in the readiness check that runs before any agent goes live, and the fix for each.
Why do Breeze agents fail on portals that look fine?
Because an agent has no judgement about the record it is reading. A human rep who sees two contact records for one customer picks the right one from context. An agent picks one and acts on it. A human who sees a "Lead Status" property with six values that mean four different things asks a colleague. An agent treats every value as truth. Every problem below is a place where a person would have paused and the agent does not.
INSIDEA runs a 15-point readiness check in three layers, data, permissions and review, before switching on any agent. The full checklist has the scoring rule. This piece is about the five checks that fail most often and cost the most when they do.
Problem 1: how do duplicate records break an agent?
The Customer Agent is asked about an order. Two contact records exist for the customer, one from a form fill and one from an import, and the open ticket is associated with the one that has no purchase history. The agent answers from the record it has: no order found. The customer escalates, and the first impression of your AI support is that it does not know who they are.
The fix comes first because it unblocks everything else. Deduplicate contacts, companies and deals, then set a merge rule for new duplicates so the problem does not return in a month. HubSpot's duplicate management handles the obvious cases; the hard ones are the same company under three spellings, and those need a pass by someone who knows the accounts. Budget a week for a portal under 50,000 contacts.
Problem 2: what happens when a property has two meanings?
A Prospecting Agent is told to target accounts where "Industry" is "Financial Services". Half the sales team has been typing "Finance", the imported list used "Banking", and the enrichment tool wrote "Financial Svcs". The agent targets a third of the accounts it should and reports success.
The fix is a property dictionary: one page that says what every property and every picklist value means, who owns it, and which values are allowed. Then clean the picklists to match. This is unglamorous work and it is the single biggest predictor of whether an agent's output is useful. Properties that drive targeting, personalisation and routing come first; the long tail can wait.
Problem 3: which system is the source of truth?
Your CRM says the renewal date is 30 November. The billing system says 15 December. The agent reads the CRM, emails the customer about a renewal that is two weeks early, and the customer forwards it to their procurement team. Nobody set out to do that. Nobody named which system wins when the two disagree.
The fix is a decision, not a build: for every field an agent will act on, name the source of truth and make the sync one-directional from it. Where the CRM is not the source, the agent should read the synced field, never a manually maintained copy. The HubSpot Breeze guide covers which Breeze features are production-ready and which still need this guard rail most.
Problem 4: what can the agent see and do?
The default permission for a new agent is often wider than anyone intended. If it can read every property, it can surface a sensitive one in a customer reply. If it can send without approval, it will. If no threshold separates a low-value routine action from a high-value one, it treats a $200 refund and a $20,000 renewal the same way.
The fix is scoping in three parts. What the agent can read, with sensitive fields excluded by name. What it can do: draft only, draft and send, or update records. And thresholds, by confidence and by value, above which a human acts first. Write the escalation rule down: when the agent hands off, and to whom. Every action logged so it can be traced and reversed.
Problem 5: who reviews the agent's work, and when?
The most common go-live plan is "switch it on and watch it". Nobody is named, nobody has a schedule, and the first mistake is found by a customer. The agent may have been 95% accurate for two weeks; the 5% is what leadership hears about.
The fix is assist-first rollout. The agent drafts, a named person approves, for a defined period and a measured accuracy rate. Autonomy widens only as the measured accuracy proves out, and anything customer-facing keeps a human in the loop at the start. A weekly review of a sample of outputs, on the calendar, with an owner. This costs an hour a week and it is the difference between an agent that survives its first month and one that gets switched off.
| Problem | What the agent does | Fix | Typical time |
|---|---|---|---|
| Duplicate records | Acts on the wrong record | Deduplicate, set a merge rule | About a week |
| Properties with two meanings | Targets or personalises wrongly | Property dictionary, clean picklists | One to two weeks |
| No source of truth | Acts on stale or conflicting data | Name the source per field, one-way sync | A decision, then days |
| Open permissions | Reads sensitive fields, acts without approval | Scope reads, actions, thresholds, escalation | Days |
| No review path | First mistake reaches a customer | Assist-first, named reviewer, weekly sample | An hour a week |
In what order should you fix them?
Data first, permissions second, review third, because each layer depends on the one before it. Deduplication and the property dictionary make the data trustworthy. Scoping makes the agent's reach match that trust. The review path catches what the first two missed. Most portals we check need two to four weeks on the data layer and a few days on the rest. Switching the agent on afterwards takes five business days on the Fast Track activation, and the agent works from day one because the portal underneath it does.
INSIDEA
Ready to put AI to work in your business?
Practical automation and AI workflows built on top of your stack, not bolted on.
How INSIDEA gets agents to go-live
INSIDEA is an Elite HubSpot Partner rated 4.99 across 450+ verified reviews. We run the three-layer readiness check on every portal before an agent goes live, fix what fails, then activate HubSpot's packaged agents ($300 on the Fast Track in five business days, $250 Standard in ten, with a credit forecast before switch-on) or build a custom agent for the use case the packaged ones do not cover, fixed fee from $2,000. The AI agents page has the two routes, the published credit rates and the seven-week custom build plan.

