Screening job applicants with an AI employee: what it does, step by step, and where people decide

Picture the front desk of a busy recruitment office. An applicant walks in and asks which jobs are open. The receptionist checks the current list rather than guessing, helps them pick one, asks the standard first questions, takes a copy of their CV, makes sure it is the right document, files it under the right vacancy, and says “the team will be in touch”. The receptionist does not decide who gets hired. The hiring manager does, later, with the file in front of them.

An AI employee that screens applicants does the receptionist’s job, not the hiring manager’s. This post walks through what it does in Wetel, based on the two patterns in our docs, and marks where a person stays in charge, for the recruitment lead and the developer who builds it.

The short answer: it asks, collects and files; a person decides

A screening AI employee asks applicants a fixed set of questions one at a time, collects their résumé, checks the file, files it in your applicant tracking system and, if you ask for it, produces a structured evaluation of the conversation. It does not make the hiring decision. The docs describe two shapes, which can be combined in one workflow:

A scored first-round interview: a set number of questions, a polite close, and an evaluation generated after the conversation ends.
A messaging-app intake: the applicant picks a role from your live openings, answers screening questions and sends a résumé, which the workflow checks and files.

In both, the result lands with your recruiters, and what happens next is their call.

Step by step: the messaging-app intake

Every message from the applicant runs the same workflow from the top, and the workflow decides which stage the conversation is in. This is the documented shape, simplified:

flowchart TD
  A["Fetch the live list<br/>of open roles"] --> B{"Did the message<br/>carry a file?"}
  B -- no --> C{"Asking which roles<br/>are open, or answering?"}
  C -- asking --> D["List the open roles"]
  C -- answering --> E["Ask the next screening<br/>question, one at a time"]
  B -- yes --> F{"Is it a PDF?"}
  F -- no --> G["Ask the applicant<br/>to resend as a PDF"]
  F -- yes --> H["Fetch the file and file it<br/>under the chosen role"]
  H --> I["Look up the new<br/>application"]
  I --> J["Closing message:<br/>the team will review it"]

Here is what each stage does, and why it is built that way.

1. It reads the real list of openings first. Before any model writes a word, an action step fetches the open roles from your applicant tracking system. Every later step reads that list, so the AI employee answers “which jobs are open?” from your data, not from a plausible-sounding guess.

2. It works out what the applicant wants. A narrow classification step labels the message “asking what is open” or “anything else” (matchAnyOf reduces a chatty answer to one label), and a router sends it down the matching branch.

3. It asks the questions one at a time. The screening step helps the applicant settle on a role from the real list, then asks your standard questions in order, one per message, continuing from the conversation so far. When all are answered, it asks for the résumé as a PDF. Each reply ends the turn and waits for the applicant.

4. It notices the file. When a file arrives through a connected messaging channel, Wetel reads the file details before the workflow runs and hands the workflow ready-made variables (attachmentUrl, attachmentMime, attachmentFilename), empty when there is no file. No model is involved in finding the file.

5. It checks the type before touching the file. A condition step compares the file type with what your system accepts:

{ "expression": "attachmentMime == \"application/pdf\"" }

6. It files the résumé under the right vacancy. An action step fetches the file, and another submits it to your applicant tracking system. The vacancy’s internal id is found with the findId helper, which matches the role the applicant chose against the list fetched in step 1 without asking a model, because models are unreliable at copying ids.

7. It closes the loop. Because the submission’s response may not include the new application’s id, the documented graph reads the list back to find it, then sends a closing message: the application has been submitted, the team will review it and follow up if there is a fit.

What happens when the file is missing, wrong or unreadable

The documented rule is: check first, and give the applicant a clear next step instead of a dead end. Each case behaves differently:

No file yet. The workflow simply stays in the question-and-answer stage. Nothing is filed.
The wrong type, such as a photo of a CV. The type check fails and the applicant gets a polite reply asking them to resend it as a PDF, then the conversation carries on. One caution from the docs: the check uses the type the sender declared (worked out from the file name when the channel gives none), and the fetch step does not inspect the bytes. If it matters that the file really is a PDF, check the fetched content too.
A file that is too large. The fetch is capped at 10 MB; a larger file fails that step rather than being cut short.
A failed fetch or submission. By default a failed action step gives the applicant a generic error reply, and the real reason is in the run record. You can draw success and failure edges on the step instead, so a failure goes to a reply you wrote (“Something went wrong filing that, could you try again?”).
A role the helper cannot match. If the applicant’s chosen role matches no vacancy, or more than one, findId returns 0 rather than guessing. The docs advise routing that case before the write, with a “which role did you mean?” reply.
A résumé the workflow needs to read. An action step can extract the text (PDF and DOCX are supported); an unsupported format fails with an error naming the supported types.

The scored interview: questions, a polite close, then an evaluation

The second pattern is a short structured interview that ends with an evaluation your systems can collect. The agent is created with the INTERVIEW use case, which selects an evaluation shaped for screening. The workflow counts the turns:

flowchart LR
  S["start"] --> T{"Enough questions<br/>asked?"}
  T -- no --> Q["Feedback on the last answer,<br/>then one new question"]
  T -- yes --> C["Polite closing message"]
  C --> E["end session,<br/>with evaluation"]

The docs’ example stops after four questions (turnCount >= 4); set the number to the depth you want. The closing step is told explicitly not to reveal a hire or no-hire decision. The session then ends with runEvaluation: true; leave that out and no evaluation is made.

The evaluation is generated in the background after the conversation ends, so your system asks for it a few seconds later. It holds a score, a recommendation, a summary, strengths, weaknesses, and the full transcript it was generated from.

What the recruiter sees

The recruiter sees the result in your own systems, not in a separate tool. Depending on which pattern you build:

In your applicant tracking system: the application, filed under the vacancy the applicant chose, with the résumé attached.
From the evaluation: the score, recommendation, summary, strengths, weaknesses and the transcript. Wetel does not push this to you yet (outbound notifications are not available); your own backend fetches it after the session ends and passes it to your applicant tracking system.
When something looks wrong: the run record lists which steps ran, what each sent to your system and what came back, so a developer can see whether a problem was the workflow or the system on the other end.

The applicant has been told the team will review the application, and no outcome, because none has been decided.

Where a person decides

The screening does not make the hiring decision, and nothing in these patterns pauses for a person by default. The recommendation in an evaluation is a model’s reading of a conversation. Treat it the way you would treat a junior colleague’s notes: useful, and checked by the person who decides.

There are three places to put people in charge:

The decision itself stays with your recruiters and hiring managers, in your applicant tracking system.
The writes. The documented graph ends with a step that updates the application’s status in your system. Whether an AI employee should change an applicant’s status at all is your call, and it is the step most worth removing or gating.
A sign-off before anything is filed. You can add an approval step before a write. The workflow pauses, a workspace owner sees the request in the approvals inbox, and approves or rejects it; if nobody answers in time it follows an expired path you define. You add this step yourself; it is not built into the screening patterns. Only workspace owners can decide, notices are in-app, and email notice is not available yet. Put a reply before it (“I’ve passed this to the team”) so the applicant knows a person is checking. The human approval walkthrough builds one step by step.

Oversight, stated modestly

The workflow screens against the criteria you write, and only those. The questions, the accepted file types and the evaluation shape are all in configuration your team can read and change. The evaluation keeps the transcript it was generated from, so a person can check a score against what was actually said.

We have not measured the accuracy of these evaluations, or how consistently they score different applicants, and we do not publish a figure. Test the questions and the evaluation on your own roles, with your recruiters reading the transcripts, before you rely on either.

What is live today and what is not

Live today: the building blocks in this post: messaging-channel connections, file details read before the workflow runs, type checks, file fetching and text extraction, the findId helper, success and failure routing, interview evaluations, and an approval step you can add. The changelog records when each arrived.

Not built: Wetel pushing results to your systems (your backend fetches them), email notice for approvals, an approval step that is on by default, and anything that makes the hiring decision for you.

If screening is the work you are weighing up, tell us which work you’d hand over first.

Recipe: First-Round Candidate Screening Agent: the scored interview, its workflow and how to fetch the evaluation
Recipe: Channel Agent with File Intake: the messaging-app intake, the full workflow and its gotchas
Case study: an HR screening assistant: an anonymous first-round screening build
Channels: connecting a messaging app and the file details a workflow receives
Action node: fetching a file, its size cap, and success and failure edges
Workflow best practices: why findId matches ids instead of a model
End Session node: turning the evaluation on
Evaluation & Export: what an evaluation holds and when it is ready
Approval node: adding a person’s sign-off before a write
Observability: reading the run record