4 Files, One Interview Brief: The Bot That Preps the Human Your hiring manager opens the CV in one tab, hunts through Gmail for the application thread in another, digs up the role scorecard in a shared drive, and joins the call three minutes late still not sure what to ask.
That is 15 minutes of tab-switching before a 30-minute interview.
This post walks through the exact bot I build for clients that turns those four scattered inputs into a single evidence-linked briefing packet — without letting the model touch a hiring decision.
The one rule that keeps this safe: the bot preps humans, it does not judge them This bot prepares the interviewer.
It does not score, rank, reject, advance, or message the candidate.
That boundary is the entire reason the workflow is worth building first.
Every automation vendor demo I have seen starts at the riskiest step — resume scoring — which is exactly where bias, EEOC exposure, and bad candidate experience live.
Flip the order.
Automate the boring information-gathering that your hiring manager is doing badly at 8:57 AM, and leave the judgment where it belongs.
Practically, that means the bot has three hard "no" rules baked into the system prompt and the workflow logic itself: No numeric fit score, no "recommend hire / no hire" language, no ranked comparison across candidates.
No candidate-facing output.
The bot writes to the interviewer only.
No stage changes in the ATS.
If you use Greenhouse, Ashby, or a spreadsheet, the bot reads.
A human writes.
If you skip this framing, the same code becomes a compliance problem the moment a rejected candidate asks how the decision was made.
The 4 inputs, and the boring identifier problem that breaks most builds The four inputs are: calendar event, candidate CV, application form response, and role scorecard.
The one people skip is the scorecard, and without it the model produces a fluent summary that has nothing to do with what you are hiring for.
Keep the scorecard to five fields so a hiring manager will actually maintain it: Field Example (customer support role) Role title Senior Support Specialist, SaaS Must-have Fluent written English, 2+ yrs ticketing (Zendesk/Intercom), B2B SaaS exposure Nice-to-have SQL basics, technical writing samples Concerns to verify US timezone overlap, availability start date, examples of angry-customer handling Interview areas Written comms sample, live triage exercise, escalation judgment The second boring problem: one clean identifier per candidate.
Email is the only reliable one.
Names collide, LinkedIn URLs get edited, phone numbers are missing half the time.
If your calendar event only has a name, matching becomes a guessing game the moment you interview two people named David Chen in the same quarter.
The fix is a title convention, not code: Or put the email in the event description field.
Not glamorous.
But every reliable automation I have shipped starts with a boring, consistent input format.
The trigger, the extractor, and the "do not guess" rule The trigger is a scheduled job that runs every 10 minutes and looks for calendar events with an label starting in the next 30-60 minutes.
When it finds one, it pulls: candidate email, candidate name, interviewer name, role title, event start time, meeting link.
If any critical field is missing, the bot does not guess.
It sends the interviewer a short exception notice and stops.
Silent guessing is how automations create embarrassing failures — the wrong candidate summary sent to the wrong interviewer, or a briefing about "David Chen" that mixes two people's CVs.
An exception notice takes 20 seconds for a human to fix.
A hallucinated brief takes a week of trust to rebuild.
Fields the trigger must always confirm before proceeding — the join key for every downstream lookup — required to load the correct scorecard — required to send the brief to the right person — required to schedule delivery 30 min before Gmail search, CV extraction, and keeping the payload small Once the trigger has the candidate email, the bot searches Gmail with a narrow query.
Broad searches ("everything from this person, ever") are how you end up with a 40,000-token context window full of scheduling back-and-forth.
Then apply three filters: Newest CV wins.
If the candidate sent three versions, use the most recent.
List older files as source links, do not blend them into the extracted text.
Extract with page references.
For PDFs, keep metadata alongside every text chunk. or both work.
This is what lets the final brief cite "CV page 2" instead of a vague summary.
Pull only the fields the interviewer needs from the application form.
Work history, key open-ended answers, portfolio links, stated availability.
Skip the "how did you hear about us" field.
The payload going into the model should be small and labeled.
For a typical candidate this is roughly: Source Size Calendar event ~200 tokens CV (extracted, page-labeled) 1,500-3,000 tokens Application form (filtered) 400-800 tokens Selected email threads (max 3) 500-1,500 tokens Role scorecard 200-400 tokens Total input ~3,000-6,000 tokens At current Claude Sonnet or GPT-4-class pricing, one briefing runs about $0.03-$0.08.
Dumping every email would push that past $0.50 per brief and would make the citations unverifiable.
The prompt: labels, citations, and no opinions Every input chunk gets a source label before it hits the model.
This is the single change that separates a useful brief from an AI-generated opinion.
The system prompt then enforces the boundary: That "no evidence found" clause is the anti-hallucination lever.
Without it, the model will happily write "Jane has strong SQL skills" because SQL is on the scorecard, even though nothing in her CV mentions it.
Delivery, review, and what a good brief looks like at 8:30 AM The brief lands in the interviewer's inbox (or Slack DM) 30 minutes before the call, with the meeting link at the top and the source index at the bottom.
Every claim has a bracketed citation the interviewer can click.
A real one looks roughly like this: The interviewer skims for 3 minutes, spots the "no evidence found" gap, and knows exactly what to probe.
That is the whole product.
What breaks in the first two weeks of running this Calendar events without the email in title or description — fix the convention, do not patch the code.
Gmail label drift ("Recruiting-2026" vs "Recruiting") — normalize labels once, monthly.
CVs sent as image-only PDFs — add an OCR fallback (Tesseract or a vision model) and flag the brief as "OCR used, verify accuracy." Interviewer forwards the brief to the candidate by accident — put a visible header on every brief.
Why bizflowai.io helps with this This is exactly the class of workflow I ship for small teams at bizflowai.io — the boring, high-leverage pre-work that a human still owns the decision on.
For hiring specifically, that means the calendar-triggered briefing bot above, plus adjacent pieces like a scorecard template your managers will actually fill in, exception routing when inputs are missing, and the source-labeled prompt structure that keeps the model from inventing evidence.
Nothing in the stack scores or rejects candidates.
Every decision stays with your hiring manager, and they walk into the call already prepped.
Want more like this?
I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.
Subscribe to bizflowai.io on YouTube — never miss a new tutorial.
Planning an AI automation project or need a second opinion on your architecture?
Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.
Visit bizflowai.io for our services, case studies, and AI consulting.