How we coordinate interview loops

Once a candidate clears a screen, scheduling the next round becomes its own small project: read the interview plan to see who's on the panel, find a time when every one of those interviewers is actually free, propose it to the candidate, and get invites onto everyone's calendar before the slot goes stale. None of it is hard, but it's tedious across several interviewers and several candidates at once, and every day it sits undone is a day the loop stalls.

We run an interview-scheduling agent on Kortix that does the coordination every day. For every candidate marked ready to schedule in Greenhouse, it reads the interview plan, checks the panel's availability on Google Calendar, and drafts a slot proposal to the candidate plus the calendar invites for each interviewer. It never sends anything and never touches a hiring decision — a coordinator reviews every proposal and invite before it goes out. This is how we keep our own interview loops moving.

The problem

Scheduling an interview loop means combining two things that live in different systems: the interview plan — who's on the panel, how many rounds, how long each one runs — sits in Greenhouse, while whether those people are actually free sits in their calendars. Checking both by hand, for every candidate who clears a screen, is the kind of coordination work that's easy to fall behind on the moment more than one requisition is open at once.

The usual workarounds don't hold up. A shared scheduling link only works if every interviewer keeps it current, and it says nothing about who the panel actually is for this candidate. A coordinator juggling several calendar tabs and a Greenhouse tab in parallel can do it, but it doesn't scale past a handful of loops, and a slipped invite reads as disorganized to a candidate who's interviewing elsewhere too.

What we built

On Kortix, a daily cron triggers an agent. It spawns a fresh session (a cloud sandbox) that reads every candidate marked ready to schedule in Greenhouse, pulls that candidate's interview plan to see who's on the panel, checks each panelist's Google Calendar for open slots, and drafts a slot proposal for the candidate along with a calendar invite per interviewer. Every draft lands with the coordinator; the agent sends nothing and decides nothing about the candidate.

How it works

Guardrails

The agent touches a candidate's next step in the hiring process, so the boundary between "proposed" and "confirmed" is the control that matters:

• Isolation. Every run happens in its own microVM sandbox. Only the drafted proposal and invites leave the sandbox.
• Scoped secrets. The Greenhouse and Google Calendar credentials are encrypted in the Secrets Manager and injected into the sandbox at runtime, never exposed to the model or the logs.
• Human approval gate. The agent never sends the candidate proposal and never sends a calendar invite. Every draft is held for the coordinator to review, adjust, and send.
• No hiring decisions, ever. The agent cannot reject a candidate, advance a stage, or send an offer. It schedules the next conversation; it never decides whether that conversation happens.
• Everything is code. The scheduling conventions and per-system permissions are files in the repo, versioned and changed through a reviewed change request rather than a dashboard setting.

The outcome

Scheduling an interview loop now starts with a proposal and a set of invites already drafted against the panel's real calendars, instead of a coordinator opening five tabs to find one time that works. The coordinator's day starts with a review instead of a hunt, and every send and every hiring call still stays with a person.