PRD_CV Screening Agent

Where the money goes, per run

Whole graph: 8 integration nodes (2x CustomApiTool_SendSMS1&2, 2x hubspot-update-contact, 2x CustomApiTool_CreateThread, 2x CustomApiTool_TriggerScoringWorkflow) + 2 python Code Executor UUID nodes + 4 std-tier prompt nodes (Extract Job Requirements 12,905-ch, Candidate Data Extraction 5,588-ch, Compare and Score 25,433-ch, Summarize and Notify 6,493-ch) + entry + 1 condition. Per run only one branch executes. With-resume path: intake $0.025 + 3 model_std x $0.10 = $0.30 + 1 code x $0.025 + 4 integration x $0.025 = $0.10 -> $0.45 (4.5 credits). No-resume path: intake $0.025 + 2 model_std (Extract Job Requirements, Summarize and Notify) = $0.20 + 1 code $0.025 + 4 integration $0.10 -> $0.35 (3.5 credits). Measured (catalog): 4.00 credits = $0.40 per candidate, 'exact menu match' (screen-a-candidate $0.375 + intake $0.025; menu.json /lines[1]/modules[1] calibration says the same). The measurement is the exact midpoint of the two branch totals — consistent with std-tier pricing and a roughly even resume/no-resume mix. No tier adjustment needed: assuming mid tier on the three with-resume model calls would give $0.60 + overhead and overshoot; std (GEMINI_3_FLASH, as configured) brackets the measured figure.

Measured: 4.00 credits = $0.40 per candidate, exact menu match ('Screen a candidate' $0.375 + intake $0.025; Notion 'Favorite Staffing - Agent Cost Summary', 2026-02-27) (credit-rail measured)

Models seen in the graph: preferredModel GEMINI_3_FLASH on every tool node except one hubspot-update-contact on GEMINI_3_5_FLASH; fallback chains GEMINI_3_PRO / GEMINI_3_1_PRO / GPT4_1 / GPT4_1_MINI / GPT5 / CLAUDE_4_SONNET; condition node evaluates on GEMINI_3_FLASH

Graph read: ama-solution/04-agents/favorite-staffing/prd-cv-screening-agent/agent.json (16 nodes, graph.agent.name 'PRD_CV Screening Agent'; graph flags isPublished=false/isEverExecuted=false present but disregarded per probe rule). Variant copies exist at 04-agents/favorite-staffing-us/cv-screening-agent-favorite{,-v2}/ and 04-agents/favorite-staffing-eu-public/1-cv-screening-agent/ — the catalog's canonical source is the prd-* file read here.

What a copycat build should know

• The resume/no-resume fork (condition after Extract Job Requirements) spawns two full parallel lanes — separate extraction/summarize prompt, HubSpot write, SMS pair, UUID code node and Create Thread call per lane. A copycat build must maintain near-duplicate node pairs, not one parameterized lane; fixes must land twice.
• The chat-thread ID is produced by a deterministic 783-char Python Code Executor node and handed to the custom Create Thread API — ID generation is never delegated to the LLM (EVIDENCED in both lanes).
• All judgment is concentrated in three large std-tier prompts (Compare and Score alone is 25,433 chars) with per-node cross-vendor fallback chains; there is no separately billed parse node — the CV rides in via isAttachmentDataPulledIn=true on the extraction node.
• Every exit fires CustomApiTool_TriggerScoringWorkflow — priority scoring is external choreography; the catalog attributes $0.15 of the $1.16 per-candidate journey (13%) to these re-entry triggers between the split agents.

Lessons from the client record

• 2026-08-26: all 9 hubspot-update-contact nodes across the 3 US agents were replaced with a direct CustomApiTool_UpdateContact (PATCH /crm/v3/objects/contacts/{objectId}) because the stock Pipedream tool silently dropped values — 13 sampled writes never persisted while nodes reported COMPLETED. New builds should write HubSpot via direct custom integration from day one (sol-favorite-staffing/ACTIVITY_LOG.md).
• Auth gotcha for the custom HubSpot integration: only auth type 'None' + a manual 'Authorization: Bearer' header attached the credential; API Key / Bearer / Connect modes did not (ACTIVITY_LOG.md 2026-08-26).
• Publish regression risk: cv-screening failed 100% (20 runs, HTTP 500 from /tool/execute) on every graph version published 2026-08-25 while older versions kept succeeding — never diagnosed, superseded by the migration; and CLIENT.md's agent ids had gone stale (lists cd48421e/09ada813, live was 8c4bed87). Verify against the live published graph, not repo snapshots.
• Direct-integration PATCH is atomic: one invalid enum discards the whole request — the open CLI-5913 case ('Unknown' configured vs lowercase emitted for facility_confirmed/license_confirmed) 400s the entire update and stops the downstream SMS/trigger node.

Reusable fragments cut from this agent

• hrGenerate Chat Thread UUID - Without Resume03-projects/26-hr/02-resources/module-library/01-取件与建档.md#1
• hrGenerate Chat Thread UUID - With Resume03-projects/26-hr/02-resources/module-library/01-取件与建档.md#2
• hrValidate candidate details with the incoming CV file03-projects/26-hr/02-resources/module-library/02-抽取候选人事实.md#2
• hrExtract Job Requirements03-projects/26-hr/02-resources/module-library/03-抽取职位要求.md#2
• hrScore Qualify SMS Summary03-projects/26-hr/02-resources/module-library/04-匹配与打分.md#4
• hrSummarize and Notify03-projects/26-hr/02-resources/module-library/06-生成交付物.md#3

What it is made of

Screen a candidateEngage a candidateHubSpotSMS via custom APIcustom thread/scoring workflow APIs

ama-solution/04-agents/favorite-staffing/prd-cv-screening-agent/agent.json · solution-intelligence/content/agent-catalog.json (id favorite-cv-screening) · solution-intelligence/content/menu.json (screen-a-candidate, price_per_item 0.375, calibration 4.00 credits) · sol-favorite-staffing/ACTIVITY_LOG.md · sol-favorite-staffing/CLIENT.md · ama-solution/03-projects/26-hr/02-resources/module-library/ (出处 grep)