Hiring happens in email until it lands on a calendar. An AI recruiting agent needs an identity that spans both.
Recruiting is a communication job before it is anything else. For every hire there are dozens of candidates, and for every candidate there is an outreach message, a reply, a screening call to book, an interview panel to coordinate, a reschedule when someone’s flight moves, and a confirmation the night before.
A recruiter’s week is lived in two tabs, email and calendar, switching between them until the offer goes out. So when teams build an AI recruiting agent, they are automating exactly that: a workload that is half inbox and half calendar. Give the agent only one of the two and it can start conversations it cannot finish.
Where borrowed setups fail
The usual first attempt is to run the agent inside a recruiter’s own mailbox. It works at first, and the problems arrive quietly. Candidate replies land mixed into the recruiter’s personal mail, so the agent is reading and writing in someone else’s account, with that person’s rate limits and login. When the recruiter changes teams or leaves, the account is deactivated and every live candidate thread goes with it. Sourcing tools that only send have the opposite problem: the outreach goes out at volume, but the “yes, I’m interested, does Tuesday work” reply has no inbox to land in and no thread to belong to. The candidate answered and nobody was home.
If you build recruiting software, you may be thinking your product already handles email and scheduling, and it does, on human identities. It sends from your recruiters’ mailboxes and books on your interviewers’ calendars, so every action your product takes belongs to a person. An autonomous agent is the first actor in your system that is not a person, and it needs an identity of its own for the same reason your recruiters do.
Nylas Agent Accounts give the recruiting agent its own identity instead: an address like recruiting@yourcompany.com with a mailbox and a calendar on a single account, created through the Nylas API. You provision it with one call to POST /v3/connect/custom and the address can send, receive, and book from the moment it exists. The screening logic and the judgment stay in your application; what Nylas runs is the identity the agent communicates through.
From outreach to a booked interview
Say you open a role next week. Your agent works the sourcing list from its own address, and a candidate writes back. The reply lands in the same mailbox, a message.created webhook announces it, and the reply threads onto the original message automatically, so the agent always works from the full history with that candidate rather than one message at a time. It can tell an interested reply from a not-right-now, answer questions about the role, and collect what the pipeline needs before a recruiter picks it up. The recruiter steps in where judgment does: deciding who moves forward, running the interview, making the offer. The agent owns the coordination in between.
Then comes the step the whole pipeline is waiting on, getting the interview on the calendar. The agent checks its own calendar with a free/busy query, offers the candidate times that are genuinely open, and once the candidate picks one, creates the event through the Events API. The invitation goes out over standard iCalendar, so it lands in the candidate’s Google Calendar or Outlook as a normal meeting invite from a participant. If your interviewers’ calendars are also connected to Nylas, the agent can run the same availability query across them and only propose slots that work for the panel, from the same API it is already using. Your humans stay on connected accounts, the agent gets an Agent Account, and it is all one integration.
Interviews move constantly. Candidates are interviewing elsewhere, panelists get pulled into incidents, flights change. Because the agent’s inbox and calendar live on the same account, the “so sorry, can we push to Thursday” email and the calendar event it refers to are visible to the same identity. The agent reads the reply, updates the event, and sends the corrected invitation without a person reconciling a scheduling tool against an inbox. Declines show up too: when a panelist RSVPs no, the agent sees it and can rebook before the candidate ever knows there was a gap. When a negotiation gets genuinely tangled across several people and time zones, the agent works it the way a coordinator would, proposing alternatives on the thread and updating the event once the panel lands.
Before your agent meets a candidate
Every message the agent sends is a candidate’s first impression of the company hiring them. Three things have to hold before it is safe to automate.
The first is candidate experience and deliverability. Outreach that lands in spam or arrives from a strange address costs you people you never even get to interview. Every Agent Account sends from a domain you control, and its reputation with mail providers is yours alone, not shared with anyone else’s sending. Underneath is the same email and calendar infrastructure Nylas has run in production for more than a decade.
The second is control, because recruiting email represents your employer brand. Each account carries policies and rules you set: send limits, allowed attachment types for resumes and take-home assignments, domains it may write to, and outbound rules evaluated before a message leaves. If you want a human to approve every offer-stage message, that stays your call, in your application logic, with the agent doing everything up to the send.
The third is the one your legal and security teams ask: candidate data is personal data, so who hosts the mailbox and what is it certified for? Agent Accounts carry Nylas’s compliance posture on every plan, from the free tier up: SOC 2 Type II, HIPAA, ISO 27001, ISO 27701. For recruiting platforms selling into regulated industries, that is often the difference between clearing a customer’s security review and stalling in it.
If you already build on Nylas, there is nothing new to integrate. An Agent Account returns the same grant_id shape your code already handles, and the Messages, Threads, Events, and Webhooks endpoints behave identically against it. Recruiting products that already sync recruiter and interviewer calendars through connected accounts can add an agent identity with one more call, without onboarding a new vendor or sitting through another security review.
For an ATS or staffing platform, your customers are hiring companies, and the agent writes to candidates on their behalf. A candidate trusts mail from the company they applied to; the same message from your platform’s domain reads like spam. So each hiring company verifies its domain once, and from then on your application provisions an Agent Account on it like any other resource. Policies live on each account, and each company’s reputation with mail providers lives on its own domain, so one customer’s heavy sending week never touches another’s deliverability. Onboarding a new customer becomes part of signup rather than an infrastructure project.
You can build the whole loop on the free tier, which includes three Agent Accounts, before you pay anything. When it is time to put it in front of candidates, the Full Platform plan starts at fifteen dollars a month and scales with usage. Provision the account, hand it your pipeline, and let it carry a candidate from first hello to a confirmed interview without dropping the thread.
Sign up (or sign in if you already have an account) to create your first Agent Account. If you want to see the calendar side before you build it, the Agent Accounts calendar docs cover hosting events, invitations, and RSVPs.
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
