An AI agent that can't receive email can't finish a signup form. That one limitation quietly rules out a huge class of autonomous workflows — the research agent that needs a developer account on a data source, the QA agent that registers for a SaaS on every test run, the purchasing agent that needs a buyer profile on a marketplace. Every one of them dies at "we've sent you a verification email."

The blocker was never the form. Headless browsers fill forms fine. The blocker is that verification emails traditionally route to a human inbox, which puts a human back in a loop that was supposed to have none.

Agent Accounts remove that dependency. The agent gets its own hosted mailbox (the feature is in beta), signs up with that address, catches the verification email via webhook, and completes onboarding by itself. Here's the whole flow, condensed from the cookbook recipe.

Provision, subscribe, sign up

Three setup moves. First, create the mailbox — one CLI command, or POST /v3/connect/custom with "provider": "nylas" if you'd rather hit the API:

nylas agent account create signup-agent@agents.yourdomain.com

The API version is the same Bring Your Own Authentication endpoint other providers use — no OAuth refresh token involved:

curl --request POST \
  --url "https://api.us.nylas.com/v3/connect/custom" \
  --header "Authorization: Bearer <NYLAS_API_KEY>" \
  --header "Content-Type: application/json" \
  --data '{
    "provider": "nylas",
    "settings": {
      "email": "signup-agent@agents.yourdomain.com"
    }
  }'

Save the grant ID it prints. Second, subscribe to inbound mail:

nylas webhook create \
  --url https://youragent.example.com/webhooks/signup \
  --triggers message.created

The message.created event fires within a second or two of mail arriving, carrying the message's summary fields. The webhook URL has to be publicly reachable over HTTPS; for local development, the recipe recommends VS Code port forwarding or Hookdeck to expose your dev server.

Third, submit the target service's signup form with the agent's address — a direct API call if the service exposes one, a Playwright/Puppeteer step if it doesn't, or a plain fetch POST when the endpoint is simple:

await fetch("https://saas-you-care-about.example.com/signup", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    email: "signup-agent@agents.yourdomain.com",
    name: "Automation Agent",
  }),
});

Catch the verification email

This is the part that used to require a human. Now it's a webhook handler with three filters and a regex:

app.post("/webhooks/signup", async (req, res) => {
  res.status(200).end();

  const event = req.body;
  if (event.type !== "message.created") return;

  const { grant_id, id: messageId, from } = event.data.object;
  if (grant_id !== AGENT_GRANT_ID) return;

  // Only react to mail from the service you signed up with.
  const sender = from[0]?.email ?? "";
  if (!sender.endsWith("@saas-you-care-about.example.com")) return;

  // Pull the full body (the webhook carries summary fields only).
  const resp = await fetch(
    `https://api.us.nylas.com/v3/grants/${AGENT_GRANT_ID}/messages/${messageId}`,
    { headers: { Authorization: `Bearer ${NYLAS_API_KEY}` } },
  );
  const message = (await resp.json()).data;

  const match =
    /https:\/\/saas-you-care-about\.example\.com\/confirm\?token=[^"\s<]+/.exec(
      message.body,
    );
  if (!match) return;

  await fetch(match[0]); // Complete the signup.
});

For multi-step confirmations, captchas, or OAuth redirects, swap the final fetch for a headless browser following the link. And if the service sends a code instead of a link, the parsing shape is identical — the OTP extraction recipe covers that variant.

The judgment calls the code doesn't show

The recipe's "things to know" section is where the real engineering lives:

Don't trust the first message that arrives. Lots of services send a "Welcome" email before the verification email. The handler above matches the sender and the expected URL pattern before clicking anything — keep both checks.

Lock the inbox down. Pair an allow-list of expected from.domain values with a block rule for everything else. If the agent's address ever leaks, the mailbox stays clean instead of becoming a spam magnet feeding garbage into your automation.

Verify webhook signatures. The handler above trusts req.body for brevity; in production, check the X-Nylas-Signature header on every POST before acting. A signup agent acts on what webhooks tell it, and an unverified webhook endpoint is an unauthenticated entry point into your automation.

Reuse or burn — pick deliberately. One account can serve many signup runs, or you can provision fresh per run and delete after. If you go per-run, teardown belongs in the happy path and the failure path:

nylas agent account delete signup-agent@agents.yourdomain.com --yes

Or, over the API, a plain DELETE /v3/grants/<AGENT_GRANT_ID> — the grant is the account, so deleting one deletes the other. Inactive grants accumulate, and "we'll clean those up later" is how every team ends up with 400 of them.

Know your quota. A free-plan account sends up to 200 messages per account per day, and inbound is generous but not infinite. A large test matrix should spread across multiple grants rather than reusing one.

Respect the terms of service. Programmatic signup is fine for your own testing and first-party integrations. Scraping third parties is a different conversation — nothing in the platform enforces this, but your legal team will care.

Why this pattern is bigger than signups

The verification-email catch is one instance of a general capability: the agent has a durable, addressable identity that other systems can send things to. Receipts, password resets, export-ready notifications, "your report is attached" emails — anything a service communicates over email becomes something an agent can act on, because the agent is reachable the same way a person is.

Some services keep talking after signup, too — follow-up confirmations, "complete your profile" nudges, billing notices. The same webhook handler grows into a full reply loop where the agent reads each message, decides, and responds from the same address it registered with.

The end-to-end loop — provision, register, verify, act — runs against a trial *.nylas.email domain with no DNS setup, so the experiment costs you a webhook endpoint and an afternoon. Pick one service your team signs up for manually today (a staging SaaS, an internal tool, a sandbox API) and automate exactly that signup. Which manual verification step would you kill first?