How to Build AI Farms for Lead Generation and Outreach

Last month I needed to pull fresh leads from LinkedIn, enrich each with company size and tech stack, then send a personalized cold email—all without hiring a VA.

I tried doing it manually and burned out after two hours.

Instead I built a small ai farm—three agents that hand off work to each other—and let it run overnight, which showed me how ai farms can scale outreach without extra headcount.

Why Most People Start with the Wrong Tool

Many guides tell you to slap everything into one giant prompt and hope the model figures out the steps.

That approach works for a demo but falls apart when you need reliability.

The model starts to forget earlier instructions, mixes up data, and you end up with duplicate or missing fields.

I learned this the hard way after watching my first attempt send the same email to three different prospects.

How to Structure Your ai farms for Reliable Hand-offs

Think of an ai farm as a small factory line where each agent has a single job.

The first agent scrapes LinkedIn profiles and returns a raw JSON blob.

The second agent takes that blob, calls an enrichment API, and adds company size and tech stack.

The third agent receives the enriched data, writes a personalized email, and drops it into a draft folder.

Each agent only needs to know its input format and its output format.

This keeps the prompts short and reduces the chance of drift.

Why do agents duplicate work when scaling?

When you run multiple copies of the same agent at once, they can all pick up the same item from a shared queue.

If the queue doesn’t mark an item as “in progress” before processing, you get duplicate work.

I ran into this when I launched ten scrapers simultaneously and ended up with three copies of the same profile.

The fix is simple: use a queue that supports atomic claim operations, or add a lock file that agents check before they start.

Once I switched to a queue with built‑in claim, the duplicates vanished.

Real Prompt and Cost Example

Here’s the exact prompt I use for the enrichment agent, run through OpenAI’s GPT‑4o.

You are a data enrichment specialist.
Given a LinkedIn profile JSON with keys: name, headline, company, location.
Return a JSON object that adds two fields: company_size (string) and tech_stack (array of strings).
Use public knowledge; if you cannot find a value, set it to null.
Profile: {input_json}

I feed the scraper’s output into this prompt.

Each call uses about 800 tokens.

At the current rate of $0.006 per 1k tokens, that’s roughly $0.0048 per lead.

For a batch of 500 leads, the enrichment step costs under $2.50.

I think that’s a fair price for the time saved—though some might balk at any per‑lead cost.

What Most Guides Get Wrong About Agent Hand‑offs

Most tutorials assume you can just pass the raw output of one agent straight into the next.

They ignore the need for a clear contract between agents.

If the scraper changes its field names, the enricher breaks silently and you get nulls everywhere.

I now version the schema and store it in a shared JSON file that both agents read at startup.

When the schema updates, I bump the version number and the agents automatically adapt.

This tiny bit of governance has saved me hours of debugging.

How to Debug When the Farm Stalls

First, check the queue depth.

If it’s growing, one agent is slower than the others.

Look at the logs of the lagging agent—often it’s hitting a rate limit on an external API.

Second, verify that each agent is acknowledging receipt of its input.

If an agent crashes before sending an acknowledgment, the queue will re‑queue the item and you’ll see duplicates.

Third, test the hand‑off in isolation.

Run the scraper alone, save its output, then feed that file directly into the enricher.

If the enricher works with the saved file but not with the live queue, the problem is in the hand‑off logic, not the prompt.

Finally, keep a simple heartbeat log that each agent writes every minute.

If the heartbeat stops, you know the agent crashed.

These steps have turned what used to be a mystery into a routine check‑list.

Step‑by‑Step Setup

1. Choose an orchestration tool that supports queues and workers—I use n8n workflows because its built‑in queue node handles atomic claims.
2. Create three workflows: Scraper, Enricher, Composer.
3. In the Scraper workflow, use the LinkedIn scraper node (or a custom HTTP request) and output raw JSON to a queue named “raw_profiles”.
4. In the Enricher workflow, set the trigger to “Queue Consumer” on “raw_profiles”, claim one item, run the GPT‑4o prompt shown above, then push the enriched JSON to a queue named “enriched_profiles”.
5. In the Composer workflow, consume from “enriched_profiles”, generate the email text with another LLM call, and save the draft to a Google Sheet or send via SMTP.
6. Set each workflow to concurrency of 1 if you want strict ordering, or higher if you’re okay with parallel processing and have idempotent steps.
7. Turn on execution logs and enable the heartbeat node (a simple cron that writes a timestamp to a file).
8. Run a small test batch of ten leads and verify that each stage receives exactly one item and that the final email looks correct.
9. If you see duplicates, lower the concurrency or add a lock step before the queue consumer.
10. Once the test passes, scale up the concurrency to match your target volume.

I love how n8n’s queue node lets agents wait for each other without custom code—it’s just a configuration toggle.

My gripe? The free tier of n8n limits you to 100 executions a month, which ran out mid‑campaign and left half my leads stuck.

That’s why I upgraded to the $20/mo starter plan; it gives me unlimited workflows and feels like a fair price for the reliability I get.

(Which, yes, is annoying when you hit the limit during a demo.)

Adjacent reading: deeper coverage of AI agent platforms.

If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this workflow as a blueprint at deepusecase.com/vault.