The problem this solves
Big list builds fail at the end, which is the most expensive place to fail. You commission five hundred contacts, wait for the run, and open a finished CSV to discover the titles skew wrong or a neighboring industry bled in. Every flaw you find is multiplied across hundreds of rows that were built after the flaw first appeared. The all-at-once delivery model guarantees that quality problems are discovered at maximum cost, when the only remedies are a painful manual scrub or a rebuild.
Verification has the same batch-size problem. Deliverability lives and dies on address quality, and a list verified only at the end tells you about your bounce risk after all the finding work is done. If a source pattern produces weak addresses for one segment, you want that knowledge after fifty rows, while the remaining four hundred and fifty can still be sourced differently.
The fix is to make the build observable while it runs. Batches land in the thread as they complete, you spot-check a handful of rows in the minute it takes to read them, and a one-sentence correction bends everything still unbuilt. The economics invert: mistakes get caught at the cost of one batch, and by the final batch the criteria have been sharpened by every check you made along the way.
How the mission runs
- The ICP becomes explicit criteria. The agent restates your ideal-customer profile as checkable criteria - industry, size, geography, and the titles that count - and confirms them in the thread before sourcing begins. Ambiguity resolved here is multiplied across five hundred rows, so this confirmation is the cheapest quality gate in the mission.
- Sourcing runs in batches, verification included. Firmographics identifies companies matching the profile, Email Finder locates the right people and addresses, and Email Verification checks every address before it enters a batch. Weak or unverifiable addresses are dropped in flight, so no batch you review is padded with rows that would bounce.
- Each batch posts to the thread as it lands. Completed batches arrive in the conversation with a quality note: match confidence, verification results, and anything the agent flagged as borderline. You skim a few rows in place. The build stays visible the whole way, so silence from you means a checked batch looked right.
- Corrections bend the remaining batches. Reply "fewer agencies, more in-house teams" or "the titles in batch two are too junior" and the criteria update immediately for everything not yet built. Thread memory keeps every correction in force, so course changes compound across the run instead of needing restatement at each batch.
- The final CSV assembles the approved whole. When the last batch clears, the agent compiles the full verified list into a CSV delivered in the thread, with a build summary: batch-by-batch quality, corrections applied and when, and overall verification rates. The file you import carries a documented history instead of an unexamined past.
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
Five hundred verified contacts matching criteria that were refined live as the build ran: batches posted to your thread with quality notes, every address checked by Email Verification before inclusion, and your mid-build corrections applied to everything downstream of them. The final CSV arrives with a build report, and the thread preserves the full audit trail from first criteria to finished file.
Make it yours
- Front-load scrutiny: make the first batch twenty-five rows instead of a full slice, so the cheapest possible sample absorbs your roughest corrections before volume runs.
- Segment the build: ask for batches grouped by vertical so each posting is internally comparable, and quality differences between segments become visible instead of averaging out.
- Pause on a threshold: instruct the agent to halt the run and ask in the thread if any batch's verification pass rate drops below the bar you set.
Frequently asked questions
What does verification actually check?
Every address passes Email Verification before joining a batch, which tests whether the mailbox can be delivered to rather than merely whether the string looks like an email. Addresses that fail or return ambiguous results are dropped or flagged, and each batch reports its pass rate so quality is visible per slice.
Do my corrections apply to batches already delivered?
Corrections bend everything not yet built, which is the economic point of batching. For rows already delivered, ask and the agent will re-audit earlier batches against the updated criteria and mark the rows that no longer qualify, so the final CSV can exclude them without a manual scrub.
Can I stop the run partway and keep what was built?
Yes. A halt instruction in the thread stops sourcing cleanly at the batch boundary, and everything delivered and verified up to that point compiles into a final CSV on request. You pay for the batches that ran, and the thread records where and why the build stopped.