The problem this solves
A partner sends you 1,400 domains from a conference badge scan. Somebody has to decide which 100 get a rep and which 1,300 get a newsletter, and the decision has to be the same one your ICP definition <name> makes everywhere else, or the rep queue fills with companies the definition would have rejected.
Scoring is the answer, and a script is the right shape for it: read the file, score each domain against the definition, write the file back with the score and reasons appended and the rows ranked. The scoring itself is the same fit scoring the console agents run, so a domain scores identically here, in a list and in a CRM sync.
What separates a script that runs once from one you keep is the handling. Keys carry a per-minute rate limit, so a naive loop over 1,400 rows hits it; a source outage should cost a null rather than a crash; a credit envelope can run out mid-file; and a rerun after a crash should pick up where it stopped rather than metering the first 900 domains again.
How the mission runs
- Read the CSV and normalize the domains. The script reads the domains column, lowercases each value, strips protocols, paths and a leading www, and drops duplicates, so acme.com and a full pricing-page URL on the same host score once. The Lead Verification Agent shows this as the first block of the script, because bad input is the most common reason for a bad score.
- Score in batches against ICP definition <name>. Each batch goes to the scoring tool through the REST API with the definition named, authenticated with Authorization: Bearer and a key minted for the script. A domain the platform has never seen is resolved first - firmographics and technographics through the waterfall - and then scored, and the response carries a fit score from 0 to 100 with the reasons: the facts that matched the definition and the facts that missed.
- Retry, back off and stop cleanly. The script retries a rate-limit response with exponential backoff, honoring the retry-after hint; logs a schema error and moves on; retries a network failure with an idempotency key so a duplicate request replays instead of metering twice; and stops on the credit-envelope response, writing what it has so far and printing where to resume.
- Append score and reasons and rank. Each row gets fit_score and reasons columns, plus the headcount and industry the score was based on so a reader can sanity-check it. Domains the platform could not resolve get a null score and a reason saying so. The rows are sorted by score, descending, and written back to the CSV path you name.
- Checkpoint for reruns. Every completed batch is written to a checkpoint file with its domains and scores. A rerun reads the checkpoint, skips the domains already scored and continues from the next batch, so a crash at row 900 costs a restart rather than 900 domains of credits.
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 script - the recipe shows it in TypeScript with the same structure in Python - that reads a CSV of domains, scores each against ICP definition <name>, appends fit_score, reasons, headcount and industry, ranks the rows and writes the file back, with rate-limit backoff, idempotent retries, a clean stop when the credit envelope runs out and a checkpoint for reruns. Point it at the badge scan and the 100 accounts that deserve a rep are the top of the file, with the reasons next to each.
Make it yours
- Save the ranked domains as list <name> through the lists endpoint instead of a file, so the top rows can be enriched, verified and pushed from the console.
- Score against two definitions in one pass and add a column per definition when two teams sell different products to the same file.
- Add a score cutoff and write two files: above the line for sales, below it for marketing.
- Run it from the CLI as a mission instead of a script when the file is a one-off and nobody will maintain code for it.
Frequently asked questions
Does scoring a domain enrich it?
Yes, when the platform holds nothing on it. Firmographics and technographics are resolved through the waterfall first, metered only when a source answers, and the score is computed from those facts. A domain already in your workspace scores from what is known, which is why the second run over the same file is cheaper.
How do I keep the script under the rate limit?
Batch the domains, wait for each batch to finish before sending the next, and back off on a rate-limit response using the retry-after hint. The recipe sets the batch size to a value that keeps a single key comfortably under its per-minute limit; a larger file simply takes longer.
What if the definition changes?
Scores are computed against the definition at call time, so rerunning the script after editing ICP definition <name> rescores the file. Keep the old ranked CSV and compare the two if you want to see which accounts the change moved.