Run an enrollment agent from a school's admissions inbox

Admissions inboxes are a grind. Most of what lands in [email protected] is some variation of the same three questions — what's the deadline, what documents do I still need, did you get my transcript — interleaved with the documents themselves arriving as PDF attachments. A human reads each one, looks up the applicant in the SIS, checks which docs are still outstanding, and writes back. Then, a week before the deadline, someone exports a spreadsheet and manually nudges everyone who hasn't finished.

The naive "AI" version of this points an LLM at a counselor's personal mailbox and lets it draft replies. That works right up until you want the agent to be the admissions desk — to send mail under its own address, receive replies in its own thread, hold the application state for every applicant, and fire deadline reminders without a human in the loop. A drafting assistant bolted onto a person's inbox can't do that. It has no identity of its own.

This post builds the version that does, on a Nylas Agent Account. I work on the Nylas CLI, so every step below is shown twice: the raw curl against the API, and the nylas command I'd actually type. Pick whichever fits where the operation lives — your webhook worker probably speaks HTTP, but your ops runbook and your one-off debugging speak CLI.

What an Agent Account actually is

Here's the part that makes this tractable: an Agent Account is just a grant. Same grant_id you'd get from connecting a Gmail or Microsoft account, except it isn't backed by a human's mailbox — it's a first-class inbox that your application owns. That means nothing new to learn on the data plane. Every grant-scoped endpoint you already know — Messages, Threads, Attachments, Drafts, Folders — works exactly the same. The agent just happens to be the account.

You create one by pointing POST /v3/connect/custom at a registered domain:

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",

    "name": "Admissions Bot",

    "settings": { "email": "[email protected]" }

  }'

Or, the way I'd do it from a terminal:

nylas agent account create [email protected] --name "Admissions Bot"

No OAuth dance, no refresh token, no provider quirks. The API auto-provisions a default workspace and policy for the account. If you need a custom policy later — say, to constrain what the agent can do — you attach it with nylas workspace update <workspace-id> --policy-id <policy-id>. There's no --workspace flag on create; the workspace comes for free.

For production you'd use your own custom domain. For prototyping, a *.nylas.email trial subdomain works, with the caveat that new sending domains warm up over roughly four weeks before they're trusted by the big mailbox providers. Free-plan limits are worth knowing up front too: 200 messages per account per day, 3 GB of storage per org, and a 30-day inbox retention window. For a small admissions cycle that's plenty; for a whole incoming class, plan your domain and plan.

Full details live in the — the reply-detection and thread-context pattern this builds on