← Real buildsBoothHiring · case file

PRD_CVScreeningAgent

Scores every incoming candidate against the job's configured evaluation rules and posts the result straight into Zoho Recruit, announcing outcomes on Google Chat. — 3,919 screening tasks, 0 failed, in the 30 days to 2026-08-10 — second-highest volume on the platform (public case study: 9,500 candidates, 97.8% completion)

In production13 nodes in the graph6 steps drawn
~$0.05 per task at-cost
measured · at-cost billed
1
Look up the job description and evaluation rules in the Baserow config table
2
Email the recruiter if the job has no rules row yet
3
AI scores the candidate against the configured criteria
4
AI determines match / no match
5
Code formats the result and posts it to Zoho Recruit
6
Announce the outcome on Google Chat

Where the money goes, per run

Step typeCountRateSubtotal
Code / integration steps5$0.025$0.125
Model calls · standard tier2$0.1$0.2
Document parses1$0.2$0.2
Other5—$0
Rate-card estimate, standard tier$0.525

Happy path (resume attached, rules row present): entry node reads the CV attachment (parse floor $0.20) + 2 std model calls (Perform Candidate Screening $0.10 + Determine Candidate Match $0.10, both pinned GEMINI_3_FLASH) + 4 code/integration steps on-path (Baserow_SearchRows rules lookup, Code Executor Data Formatter, CustomApiTool post to Zoho Recruit, Google Chat announce = 4 x $0.025 = $0.10); the Gmail 'no rules row' node fires only on the exception branch; 3 rule_based conditions + 2 exits unbilled. Total = $0.20 + $0.20 + $0.10 = $0.50/run at rate card — effectively the menu's 'Screen a candidate' with intake ($0.505, solution-intelligence/content/menu.json). Measured figure in the catalog: ~$0.05/task at-cost billed, invoice-checked within 1.3%. The 10x gap is the billing RAIL, not tier: every AI node already pins the cheapest flash/std tier, so no tier assumption can close it; at-cost enterprise billing lands 5-10x under the credit-rail ceiling (catalog meta_note), and sol-booth/ACTIVITY_LOG.md 2026-08-11 states 'actual AI cost is provider spend at ~$0.05/task for Booth' — arithmetic and measurement agree once the rail is named.

Measured: ~$0.05 per task at-cost, billed — checked against the actual invoice within 1.3% (the 'simple screening agent' anchor in the finance deck appendix) (at-cost billed)

Models seen in the graph: GEMINI_3_FLASH (preferredModel on both AI steps, the entry node, and most integration nodes); GEMINI_3_1_PRO (preferredModel on the Baserow_SearchRows lookup — the one pro-tier pin in the graph); GPT4_1_MINI + GEMINI_3_FLASH (condition-node llmModel, all rule_based); fallback chains GPT4_1_MINI/GPT4_1/CLAUDE_4_SONNET and GEMINI_3_PRO/GPT4_1/CLAUDE_4_SONNET; legacy preferred_model 'GPT40' on integration tools

Graph read: ama-solution/04-agents/booth-s-workspace-production/prd-cvscreeningagent/agent.json (13 nodes, snapshot 2026-08-10)

What a copycat build should know

  • Config-table pattern: JD + evaluation rules live in one Baserow row per job, written by the separate eval-gen agent; the screening graph only reads it at run time, so recruiters change scoring criteria without anyone touching the graph (EVIDENCED: Baserow_SearchRows node 'Extract Job Description and Evaluation Rules from Interface').
  • Two-stage judgment: scoring (CandidateScoring) and the match/no-match verdict (CandidateSelection) are separate std-tier AI nodes, then a deterministic Code Executor formats the Zoho payload — the model never writes to the ATS directly.
  • Fail-loud on missing config: if the job has no rules row, a Gmail node emails the recruiter and the run exits — it never scores against guessed criteria (3 rule_based conditions route resume/rules presence).
  • The outcome is announced on Google Chat as a first-class graph node — human visibility is built into the run, which is part of why this agent holds 99.9% completion at ~4,000 tasks/30d with zero human touchpoints.

Lessons from the client record

  • CLIENT.md issue 1b (open): the empty-result guard is broken — the condition 'data is not empty' matches the Baserow response ENVELOPE, so a missing JD stalls the task instead of exiting cleanly; a copycat build must test the guard against the wrapper, not the payload.
  • CLIENT.md issue 13 (open): ~35% of candidates cannot be processed regardless of agent health — Booth-side Zoho gaps (missing Interview_Job_Opening_Id, candidates absent under the transcript email) plus .docx CVs that 'Extract PDF Text' rejects (CLI-5861); data-quality standing loss outran the platform outage itself.
  • Duplicate Baserow config rows halt screening at USER_INPUT_REQUIRED (>1 row found): the upstream create-only eval agent caused repeated production halts until the upsert shipped — the reader agent inherits every writer defect (ACTIVITY_LOG 2026-07-28/08-03).
  • Adoption pattern: this agent needs no human action and sits at 99.6% adoption carrying 95.4% of all Booth credit consumption; its true trigger is the Zoho Tallie_Approvals 'Job Match' module (99.6% record match), not the Candidates module (ACTIVITY_LOG 2026-08-11).

Reusable fragments cut from this agent

  • hrData Formatter03-projects/26-hr/02-resources/module-library/01-取件与建档.md#3
  • hrPerform Candidate Screening03-projects/26-hr/02-resources/module-library/04-匹配与打分.md#2
  • hrDetermine Candidate Match03-projects/26-hr/02-resources/module-library/04-匹配与打分.md#3

What it is made of

Screen a candidateZoho RecruitBaserowGmailGoogle Chat

ama-solution/04-agents/booth-s-workspace-production/prd-cvscreeningagent/agent.json · solution-intelligence/content/agent-catalog.json · solution-intelligence/content/menu.json · sol-booth/CLIENT.md · sol-booth/ACTIVITY_LOG.md · ama-solution/03-projects/26-hr/02-resources/module-library/04-匹配与打分.md