You've built the agent, the reply loop works, the demo lands — and then someone asks the question you didn't budget time for: "so what address does it send from?" Suddenly you're staring at noreply-svc-prod2@yourcompany.com realizing that the first thing every recipient sees isn't your prompt engineering. It's the From line.

An agent's email address is an interface. Humans parse it before the subject, mail servers judge it before the body, and spam filters score it before any human sees it at all. Once your agent has a real mailbox — which is what Nylas Agent Accounts (currently in beta) provide — address design becomes a product decision with three layers: the local part, the domain, and the disclosure question.

The local part: role beats persona beats hash

Take three candidate addresses for the same scheduling agent:

• scheduling@ — a role. Tells recipients what the mailbox does and implies that emailing it is how you use the service.
• jane.ai@ — a persona. Friendlier in a sidebar avatar, but it invites recipients to treat the sender as a colleague, with all the expectations that carries.
• bot-7f3a@ — an artifact. Screams "auto-generated," gets mentally filed next to spam, and gives a human nothing to anchor on.

The docs consistently model the first pattern — sales-agent@, support@, scheduling@ appear throughout the Agent Accounts overview — and I think that's right for a reason deeper than convention. A role address makes an honest promise about capability: scheduling@ claims it can schedule, nothing more. A persona address makes an implicit promise of general competence that current agents can't keep. When jane.ai@ fails to understand a simple request, it reads as a person being obtuse; when scheduling@ fails, it reads as a tool hitting its limits. Same failure, different trust damage.

The overview's framing is worth internalizing: an agent identity should be like any other user in your organization — reachable, persistent, accountable. Address design is how that accountability becomes visible.

Claiming the address is one API call

Once a domain is registered and verified, the address itself costs nothing but the decision. Creating the account with your chosen alias is a single request — "provider": "nylas", no OAuth, no refresh token:

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": "scheduling@agents.yourcompany.com"
    }
  }'

The response carries a grant_id that drives the mailbox from then on. The same creation works from the CLI — nylas agent account create scheduling@agents.yourcompany.com — or from the Dashboard, where you pick a registered domain and an alias and the account is live immediately.

That cheapness cuts both ways. It means you can prototype three naming patterns in an afternoon and reply-test them on real recipients. It also means nothing stops you from minting bot-7f3a@ because a UUID was lying around. Remember that the address is the one part of the system whose history you can't transplant: months of threads, recipients' contact lists, allowlists in customer systems, accumulated sender reputation. Provisioning is disposable; identity isn't. Choose the local part like you'll keep it.

The domain: a subdomain is cheap insurance

The provisioning docs recommend a dedicated subdomain for production — agents.yourcompany.com — and the reasoning is reputation isolation: sender reputation accrues per domain, so your agents' sending behavior never contaminates the domain your humans and your marketing depend on. If an experiment misbehaves, the blast radius is the subdomain.

Registering a domain is a one-time event per organization: add it from the Dashboard or API, pick the data center region (US or EU), publish the MX and TXT records, and verification happens automatically once DNS propagates. After that, you mint addresses under it freely. A few patterns from the docs scale this up:

• Per-customer domains in multi-tenant apps: scheduling@customer-a.com, scheduling@customer-b.com, each on the customer's own verified domain with its own send quota — 200 messages per account per day on the free plan — and its own sender reputation. One application can manage an unlimited number of registered domains, so this doesn't fragment your infrastructure.
• Environment separation: agents.staging.yourcompany.com vs agents.yourcompany.com, so test traffic never touches production reputation.
• Reputation sharding: high-volume senders split across sales-a.yourcompany.com, sales-b.yourcompany.com so one domain's deliverability issue doesn't spread.

One caveat on subdomains: don't let isolation drift into obfuscation. agents.yourcompany.com signals "automated, but officially ours." A lookalike domain that hides the relationship signals something much worse.

(For prototyping, trial addresses use the format alias@<your-application>.nylas.email — fine for testing, but the format itself tells recipients nothing about you, which is one more reason to move to your own domain before anything customer-facing.)

The disclosure question

Should the address admit the sender is an agent? My position: the system should disclose, and the address is the cheapest place to do it. Role addresses on an agents subdomain disclose structurally — no recipient who glances at scheduling@agents.acme.com will mistake it for a person, and nobody feels deceived later.

The counterargument deserves a fair hearing: persona addresses measurably improve open and reply rates in outreach, and plenty of teams ship alex@ agents for exactly that reason. Short-term, they're probably right. But that uplift is borrowed against the moment a recipient realizes they've been having a heartfelt back-and-forth with a language model that signed off as Alex. The reply-rate gain is yours; the trust debt lands on your whole domain — the same domain all your other mail comes from. That trade looks worse every quarter as recipients get better at spotting synthetic correspondence.

There's a middle path that keeps most of the warmth: role address, human-adjacent display name. "Sam (Acme Scheduling Assistant)" <scheduling@agents.acme.com> reads friendly in the inbox list and honest on inspection.

Before your next agent ships, write down its From line — display name, local part, domain — and show it to someone outside the team with one question: "who do you think sent this, and what happens if you reply?" If their answer doesn't match your architecture, fix the address before you fix the prompt. Which pattern have you shipped, and did recipients ever call it out?