The first read is where the bar moves
An open role draws more applications than anyone can read carefully. That pressure lands on the first read, the cheapest step in the process to rush: a few seconds per resume, a glance at the last job title. Two reviewers can read the same application and reach different verdicts without either misreading a word. Each works from their own memory of what the role needs.
The criteria drift next. A requirement that mattered in March stops mattering by June, not because anyone decided it should, but because nobody wrote down how to weigh it. Keyword filters fix the wrong part of this. They reject on a signal the role never listed, drop strong candidates quietly, and leave no record of the reason.
An AI screener that ranks against its own sense of a good candidate swaps one inconsistency for another, and the second one is harder to argue with. A recruiter who skimmed can be asked what they saw. A score with no rubric behind it cannot be checked by the hiring manager, or by the candidate. A year later, nobody can say why that application was turned down.
The rubric is a file, and every score carries its quotes
Kortix runs this screening on its own inbound applications (kortix.com). A new application is the trigger. Each one starts a fresh session in its own sandbox, seeded with that resume alone, so one application maps to one run on one disposable machine. A screen never inherits state from the applications before it.
The role's written rubric travels with the agent as skills and memory. It carries the required and preferred criteria, what strong evidence looks like for each one, and how to score. The agent scores against that file and nothing else. The screen it writes has four parts. Strengths, gaps, a score, and the quotes from the resume that support each judgement.
That last part is what makes a screen usable in an argument. A hiring manager who disagrees can point at the quoted line and say why. When the rubric changes, someone edits the file, and the next screen follows the new version. The old one stays in the history, so the bar at the time is on record.
What the agent may not do
It never rejects anyone. It cannot advance a candidate, send an offer, or treat its own score as final. The agent produces the screen and, for strong matches, a set of proposed interview slots. A person makes every advance-or-reject call.
A rejection therefore has a person's name on it and a written screen behind it, and the screen names the lines it read. That is a different artifact from a rank position. A rank position is easy to produce and hard to explain, and the explanation is exactly what a candidate or a works council asks for.
Screening output also shapes who gets interviewed, so the scope of what the agent reads matters as much as what it writes. On this workflow a session reads the one resume it was seeded with and the hiring manager's calendar. Only the screen and the proposed slots leave it.
The scheduling half keeps the confirm with a coordinator
Scheduling starts where screening ends, and it has its own version of the same failure. The interview plan sits in the ATS. The panel's real availability sits in their calendars. Nobody holds both in their head for more than one candidate at a time. A shared booking link only helps if every interviewer keeps it current, and it says nothing about which panel this candidate actually needs.
The scheduling agent Kortix runs fires once a day (kortix.com). Each firing starts a fresh session, so the list of candidates ready to schedule and the panel's availability come from the current state rather than yesterday's run. For every candidate marked ready in Greenhouse, it pulls the interview plan and checks each panelist's Google Calendar. Then it drafts a slot proposal for the candidate, with one invite per interviewer.
It sends nothing. A coordinator starts the day with a batch of proposals, adjusts a time if a panelist's week changed, confirms, and sends. Candidates get one proposed time that every panelist can actually make, and the coordinator keeps the last look before anything reaches a candidate's inbox or an interviewer's calendar.
What a person still decides
Three decisions stay where they were. A person advances or rejects each candidate. A person confirms the slot. A person owns the rubric, which means owning the criteria, the weighting and the evidence standard that the agent applies.
The exceptions land with a person too. An internal candidate applying through the external portal, a resume in a language the rubric never covers, a referral who arrives by email instead of the ATS. Those cases need a judgement the rubric does not contain, and the screen simply says so.
What the packaged screeners do well
The screening products built for volume are good at the part that breaks a paper process, and Workday sets out the trade. It describes automated screening against predefined criteria, candidate matching, predictive analytics, and bias reduction by removing identifiers such as name, age and gender from the first pass. It adds the caveat that matters: a model is only as unbiased as the data behind it. Organizations need to audit the models and keep a person in the decision (workday.com).
Pete & Gabi's Rebecca AI is a screening product built for staffing teams. Its page describes resumes parsed as they arrive and scored on five role-specific criteria configured per job. Ranked shortlists and candidate summaries sync to the applicant tracking system, and it runs fraud detection on candidate profiles (petegabi.com).
Both are built to make a high-volume funnel move, and a staffing team with thousands of applications a week has a real reason to buy one. The difference a buyer can check is where the scoring rules live and what the output lets them defend. In a packaged screener the criteria, the weighting and the scoring sit inside the vendor's product, configured in its interface. Here the rubric is a file in a git repo the company owns, and every score cites the resume lines behind it. The agent has no authority to move a candidate to the next stage.
Wiring it to the systems that already hold the record
The reach comes from connectors: the applications inbox or the ATS for the trigger and the interview plan, Google Calendar for panel availability, email for the drafts. Nothing is migrated. The ATS stays the record and the calendar stays the calendar, and the agent reads both under scopes you grant. Connector credentials are brokered server-side and never enter the machine.
Outbound steps deserve a gate, and the gate is a per-action setting rather than a global switch. Approval gates you set. Off until you set them. Put one on the candidate email and on the invites, or on any connector action that reaches a person outside the team.
The rubric, the agent's configuration and its permissions are files in the repository. A change to the evidence standard appears as a diff on those files. Editing the same setting in the dashboard commits to the default branch, so the file history is the record a hiring manager can hand over. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan. A month after a hiring round, the sessions show which applications were read, what each screen said and which decisions a person made.
Open source. Read it, fork it, audit it. That matters more for screening than for most HR software. A screening system is the one piece of HR software a regulator, a candidate or a works council may ask to inspect. The policy desk is the other side of the same setup, and the five HR workflows it belongs to run on the same project.