You own the systems of record, so you know the job nobody volunteers for. Standardize the industry field on every account. Normalize the deal notes after a quarter of drift. Merge the duplicates. The work is hygiene, not net-new, and it is thousands of records deep. The tooling is what stops you. The AI built into your CRM stops reading after a few hundred records. MCP makes an API call per record and falls over on real volume. One customer had given up and was hiring help: "We're literally hiring a consultant to help with duplicates inside of HubSpot." Another named the other half of the problem, the fear of writing blind: "Every time I set it up, I'm a little scared. Am I about to do something unforgettable inside of my company's deals?"
Scratch downloads the whole object as files on your computer. Your agent reads and edits every record there, not the first 200, and about 10x faster than it works over an API. Every change comes back as a diff next to the original. Nothing writes back to the live system until you approve it, per record.
Without Scratch, and with
| the job | without scratch | with scratch |
|---|---|---|
| Standardize company and industry fields across the CRM | One blind pass overwrites every account at once. | You scan the diff and approve only the rows that are right. |
| Merge duplicates across the CRM | "We're literally hiring a consultant to help with duplicates inside of HubSpot." | The agent merges locally and queues the changes. You review all of it before anything writes back. |
| Normalize deal notes after a quarter of drift | A find-and-replace flattens the cases it never saw. | The agent handles the messy ones. You read each change next to the original. |
| Normalize naming and formatting across a 14,000-row base | The built-in assistant caps out around 200 records. | "Iterate a billion times through all the rows." Locked fields never write back. |
| Reconcile copy and fields after a migration | The export sits in your downloads folder, untouched. | Every record mapped, every change a diff you can read and reject. |
How it works
- Scratch pulls your records into files. HubSpot contacts, companies, and deals, Airtable rows, Notion database entries, Supabase tables, Linear issues, Attio and Pipedrive records all come down to a folder on your laptop, one file per record.
- Your AI edits the fields you point it at. Open the folder in the agent you already use. Try a prompt on a few records, then let it run across the whole object, every record, not a sample. The agent edits the files, never the live system.
- You review every diff and publish. In the Scratch desktop app, each changed field shows next to the original, word by word. Approve what ships, and Scratch writes only the records you approved back through each platform's API, or a direct database connection for SQL sources like Supabase.
A real run: 20,000 support conversations through Claude in 30 minutes.
One customer pulled 20,000 Intercom conversations down as files. Claude wrote a Python script, pruned the spam, scored every conversation, and produced a ranked feature-request list in about 30 minutes. Asked to do the same job over MCP, Claude itself estimated it would take an eternity. In the customer's words: "That was just impossible before."
The same pattern holds on a CRM or a database. A 14,000-row base whose built-in assistant caps out around 200 records becomes, in its owner's words, "iterate a billion times through all the rows." Queries that took five hours over a connector run in five minutes on disk. The honest caveat: the speed is in the agent's work on your data. Writing approved changes back runs at your platform's own API speed.
What ops teams use it for
Most people arrive with a system of record that has drifted, because cleaning it by hand means opening every record one at a time.
- Standardize company descriptions and industry fields across the whole CRM.
- Merge duplicate contacts and companies in one reviewed pass.
- Tighten and normalize deal notes after a quarter of drift.
- Clean up custom-object copy that diverged across teams.
- Normalize naming and formatting across an Airtable base or a Notion database.
- Reconcile copy and fields after a migration, so the source of truth matches again.
- Roll back yesterday's automated run, per record, when it went wrong.
Pull a few hundred records to feel the loop, then point the agent at the whole object.
Why not let the AI write straight to your system of record?
An MCP server or a direct API write hands the AI the publish button straight to the live system, and it is the slow path on top: every record is an API call, and on a real object it falls over. There is no diff, no review queue, no rule layer, no rollback. One confident pass rewrites every record, fires the automations watching those fields, and skews the reports your team reads on Monday. By the time you spot the problem it is already live and the original is often gone. A cleanup script is no safer. It does exactly what you wrote, including the case you did not anticipate, across thousands of rows.
Scratch gives the AI the same full read and write access, but against a local copy. The write-back step is pulled out and handed to you. The agent can change anything; only you commit it. And every published change is reversible per record, so yesterday's run is never a one-way door.
What is safe, and what is off-limits
You bring your own AI. Scratch holds no AI credentials and runs no model. Sign into Claude, Claude Code, Codex, Cursor, Copilot, Cline, Windsurf, or any agent that edits local files, the way you already do. By default, nothing leaves your laptop until you publish, and Scratch writes back only the fields you changed, so the fields you did not touch are left exactly as they were. Locked and never-touch fields you flag are stripped before write-back, so the agent cannot push them even if it edits the copy. Optional Python validators, which the AI can author, flag edits that break a length cap or touch a field you protected, next to the diff. And every record Scratch writes back is reversible on its own, so you can undo one row without touching the rest.
In one customer's words: "The advantage of your service over MCP is I get to check off on anything writing back through it." Another, after his first reviewed run: "Now I'm going to feel better doing changes. I can use the product more because I'm safe."
Questions ops teams ask
Can I let an AI clean up the system of record my whole team depends on?
Yes, because the AI never touches the live system. It reads and rewrites a local copy, and nothing writes back until you have seen the change as a diff and approved it. The agent gets full access to the copy; you keep the publish step. On a record the whole company runs on, that is the difference that matters.
Is this actually faster than MCP or the built-in assistant?
Yes, on the work itself. Over MCP every record is an API call, and on larger objects it falls over. On local files the agent reads everything at once: 20,000 support conversations were processed in about 30 minutes, and queries that took five hours over a connector run in five minutes on disk. Built-in CRM assistants also stop reading after a few hundred records; on files the agent reads all of them. The exception is write-back, which runs at the platform's API speed for the records you approve.
Will anything write back before I have seen and approved it?
No, not unless you have switched on automatic publishing yourself. By default, every edit lands in local files first, Scratch shows each change next to the original in the desktop app, word by word, and it writes only the records you approve back to the live system. Auto-publish and scheduled publishing exist, but they are opt-in and off until you turn them on.
Will it touch my workflows, automations, or locked fields?
Scratch writes back only the fields you change, so it is not rewriting whole records out from under your lists and views. Locked and never-touch fields you flag are stripped before write-back, so they never reach the live system even if the agent edits the copy. Optional validators flag anything questionable next to the diff. One caveat: approving a record can fire an automation that watches a field you changed, the same as a manual edit would, which is why you choose which records write back.
Will editing records fire my automations or skew my reporting?
Edits in the local copy fire nothing and change no report. When you approve a record, Scratch writes it back like any normal update, so an automation watching that field can fire, the same as if you had edited the record by hand. The difference is that you choose which records write back, instead of one bulk pass tripping every automation at once.
How is this different from a cleanup script or a CSV re-import?
A script and a CSV re-import both write straight to the live system with no diff and no per-record approval, and a find-and-replace only does exactly what you spelled out. Scratch puts an agent on the edit, so it handles the judgment a rule cannot, and holds every change as a word-level diff you approve before anything ships.
Can I undo yesterday's run after it wrote back?
Yes. Every written record is reversible from Scratch, per record. Roll back one row or the whole run, and Scratch restores the original for you to publish. You never have to choose between a bulk pass and a one-way door.
See it on your own records
The fastest way to trust it is to watch it run on your records. See it run on your system of record, or download Scratch free and run the first pass yourself.