AI Engineer World‘s Fair: How to Automate Conference Outreach

Preparing outreach for the AI Engineer World’s Fair usually means copying speaker bios by hand, drafting generic emails, and losing hours to follow‑up chaos. After reading this guide you’ll be able to pull speaker data automatically, craft personalized messages with AI, and run the whole flow without writing a single line of code.

Scraping speaker data without getting blocked

The first step is to collect names, titles, and recent talk topics from the event’s public speaker list. I use Apollo.io for this because its search engine lets you filter by event name and job title. You paste the event URL into Apollo’s company search, then pull the list of people attached to that company.

Apollo’s credit system feels like a hidden tax — you never know how many credits a search will cost until after you’ve run it. (which, yes, is annoying) Still, the basic plan at $29/mo gives you 10k credits, enough to scrape about 500 speaker profiles, which is plenty for a solo operator.

Once you have the CSV export, you keep three columns: full_name, job_title, recent_talk_topic. Those fields feed directly into the next step.

What most guides get wrong about AI email personalization

Most tutorials tell you to drop the whole CSV into a GPT prompt and hope for the best. That approach produces bland, repetitive lines and often hallucinates details that never existed. The real trick is to give the model a tight template and only one variable at a time.

I think GPT-4 Turbo is overkill for simple email personalization; you could use Claude 3 Haiku and save money. The Haiku model costs a fraction per token and still understands the short, structured prompts we need.

Here’s the prompt I use, stored as a snippet in Make (formerly Integromat):

Write a friendly opening line for a cold email. Use the speaker's name: {{full_name}}. Reference their recent talk on {{recent_talk_topic}}. Keep it under 20 words. Do not add any fluff.

The double curly braces are placeholders that Make.com replaces with each record’s values. The output is a single sentence you can drop straight into the email body.

Why does my automation break when I add a second email step?

Many builders add a follow‑up email step right after the first, then wonder why the scenario stops after the first run. The issue is usually a missing filter: without checking whether a reply has arrived, the second email fires immediately, which looks like a spam burst and gets the account throttled.

Instead, add a router after the first email. One branch goes to a “Wait 3 days” module, the other goes to a “Check inbox for reply” module. Only if no reply is found does the scenario continue to the follow‑up email. This simple split keeps the flow respectful and prevents accidental bans.

I’ve seen this mistake in three different forums, and each time the fix was the same: insert a conditional delay before the second outreach.

How to debug when the email generator hallucinates attendee names

When the AI starts inventing talk titles or mis‑spelling names, the first place to look is the prompt length. If you feed the model a huge block of text, it starts to guess. Keep the input under 200 tokens and give explicit instructions to stick to the supplied fields.

Another common source of hallucination is temperature set too high. I keep temperature at 0.2 for this task; any higher and the model starts to get creative in unwanted ways.

If you still see odd outputs, add a validation step that checks the generated line for the speaker’s exact name. Use a text‑parser module to confirm the name appears; if not, route the record to a manual review queue.

Building the workflow in Make.com

Now let’s put the pieces together. I’ll outline the scenario in plain steps; you can copy them into Make.com’s visual editor.

• Create a new scenario and add a “HTTP > Get a file” module to download the Apollo CSV export (you can schedule this daily).
• Add a “CSV > Parse a file” module to turn the file into bundles, one per speaker.
• Insert a “Router” to split the flow: one path goes to the email generation, the other to a “Stop” module for testing.
• On the email path, add a “Text > Replace” module to insert {{full_name}} and {{recent_talk_topic}} into the prompt snippet shown earlier.
• Connect the output of the Replace module to an “OpenAI > Create a completion” (or Claude) module. Set model to gpt-4-turbo or claude-3-haiku, temperature 0.2, max tokens 60.
• Take the completion text and add it to a “Email > Send an email” module as the opening line. Fill in the rest of the email template manually or with another Replace module.
• After the Send email module, add another Router. Branch A: “Delay > Wait 3 days”. Branch B: “Email > Watch for incoming messages” filtered to the same thread.
• From the Delay branch, go to a second “Email > Send an email” for the follow‑up. From the Watch branch, go to a “Stop” module (reply received, end flow).
• Finally, add a “Data > Store” module to log each outreach attempt to a Google Sheet for reporting.

Each module is clearly labeled, and you can watch the data move step‑by‑step in the scenario history. That visibility is what I love about Make.com — you see exactly where a bundle gets stuck, which makes debugging far less painful than guessing in a code‑only environment.

Pricing and tool breakdown

Here’s what the stack costs per month if you run it at a modest scale of 500 outreach attempts:

• Apollo.io (Basic): $29/mo – 10k credits, enough for 500 speaker pulls.
• Make.com (Core): $9/mo – gives you 10,000 operations, plenty for the scenario above.
• OpenAI (gpt-4-turbo): $0.01 per 1k tokens – roughly $5 for 500 emails at 500 tokens each.
• Alternative Claude 3 Haiku**: $0.0025 per 1k tokens – drops the AI cost to about $1.25.
• Google Sheets (free tier) – sufficient for logging.