The problem this solves
Duplicate companies are what a CRM grows when three imports, two integrations, and years of manual entry all feed the same table. One account becomes four records with slightly different names, activity splits across them, and suddenly your reporting counts the same customer twice while your reps work half a history. Nobody decided to create this mess. It accreted, one convenient shortcut at a time, and now every list, score, and dashboard built on the company table inherits the noise.
The reason it persists is that merging is scary. A wrong merge destroys information, so the person who volunteers to clean up is the person who owns the fallout if two genuinely different companies get combined. Faced with that asymmetry, most teams do nothing, and the duplicate count compounds. This is the decay economics of CRM data in miniature: the cost of cleanup is visible and assignable, while the cost of leaving it alone is diffuse and lands on everyone.
What breaks the deadlock is a process that is conservative by construction and accountable by default. Matches need evidence, ambiguous cases need to be surfaced rather than guessed, and every single change needs to land in a log a human can audit afterward. With that in place, the cleanup stops being an act of courage and becomes a routine the team can repeat with confidence every quarter.
How the mission runs
- Build the duplicate map. The agent scans your HubSpot companies and clusters likely duplicates using domains, normalized names, and near-match heuristics. Exact-domain matches are high confidence; name-only matches are flagged as candidates. Nothing merges at this stage; the output is a map of clusters with the evidence for each.
- Propose merge-safe resolutions. For each confident cluster, the agent picks a surviving record and works out how conflicting fields resolve: most recent value, most complete value, or keep-both-in-notes, depending on the field. Ambiguous clusters, where the evidence could support two different companies, are set aside for your call instead of being forced.
- Normalize names and domains. Independent of merging, company names get consistent casing and suffix treatment, and domains are canonicalized so that variants of the same web address stop reading as different companies. The normalization rules are stated in the output, so you can see exactly what convention the database now follows.
- Apply the changes idempotently. Merges and normalizations are applied to HubSpot in one pass. Every changed record carries a note saying what happened and why - merged from which record, renamed from what, on what evidence. Re-running the mission is safe: records already resolved are recognized and left alone rather than re-processed.
- Deliver the change log CSV. A CSV lands with one row per touched record: the before state, the after state, the action taken, and the reason. The ambiguous clusters that were held out appear in their own section with the evidence for each, ready for a human decision in a follow-up run.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
A HubSpot company table with duplicates merged, names and domains following one stated convention, and a note on every changed record explaining the action and its evidence. Alongside it, a change log CSV covering every merge and rename with before and after values, plus a held-out list of ambiguous clusters the agent declined to force, each with the evidence laid out for a quick human ruling.
Make it yours
- Run it in propose-only mode first: the full change log arrives as a CSV for review, and the merge pass executes in a second run once you have signed off.
- Narrow the scope to companies created in the last year if the historical table is contested territory, then widen once the team trusts the convention.
- Add contact-level dedupe to the same mission so people attached to merged companies are consolidated in the same pass, with their rows in the same log.
Frequently asked questions
What happens if the agent is unsure whether two records are the same company?
It declines to merge. Clusters where the evidence is ambiguous are held out and delivered as a separate section of the change log with the reasoning shown, so a human makes the call. The mission is built to be conservative: a missed merge costs a little, a wrong merge costs a lot.
Can I undo a merge if something looks wrong?
The change log records the complete before state of every touched record, which is exactly what you need to reconstruct one. In practice the propose-only variation is the stronger safety net: review the log first, approve it, and the apply pass only ever executes changes you have already seen.
How does re-running this stay safe?
Writes are idempotent. The agent recognizes records it has already resolved and leaves them alone, so scheduling the sweep monthly keeps the table clean without churning it. Each run produces its own change log, giving you a running audit trail of how the company table has evolved.