An assistant that works over email and calendar has to be reachable. It cannot borrow yours.
The way people actually use an executive assistant has never really changed: you loop them in. “Adding my assistant to find time.” The assistant takes the thread from there, checks the calendar, proposes options, books the meeting, confirms the details, and follows up afterward. Everyone on the thread knows who they are talking to, and nobody needs an app, an account, or a booking link to participate. It is delegation over the most universal channel there is.
AI executive assistants inherit that same shape, and it surfaces the identity question immediately: when someone writes “adding my assistant,” what address is on the cc line? A human assistant can work inside your inbox but still has an address of their own. An AI assistant deserves the same arrangement.
Where the borrowed inbox breaks
Two shortcuts get tried first, and both fail in a way that only shows up after the assistant is live.
The first is to run the assistant inside the executive’s own mailbox, through delegate access or an OAuth grant on their account. It demos well, and the trouble surfaces later. Everything the assistant sends comes from the executive, so a recipient reading “let me check and get back to you” assumes the executive wrote it, and every scheduling mistake reads as the executive’s own. The assistant works under someone else’s login and someone else’s sending limits, sized for one person keeping up with their own inbox, not software working a queue. Assistant mail and personal mail sit in the same folders permanently, so there is no clean way to audit what the agent did or to move the workload to a different tool later. And when that executive changes companies and IT deactivates the seat, every thread the assistant was holding goes with it.
The second shortcut is the booking link. Rather than giving the assistant an identity, you give it a URL and let the other side do the work. That hands the work back to the person who wanted it done. A booking link cannot read the thread it was pasted into, so it does not know the meeting is a follow-up to last week’s call or that the person asking is a customer rather than a vendor. It cannot answer a question, decline on your behalf, or chase a reply that never came. A booking link is a fine tool for inbound scheduling. It is just not an assistant: someone wanted to talk to your assistant, and a link cannot talk back.
If you are building an assistant product rather than running one for yourself, this is the ceiling you hit early. Your integration already sends and books on connected accounts, which holds up as long as every action belongs to the user who authorized it. The assistant is the first actor in your product that is not one of your users, and the first one people will try to address directly.o the user who authorized it. The assistant is the first actor in your product that is not one of your users, and the first one people will try to address directly.
That is what a Nylas Agent Account is: a hosted email and calendar identity the assistant owns outright, like assistant@yourcompany.com, created through the Nylas API with one call to POST /v3/connect/custom. The account comes back as a grant with a mailbox and a primary calendar, and the assistant operates both. The judgment about what to say and what to book lives in your product; Nylas runs the identity the assistant works from.
From cc to confirmed meeting
Say your assistant went live this morning. Someone cc’s the assistant on a thread, or writes to it directly. The message arrives in the assistant’s own inbox and a message.created webhook wakes the agent with it. Nylas keeps replies on the same thread using standard In-Reply-To and References headers, so the assistant reads the whole conversation, not a fragment, and “let’s do the call we discussed last week” actually means something to it. To schedule, it runs a free/busy query, proposes times that are open, and once someone agrees, creates the event through the Events API and sends invitations that land natively in Google Calendar and Outlook. Invitations flow the other way too. When an invite arrives addressed to the assistant, it lands in the mailbox like any other participant’s, the matching event appears on the assistant’s calendar, and the assistant can accept or decline through the RSVP endpoint. Follow-ups, recaps, and the “confirming tomorrow at 10” message all go out from the same address the conversation started on. And the meeting is only the visible half of the job: the same loop lets the assistant triage what arrives, draft replies for your sign-off, and chase the follow-up nobody answered.
The email and the calendar being one account is not a convenience, it is the job. An executive assistant’s entire function lives at the seam between inbox and calendar: reading intent out of messages and turning it into scheduled time, then defending that time when things move. Split those across two systems and you have rebuilt the coordination problem the assistant was supposed to remove. On one identity, the “can we push our call” email and the event it refers to are visible to the same agent, which reads the message, moves the event, and sends the updated invite in one motion. When a negotiation gets genuinely messy across several people and time zones, the assistant works it the way any assistant would, proposing alternatives on the thread and updating the event once everyone agrees.
How the assistant earns your trust
Letting an agent send and book on your behalf takes trust. The account gives you three ways to build it.
Oversight is the first. You will want to see what your assistant is saying on your behalf, especially early. Create an app password for the Agent Account, and Outlook or Apple Mail can open the assistant’s mailbox like any other. You read exactly what it sent and received, and if you step in and reply yourself, that reply flows back through the same account, so the assistant picks up with full context of what you said. That is supervision without a special dashboard.
Control is the second. Each Agent Account carries policies and rules you define: how much it can send, which domains it can write to, what attachments the mailbox accepts, and outbound rules evaluated before a message leaves. The address itself sits on a domain you verify and control, so the assistant’s sending reputation belongs to you rather than a shared pool, and mail from it looks like mail from your company. You choose what the assistant may do autonomously and what waits for your approval, and you can tighten that at the account level without touching the agent’s code.
Compliance is the third, because an executive’s mail is some of the most sensitive data a company has. Agent Accounts carry Nylas’s compliance posture on every plan, including the free tier: SOC 2 Type II, HIPAA, ISO 27001, ISO 27701. The infrastructure underneath has run email and calendar in production for over a decade. If you are building an assistant product for customers rather than for yourself, that is the answer their security teams are going to ask for.
From one assistant to an assistant product
For teams already on Nylas, the addition is one call. An Agent Account is another grant: same grant_id pattern, same Messages, Threads, Events, and Webhooks endpoints your integration already uses. And if you are building an assistant product, the multi-tenant shape is the point: one Nylas application provisions an identity for each customer’s assistant, each on a domain that customer verifies once, with its own policies and its own reputation with mail providers, all one code path. Your customer’s assistant is theirs, at their address, from day one.
Dana Intelligence, an AI personal assistant product, already runs this today: every user who signs up gets a dedicated mailbox and calendar for their assistant, and every inbound email becomes a live agent turn. A small team shipped a hosted email identity for every user without managing MX records, SMTP infrastructure, or Google’s restricted scope review.
The free tier includes three Agent Accounts, enough to run an assistant end to end before paying anything, and the Full Platform plan starts at fifteen dollars a month when you scale. Provision the address, cc it on something, and see how it feels when “adding my assistant” is a sentence your software can finish.
Sign up (or sign in if you already have an account) to create your first Agent Account. The Handle email replies recipe shows the reply loop the assistant runs on.
Email and Contacts API 
Calendar API & Scheduler 
Notetaker API 
Agent Accounts 
Sales & CRM 
Recruiting & ATS 
Healthcare
Financial
Legal
Real Estate
Education
Field Services
Docs
SDKs
Guides
Integrations
API status
Changelog
Support
Enterprise
