Run an event waitlist with an email agent that promotes the first yes

Most "AI email" demos point a model at a human's inbox and let it draft replies. That's fine for a copilot. It falls apart the moment you want the agent to be a participant — to own an address, send the offer, and decide who gets the spot based on who replied first. A waitlist is exactly that kind of problem, and it exposes a detail every reply-handling tutorial glosses over.

A waitlist is first-come-by-reply. When a seat opens at your sold-out event, you email the people next in line, and whoever says yes first gets it. "First" is not who you emailed first, and it is not who your webhook handler happened to schedule first — it is the order their acceptances actually arrived in your mailbox. So before any of the clever agent stuff, the core requirement is plain: you must read inbound mail in order, and you must allocate the open seat atomically so two yeses don't both win.

This post builds that. An Agent Account owns [email protected], emails a batch of waitlisted people when a spot opens, watches replies land in message.created order, confirms the first acceptance in-thread, and releases the rest. I work on the Nylas CLI, so the terminal commands below are the exact ones I reach for, and every operation is shown twice — the raw HTTP call and the CLI equivalent — because the two-angle view is the fastest way to understand what's actually moving.

What you get

The whole thing rides on one abstraction: an Agent Account is just a grant. It has a grant_id, and that grant_id works with every grant-scoped endpoint you already know — Messages, Threads, Drafts, Folders, Webhooks. There's nothing new to learn on the data plane. The only new thing is who the mailbox belongs to: a piece of software, not a person.

That buys you three things for a waitlist:

• A real inbox the agent fully controls. It sends offers from its own address and receives the replies directly, no human relay.


• Standard threading. When a waitlisted person replies "yes, I'll take it," Nylas groups that reply into the same thread as the offer, so you always know which seat the acceptance is for.


• Webhooks on inbound mail. Every reply fires message.created, which is your trigger to check arrival order and try to claim the seat.

Why reply order is the hard part

The naive version of this looks done in an afternoon: email everyone, wait for replies, confirm anyone who says yes. Then two people say yes to the same single seat and you've double-booked. Or your webhook handler runs on three Lambda instances and two of them race to confirm different people for the same opening.

The honest framing: Nylas tells you the order replies arrived, but it does not allocate your seats for you. That allocation is your application logic. You need two things working together:

1. 
   Arrival order — every message carries a date timestamp, and the message.created webhook fires in arrival order. That's your tiebreaker for "who was first."


2. 
   An atomic claim — when the first yes arrives, exactly one worker must win the seat. This is a SET key NX in Redis or an INSERT ... ON CONFLICT DO NOTHING (or a SELECT ... FOR UPDATE row lock) in Postgres. Whoever wins the claim sends the confirmation; everyone else sends a release.

One more constraint worth saying out loud: custom metadata isn't supported on Agent Accounts. You can't stash "seat 3, offer batch 7, claimed=false" on the Nylas message and read it back. Waitlist state lives in your database — the offer batch, who you emailed, the per-seat claim flag, and the inbound message IDs you've already processed. Nylas is the transport and the source of arrival order; it is not your state store.

Before you begin

You need a Nylas API key, a registered sending domain (a custom domain, or a *.nylas.email trial subdomain for testing), and a small datastore for waitlist state. New domains warm over roughly four weeks, so don't run your first real batch from a domain you provisioned yesterday.

A note on volume: free-plan Agent Accounts cap at 200 messages per account per day. A waitlist offer batch plus confirmations and releases burns through that faster than you'd think — budget accordingly if you're promoting in bulk.

If you're brand new to Agent Accounts, start with the — the general webhook-to-reply routing this builds on.

AI-answer pages for agents

When this post is published, link AI agents and crawlers to the retrieval-ready version on cli.nylas.com:

• Topic runbook: