A new hire gets an email address on day one; most AI agents get a borrowed OAuth token and a list of tasks. That difference sounds cosmetic. It isn't — it quietly decides who's accountable when something goes wrong.
Here's a filter I find useful for any agent doing ongoing work — support triage, scheduling, outreach: would you onboard a human contractor the way you onboarded this agent?
Sharing one employee's login? No address of their own, so every message they send appears to come from someone else? No calendar, so every meeting they arrange lives on a borrowed one? You'd never run a team that way, because you'd lose the thing organizational structure exists to provide: a stable answer to "who did this, and how do I reach them?"
Software agents have been exempt from that standard mostly because giving them a real identity was hard. It's not anymore.
Agent Accounts — currently in beta — apply the coworker treatment to software. The agent gets a real name@company.com
mailbox that sends and receives, six system folders provisioned automatically (inbox
, sent
, drafts
, trash
, junk
, archive
), and a primary calendar that hosts events and RSVPs to invitations over standard iCalendar. To anyone interacting with it, the account is indistinguishable from one a person operates.
The docs frame it the way you'd frame a colleague: "reachable, persistent, and accountable for its own interactions." Reachable — anyone can email scheduling@yourcompany.com
without knowing or caring that it's software. Persistent — the mailbox and its full history outlive any single deployment, model swap, or rewrite. Accountable — every message it ever sent is sitting in its own sent folder, attributable to it and nobody else.
Mechanically, the account is just another grant: one grant_id
works across the existing Messages, Drafts, Threads, Folders, Calendars, Events, and Webhooks endpoints. The agent uses the same APIs a human-connected account would, which is precisely the point.
Onboarding the non-human coworker is one API call — the same Bring Your Own Authentication endpoint used for other providers, with "provider": "nylas"
:
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": "support@yourcompany.com" }
}'
No OAuth consent screen, because there's no human to consent. From that moment, inbound mail to the address fires the standard message.created
webhook — identical in shape to the one any connected account fires. Your code branches on the grant's provider
field ("nylas"
) when it needs to know a delivery belongs to an agent rather than a person.
When a customer asks "who told me my refund was approved?", the answer with a coworker-style agent is concrete: support@yourcompany.com
did, here's the thread, here's the timestamp. Compare that to an agent acting through a human's credentials — the audit trail says Dana sent it, and now Dana has to prove she didn't.
Identity also changes how people relate to the automation. A voice agent that emails a call recap from voice-agent@yourcompany.com
is something you can reply to, forward, or CC into a thread. A support-triage account at support@yourcompany.com
receives every inbound ticket directly, in its own inbox, where the full history stays searchable. The agent becomes a participant in normal workflows instead of an invisible process hiding behind someone else's name. Trust follows addressability: people extend more of it to things they can reach.
Make it concrete. A support@yourcompany.com
Agent Account receives every inbound support email directly — not a forwarded copy, the actual delivery. Rules attached to the account block known spam domains at the SMTP stage, before the model spends a single token on them. Invoices auto-route to a finance folder. VIP senders get marked for immediate attention. An LLM drafts replies to the common questions; the sensitive ones queue for a human to approve through a webhook flow.
Every piece of that pipeline maps to something you'd recognize from onboarding a person: a desk (the mailbox), standing instructions (the rules), a manager's sign-off on anything risky (the approval queue). The difference is that the standing instructions are enforced by infrastructure instead of memory, and the paper trail writes itself.
The model also scales the way org charts do. A multi-tenant product can provision one Agent Account per customer, each on the customer's own verified domain — scheduling@customer-a.com
, scheduling@customer-b.com
— each with its own policy, its own send quota, its own sender reputation. All of them run in one Nylas application with the same code path. That's a hundred coworkers with a hundred distinct identities, and one payroll system.
Now the honest part. Agents aren't coworkers, and treating them identically is how incidents happen. A human earns trust gradually and exercises judgment under ambiguity; an agent needs explicit, machine-enforced limits from day one, because an LLM in a retry loop has no concept of "this seems off."
So the implementation inverts the metaphor: a coworker gets a performance review, an agent gets a policy object. Send quotas (the free plan defaults to 200 messages per account per day), spam detection, and inbound rules that block junk before the model ever sees it — all attached to the account itself rather than left to the agent's own discipline.
Even the agent's memory is a policy decision rather than a personal trait: the free plan retains inbox mail for 30 days and spam for 7, and retention is configurable through the same policy object that sets the quotas. A coworker remembers what they choose to; an agent remembers exactly what you configured it to.
Offboarding breaks the metaphor too. Humans leave gradually, with handovers and goodbye cake. Agents should be torn down instantly and completely — delete the grant, and the identity is gone. The coworker framing covers identity and accountability. It was never about employment.
The quickstart goes from API key to a working send-and-receive mailbox in under 5 minutes, which is faster than most companies issue a laptop. Provision an account for an agent you already run — even a low-stakes one — and pay attention to what changes once its output has a name attached. In my experience the audit conversation gets shorter, and the "wait, what sent that?" conversation disappears entirely.
Does your agent have an identity of its own, or is it still wearing yours?