Scheduling across four calendars, the interview kit built from the actual scorecard, the onboarding checklist that runs itself, the policy question answered from your handbook rather than from the internet. An agent does the logistics. A human does the judgement — and we mean that as a boundary, not a slogan.
Coordination and drafting · a person decides about a person
A People team is judgement plus an enormous amount of coordination, and the coordination is what stops the judgement happening. Every job below is the coordination half — deliberately.
Find the slot that works for the panel and the candidate, send the invitations with the right materials attached, and re-run the whole thing when one interviewer drops. The single most reliable source of hiring delay, and pure logistics.
For each stage: what this interview is testing, questions that actually test it, and what a strong and a weak answer look like. Generated from your own scorecard in the repo, so a new interviewer runs the same loop as an experienced one.
It assembles what every interviewer wrote, arranged against the scorecard rather than by who typed most, and highlights where two interviewers disagreed. Surfacing disagreement is the point. Resolving it is the panel’s job.
Accounts requested, the reading list assembled, the first-week plan drafted from the role, the buddy pinged. It is a checklist that executes instead of a checklist somebody has to remember to open.
Asked in a Slack thread, answered from the document in your repo with the section quoted. If your handbook does not answer it, it says that and routes to a person rather than filling the gap with a plausible policy.
It reads the roles you already have and the work that team actually does before writing the posting, so the description matches the job rather than the last posting for a similar title.
The output here is deliberately about the process, not about the person. It makes the loop consistent and the bar explicit — which is the part a tool can genuinely improve.
What this stage is for: whether the candidate reasons about failure before they reason about throughput. It is not a breadth check — stage 3 covers breadth, and asking here duplicates it.
Open with a system they have actually operated, not a hypothetical. Follow the first failure mode they name all the way down. A strong answer gets more specific under pressure; a weak one gets more abstract.
Not in scope for this stage, and flagged because interviewers keep straying into it: compensation, notice period, and anything that belongs to the recruiter conversation.
The kit, the schedule, the debrief structure, the onboarding plan. Every one of those is about how you run hiring. None of them is a judgement about a candidate, and that boundary is a deliberate product position rather than a limitation.
Policy answers come from the document in your repo with the section quoted. A question the handbook does not cover gets routed to a person — the gap is reported, not filled.
The value of generating the kit from the scorecard is not speed. It is that the fifteenth candidate gets the same interview as the first, which is a fairness property before it is an efficiency one.
People systems hold the most sensitive data in the company, so the mechanism matters more here than anywhere else on this site. Connect each once for the project; the credential is decrypted on our side and attached to the outbound call.
Easy connect covers 3,000+ apps through their own OAuth screens, and most applicant and HR systems are reached that way. Where one is not, OpenAPI, GraphQL, raw HTTP or a remote MCP server reaches it — and if a system holds data you would rather no agent touched, the correct configuration is not to connect it.
The same session machinery started three ways. In this function the automated mode is best pointed at logistics with a fixed date, never at anything evaluative.
Asked in a Slack thread, answered from the handbook with the section quoted. Questions the handbook does not answer get routed to a person instead of guessed at.
Set anything that sends to a candidate to Ask. The run pauses at the call showing the message and the recipient, and resumes from that exact point once you approve.
A cron trigger opens the session on day one and works the checklist: accounts requested, reading list assembled, first-week plan drafted, buddy pinged. Fixed date, fixed list, no judgement in it.
This is the function where "the agent handled it" would be the wrong answer. The controls below are the platform ones; the first row is the product position.
One project, one set of connectors, one memory that compounds. Each team writes the skills for its own work; nobody stands up a second system.
Open source and self-hostable. Any model, your keys. Kortix Cloud, your own VPC, or your own on-prem network.