The problem this solves
A persistent list is a query with memory: the criteria that built list <name> are saved with it, and a refresh re-runs them against live data, adds the companies that newly match, drops the ones that no longer do and updates the rows whose facts moved. Left to a human, the refresh happens when someone remembers, which is roughly once a quarter.
The useful output of a refresh is the delta. Nobody in #sales wants the whole list again; they want the 14 companies that appeared since yesterday, the 3 that fell out and the 9 whose headcount or stack changed. New rows need verified emails before anyone sends to them, so verification belongs inside the job rather than in a follow-up nobody schedules.
The CLI is built for exactly this kind of unattended run: it reads its key from the environment, prints JSON to stdout and progress to stderr, exits with codes a scheduler understands, and retries safely because async runs carry an idempotency key.
How the mission runs
- Write the refresh command. The Prospecting Agent hands you a single CLI command that refreshes list <name> against its saved criteria and waits for the run to finish, with JSON output on so the job can parse the result. The key comes from an environment variable rather than a stored config, which is the right setup for a cron user or a container.
- Verify the new rows. The second command runs email verification over the rows the refresh added. Each address gets a status - deliverable, risky, catch-all or invalid - and a confidence value, written back to the row on list <name> so the status travels with the row wherever it is exported later.
- Compute the delta. The job keeps a snapshot of last night's rows and compares tonight's rows against it by row id. Rows present now and absent before are added, the reverse are removed, and rows whose tracked fields differ are changed, with the names of the fields that moved recorded next to each.
- Post to #sales. The three groups are formatted as one message: counts in the first line, then the added companies with their fit score, matching evidence and verified contact, then the removed and changed rows in shorter form. It goes to #sales through the Slack connection in your workspace, and an empty delta posts a one-line all-quiet note so the channel knows the job ran.
- Schedule it. The cron line runs the job at 02:00 in your timezone, after the data sources have settled and before anyone reads Slack. The agent gives you the line, the command with its flags, and the exit codes to alert on: 0 for success, 1 for an API or run failure and 2 for a usage error, so a broken key pages you rather than silently posting nothing.
- Keep the cost visible. Every refresh and every verification meters against the workspace, and the run reports its cost in the JSON. The job writes that figure into the footer of the Slack message, so the team sees what the nightly list costs and can tighten the criteria if it drifts.
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 cron line, the refresh and verification commands with their flags, and a short wrapper that computes the delta and posts it to #sales every night. List <name> stays current against its criteria without anyone opening the console, new rows carry verified emails before a rep sees them, and each morning's message shows what was added, removed and changed, with the run's credit cost in the footer.
Make it yours
- Run it as a platform schedule instead of cron when you would rather have no machine of yours involved; the delta still lands in #sales.
- Push the added rows into HubSpot or Pipedrive as the last step; the push is approval-gated, so the message includes the approval id for someone to confirm in the morning.
- Post only the added rows that score above 75 and send the rest to a quieter channel, when #sales should stay short.
- Refresh two lists in one job and post one combined message with a section per list.
Frequently asked questions
What counts as a changed row?
Any tracked field that differs from last night's snapshot: headcount band, industry, a technology detected or dropped, a new signal, a contact whose email status changed. The job names the fields that moved, so a rep can see at a glance whether the change matters.
What happens if the run fails halfway?
The CLI exits with code 1 and the wrapper skips the Slack post, so a partial delta is never announced. Async runs carry an idempotency key, so re-running the job replays the same request instead of starting a second refresh.
Will removed companies be deleted from the list?
They are reported as removed and no longer appear in the active rows. A company that matches the criteria again later comes back as added, so the list stays a faithful answer to its criteria rather than an ever-growing archive.
Does verification run on every row each night?
Only on the rows the refresh added. Verifying the whole list nightly would meter every address again for no new information; a monthly re-verification of the full list is a separate job most teams add alongside this one.