You want to run pi across your HubSpot CRM and say: standardize every company description, tighten the deal notes from last quarter, fill the missing fields before the next QBR. What makes pi the right tool is that it is yours. You write the system prompt, you wire in the validators, you set the rules for what it checks before it writes and what it rejects before it stops. Pi does not impose a workflow on your HubSpot. You configure it to match the one you already have.
What stops most people is the CRM itself. Contacts, deals, and sequences are live and react instantly. Workflows watch the fields pi would touch. Reps depend on the records being accurate right now. Most ways of running an agent against a CRM hand it a direct line to the live data, so one misconfigured pass rewrites records, trips automations, and leaves your team cleaning it up by hand. Scratch removes that risk by pulling everything down as a folder of local files first. Pi edits the files. You approve the diffs. Nothing reaches HubSpot until you say so.
How it works
- Scratch pulls your HubSpot records into files. Contacts, companies, deals, tickets, and custom objects come down to a folder on your laptop, one file per record. Pi reads real data, not fixtures or samples.
- Pi edits the files. Open a terminal in the Scratch folder and run pi the way you normally run it. Hand it the prompt you prepared: standardize every company description and tighten the deal notes from last quarter. Your system prompt and validators run on every file. Pi works through the records and stops when they pass.
- You review every diff and publish. Scratch shows each changed field next to the original, word by word. Approve what you want to ship. Scratch writes only those records back through the HubSpot CRM API. Records you skip never leave your laptop.
What people use it for
Most teams arrive with a CRM that has drifted, because cleaning it by hand means opening every record one at a time.
- Standardize company descriptions across every account so filters and reports behave.
- Tighten deal notes and next-step fields after a quarter of inconsistent rep input.
- Fill missing properties by reading what is already on the record.
- Normalize the formatting on a custom property so sequences and lists target the right contacts.
- Run a voice pass on every contact note so outreach reads like it came from one person.
Pull a few hundred records to feel the loop, then point pi at the whole object.
Why not an MCP server?
A HubSpot MCP server hands pi a direct line to your live CRM. The write path is wired straight in, and pi can change records as fast as it runs. One misconfigured system prompt, one validator that was too permissive, and pi has rewritten a whole object, fired every workflow watching those fields, and left the data in a state your team has to manually unwind.
Scratch gives pi the same full read and write access, but against a local copy. The write-back step is separated out and given to you. Pi can change anything in the files. Only you can commit those changes to HubSpot, record by record, after you have seen every diff. On a CRM that drives your pipeline and your reporting, that separation is the thing that makes it safe to actually use.
What pi edits in HubSpot
Pi edits the files in your Scratch folder. What writes back to HubSpot depends on what you approve and what you have locked.
Editable, subject to your review:
- Contacts and companies
- Deals, tickets, quotes, and line items
- Notes, tasks, calls, and meetings
- Custom objects and the associations between them
Locked by default, never touched:
- Workflows, sequences, and enrollment criteria
- Lists and their membership rules
- Marketing Hub assets and email content
- Any field you mark read-only in the Scratch connector
If pi edits a field you have locked, Scratch will not write that field back. The lock sits at the sync layer, below the file. Pi can change the text in the file. The locked field stays unchanged in HubSpot.
For the full field list, see Scratch for HubSpot.
Questions people ask
Can I configure pi to follow my specific HubSpot conventions?
Yes, that is the point. Pi runs from a system prompt you write. You put your field rules, your tone requirements, your character limits, your list of phrases to never use, all of it, directly in the prompt. Validators add a second layer: a Python script that runs after every edit and rejects any record that fails a check. Pi will not mark a rewrite done until the validator passes. Your configuration lives in files on your machine, not in someone else's dashboard.
Will pi touch my workflows or sequences?
No. Workflows, sequences, enrollment criteria, lists, and Marketing Hub assets are never exposed for editing. Pi only sees the objects you pull down through Scratch, and Scratch does not pull those assets. Emails on contact records come down as read-only context if you need pi to understand history, but they cannot be edited.
Will editing records fire my automations?
Edits in the local copy fire nothing. HubSpot cannot see what pi does in your Scratch folder. When you approve a record and Scratch writes it back, HubSpot processes the update the same way it would process any API write, so a workflow watching that field will fire, exactly as if you had edited the record by hand. The difference is that you chose which records to write back, one at a time, instead of a bulk pass tripping every automation at once.
Can I undo a change after it writes back to HubSpot?
Yes. Every written record is reversible from Scratch, per row. The original sits next to the rewrite in the review queue until you decide which one stays. Approving a revert sends the original back through the API.
Do I need to be technical to set this up?
You need to be comfortable running a CLI tool, because pi is a terminal application. Writing a system prompt and wiring in validators is work you do yourself, in files, without a GUI. If that fits how you already work, the HubSpot setup is straightforward: install Scratch, connect HubSpot, run pi in the folder, approve the diffs.
See it on your own CRM
The fastest way to trust it is to run it on your own records. Talk through the setup or download Scratch free and run the first pass yourself.