Every CRM rots. Duplicate accounts pile up, fields go blank, records go stale. Everyone knows they should clean it. Almost nobody does, because the cure feels scarier than the disease: point a script at your customer data, hold your breath, and hope it doesn't merge the wrong two companies or wipe a field someone needed.
That fear is correct. A cleanup tool that can quietly do the wrong thing to your real data is not a tool, it's a liability. So the interesting problem was never "can a bot merge duplicates." It was "can a bot merge duplicates in a way you'd actually trust."
Three rules that make it safe
The whole thing comes down to a loop with the danger designed out:
1. Read-only first. Before anything changes, the agent just looks and reports: here are your duplicates, your blank fields, your stale records. No writes. You see the problem before you spend a cent.
2. You approve the plan. Nothing is touched until you say go — and you see the exact blast radius first: what gets merged, filled, or removed.
3. Logged and reversible. Every change is written to a tamper-evident log. Merges keep the related records, so nothing gets orphaned. If something's wrong, it walks back.
Caught working
Here's the loop on a throwaway test org I seeded with deliberately messy data — two pairs of duplicate accounts, same company entered twice with different casing:
// A real run — on a test org with planted data, no client involved. The same guarded loop runs on a real org only after your approval.
Small numbers, on purpose: the point is the method, not a big scary batch. The same loop scales to thousands of records without changing a single rule. Read-only first. Approve. Reversible. Every time.
The engine behind this is guardrailed by construction: it literally cannot write to a real org unless it's explicitly, per-job, allowed to — and production is blocked by default. The safety isn't a promise in a sales deck. It's the architecture.