Ten seconds. That's how long your endpoint has to return a 200 OK when a Nylas webhook fires — and it's the only latency contract an email agent actually has to meet. Everything else about the workload is bursty, stateless, and event-shaped, which is a near-perfect description of what serverless platforms are built for.

Most email agents spend their lives idle. Mail arrives in bursts, the agent reasons for a few seconds, sends a reply, and goes quiet again. Running a 24/7 server for that is paying for silence. A function that wakes on a webhook and scales to zero matches the workload exactly.

The event source is already push

The reason this architecture works is that you never poll. A single subscription to the message.created trigger gets you a push the moment mail lands in any mailbox on your application:

curl --request POST \
  --url 'https://api.us.nylas.com/v3/webhooks/' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>' \
  --data-raw '{
    "trigger_types": ["message.created", "grant.expired"],
    "webhook_url": "https://yourapp.com/webhooks/nylas",
    "description": "Email agent trigger"
  }'

Compare that with what the providers hand you natively — all of it long-lived, stateful upkeep that fights a scale-to-zero model:

The unified webhook needs no renewals, no connections, nothing for your function to maintain between invocations. There are 43 trigger types if your agent also cares about calendars, threads, or grant health; the real-time webhooks recipe catalogs them. Note the grant.expired trigger in the subscription above — for a serverless agent with no monitoring daemon, that webhook is your health check on connected accounts.

State lives in the mailbox, not the function

The second reason serverless fits: an email agent barely has state of its own. The mailbox is the database. Messages, threads, folders, sent mail — all of it is queryable through the API using one identifier, the grant_id that arrives in every webhook payload.

That's especially clean with Agent Accounts (in beta) — mailboxes your application owns outright, created with one API call (POST /v3/connect/custom with "provider": "nylas"). The function receives a notification, extracts grant_id and the message id, fetches what it needs, acts, and exits. Nothing to persist between invocations except a dedup record.

Here's the whole agent as a single handler, in the Cloudflare Workers style:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    // Challenge handshake: echo the raw value within 10 seconds
    if (request.method === "GET") {
      return new Response(url.searchParams.get("challenge") ?? "");
    }

    const payload = await request.json();
    const { grant_id, id: messageId } = payload.data.object;

    // Dedupe — delivery is at-least-once
    const seen = await env.KV.get(`msg:${messageId}`);
    if (seen) return new Response("ok");
    await env.KV.put(`msg:${messageId}`, "1", { expirationTtl: 86400 });

    // Fetch the full message, then act
    const res = await fetch(
      `https://api.us.nylas.com/v3/grants/${grant_id}/messages/${messageId}`,
      { headers: { Authorization: `Bearer ${env.NYLAS_API_KEY}` } },
    );
    const message = await res.json();

    // ...LLM call, then reply from the same mailbox:
    // POST /v3/grants/{grant_id}/messages/send

    return new Response("ok");
  },
};

The same shape works on Lambda behind API Gateway or a Vercel function — the platform specifics change, the flow doesn't.

Verify signatures before acting

A serverless endpoint is public by definition, and this one can make your agent send email. Every notification carries an X-Nylas-Signature header — a hex-encoded HMAC-SHA256 of the raw request body, signed with the webhook_secret you received when the challenge handshake passed. On Workers, the verification is a few lines of crypto.subtle:

async function verifySignature(raw, signature, secret) {
  const enc = new TextEncoder();
  const key = await crypto.subtle.importKey(
    "raw", enc.encode(secret),
    { name: "HMAC", hash: "SHA-256" }, false, ["sign"],
  );
  const mac = await crypto.subtle.sign("HMAC", key, enc.encode(raw));
  return [...new Uint8Array(mac)]
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("") === signature;
}

One adjustment to the handler above: the HMAC is computed over the raw body, so read await request.text() first, verify, and only then JSON.parse — calling request.json() directly leaves you nothing to sign against. Reject mismatches with a 401 before touching KV or the API. Store the secret as a platform secret (Workers secrets, Lambda environment variables via your secret manager), not in code.

The two constraints to respect

Acknowledge inside the window. The 10-second budget covers your response, not your reasoning. If the agent's work involves an LLM call, don't do it inline — return the 200, then process. On Lambda that means dropping the event onto a queue; on Workers, ctx.waitUntil(); on Vercel, a background function. The challenge handshake is even stricter: echo the raw challenge query value exactly — no quotes, no JSON — or the endpoint is marked failed with no retry.

Dedupe across instances. At-least-once delivery means duplicate notifications, and serverless concurrency means two instances can process the same message simultaneously. An in-memory Set won't save you when each invocation is a fresh instance. Use shared storage with an atomic write — KV, DynamoDB conditional puts, Redis SET NX — keyed on the message id. For an agent that sends email, this isn't an optimization; it's the difference between one reply and two.

What this costs you

Honesty section: serverless isn't free architecture. Cold starts eat into the 10-second window (rarely fatally, but measure). Debugging a distributed event flow is harder than tailing one server's logs. And webhook ordering isn't guaranteed — a message.created can arrive after a message.updated for the same message — so always trust the fetched state over the event sequence.

But for the canonical email agent loop — receive, think, respond — the fit is hard to argue with. The infrastructure bill between emails is zero, and scaling from one mailbox to a thousand changes nothing about the code.

Spin up the smallest version this weekend: one webhook subscription, one function, one mailbox. Send it an email and watch the invocation logs light up. Where do you land on the queue question — process inline with waitUntil, or always go through a queue?