The problem this solves
Your outbound agent needs a short, ranked queue of accounts to work each morning, with enough context per row to write a first line and a verified address to send to. What it usually gets is a whole list export: 800 rows, a score column somebody computed last month, and contacts whose emails were never checked. The agent spends its first hundred tool calls filtering, and its first ten sends bounce.
The shape matters as much as the selection. An agent reads JSON, so it needs consistent field names, a score it can sort on, reasons it can quote, a latest-signal field it can turn into an opener and a contact object with a verified flag it can trust. A spreadsheet column called Notes does none of that.
And the queue has to be reproducible. If the top 20 came from a one-off analysis, tomorrow starts from zero. If it came from a call against the list with a filter and a limit, the same call runs every morning from your agent's own code and returns whatever list <name> holds by then.
How the mission runs
- Read list <name> and its scores. The Prospecting Agent opens list <name> through the lists endpoint and reads every row with its fit score and the reasons behind it. Rows that were never scored are scored now against the ICP definition attached to the list, so the ranking covers the whole list rather than the rows that happened to be scored earlier.
- Rank and cut to 20. Rows are sorted by fit score, descending, and the top 20 are kept. Ties are broken by the freshness of the latest signal on the row, so two accounts with the same score are ordered by which one moved most recently: a new posting, a round, a technology change or intent activity on a topic you track.
- Attach the latest signal per account. For each of the 20, the agent pulls the newest signal on the row - its kind, its date and a one-line description - and writes it into a latest_signal object. An account with no signal in the window gets a null there rather than a filler sentence, so your agent can branch on it.
- Resolve and verify the primary contact. The primary contact is the person on the row whose title best matches the buyer role the list was built for. If the row holds no contact, people search finds one and the email finder fills the address through the waterfall, billed only when a source answers. Every address passes email verification before it is returned, and the contact object carries a verified flag plus the status the verifier gave.
- Return the JSON and the call that reproduces it. The result is a JSON array ordered by score, one object per account: domain, fit_score, reasons, latest_signal and primary_contact. Below it the agent prints the request that produces the same rows on demand - the rows call for list <name> with a minimum-score filter, a limit of 20 and the contact columns, authenticated with Authorization: Bearer and your key - so your agent can fetch it every morning without a new mission.
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 JSON array of 20 objects, ordered by fit score, each with domain, fit_score, reasons (the firmographic, technographic and signal facts that scored it), latest_signal (kind, date, description, or null) and primary_contact (name, title, email, verified flag and status). Under it, the reproducing API call with a Bearer placeholder and a note on what it meters in credits, so the same selection can run from your agent's code on a schedule against whatever list <name> holds that day.
Make it yours
- Raise the count to 50 or lower the score cutoff to 70 when the agent is meant to work a wider queue and can afford a lower hit rate.
- Ask for two contacts per account - the economic buyer and the champion - when your agent runs multi-threaded sequences.
- Add a signal filter, such as accounts with intent activity on <topic> in the last 14 days, so the 20 are chosen by timing as well as fit.
- Request the same JSON through MCP inside Claude Code or Cursor when the consumer is a coding session rather than a service.
Frequently asked questions
What if fewer than 20 rows have a verified contact?
The agent returns the rows that do, tells you how many were dropped and why - no contact found, or the address failed verification - and offers to run the email finder and verification on the next rows down so the queue fills to 20.
Does the reproducing call re-run the scoring?
No. It reads the rows and the scores already stored on the list, which is a light call. Scoring happens when the list is scored or refreshed, so a nightly refresh keeps the morning call current without a mission in between.
How is this metered?
The rows read is light. Scoring unscored rows, finding a missing contact and verifying an address meter per row, and the waterfall bills only when a source answers. The mission reports its total, and the reproducing call reports its own each time it runs.
Which key should the agent use?
Mint a key for this agent alone, scoped to list reads and the enrichment and verification tools, and keep it in the agent's environment. One key per surface means revoking it later cuts only this agent's access, and its calls show up under its own name in the audit trail.