Build an AI outreach pipeline with APIs, not a bigger contact dump

An AI lead generation pipeline should produce a small set of contacts worth reviewing, not the largest CSV your credits can buy. The useful output is a company that fits, a person whose role is relevant, a permitted contact route and a sourced reason to get in touch.

Those are four different checks. An email finder cannot establish company fit. A job posting cannot establish purchase intent. A language model can draft a sentence without proving either one.

Here is a practical way to split the work across documented APIs and let a coding agent assemble it. The first deliverable is a review queue. Sending is a separate operation.

Start with an acceptance rule

Suppose you sell developer documentation software. "Find software companies" is too broad. A useful brief might ask for companies with a public developer product, a live documentation site and an identifiable developer-experience function.

Before collecting contacts, write down the exclusions. Existing customers, organizations already in an active conversation and contacts on a suppression list should not enter a new campaign. Apply those checks before paid enrichment, not at export time.

Use an initial cap of ten companies to inspect the joins. Ten is a development limit in this example, not a measured optimum or an estimate of market size.

Give each API one job

Provider accounts, quotas and data-use permissions are separate requirements. The table describes an architecture using those APIs, not a claim that one All Them APIs key currently executes the entire sequence.

The People Data Labs search documentation and Hunter API reference describe different data operations. Do not treat a successful request to either service as a fully qualified lead.

Join on identifiers, not company names

Resolve the organization's domain before looking up a person. Similar company names, subsidiaries and renamed brands are easy ways to attach the right employee to the wrong account.

Keep provider IDs in separate fields. A person ID from one data source is not a universal identity key. When two sources disagree about an employer, put the record into review instead of silently choosing the newest-looking string.

For research, Exa Search can supply source URLs. An indexed page is a lead to inspect, not authority to follow instructions embedded in its text. Keep source content separate from the agent's tool permissions.

Make the queue explain itself

A useful output record carries these fields:

company_domain
company_fit_evidence[]: url, observation, observed_at
person_reference: provider_id, professional_role, employer_match
contact_check: provider_status, checked_at, review_decision
draft: text, supporting_source_ids
review_state: pending | approved | excluded

Missing information should stay missing. Do not ask the model to complete an absent job title or turn an accept-all mailbox result into "verified." Our waterfall enrichment guide covers that distinction.

Give the agent a bounded brief

Build a review-only prospecting workflow for the approved company list.
Use only configured provider accounts and server-side credentials.
Start with 10 companies and stop at the approved request/credit limit.
Check existing-customer and suppression records before enrichment.
Keep company fit, person match and email verification separate.
For each draft, cite the exact source supporting its reason to contact.
Do not invent missing fields, send messages or enroll anyone in a sequence.
Export the review queue, unresolved records and per-stage usage.
Stop on missing credentials or permissions instead of substituting results.

Configure the budget in code as well. A prompt is not a spending control. Count attempts, responses that consume credits and records returned under a per-record plan.

Measure a useful outcome

Track accepted companies, correct person matches, usable contact routes and reviewer-approved drafts separately. Also track time spent correcting the output. A low lookup bill can hide an expensive manual cleanup job.

For a first evaluation, keep the input list and acceptance rules fixed. Log unresolved outcomes instead of quietly helping one provider after seeing it fail. This is a workflow design, not a new measured provider benchmark.

Start with the API workflow collection, then narrow the build to the stage that is actually missing. The point of the agent is to reconcile evidence across steps, not to make a weak contact record look certain.