Whole graph: 13 integration nodes (5x hubspot-update-contact, 2x CustomApiTool_TriggerQualificationAgent, 3x CustomApiTool_TriggerScoringWorkflow, 2x CustomApiTool_SendSMS3, 1x CustomApiTool_AdditionalSMSforNoResume), 2 std-tier prompt nodes (Reply Handling 25,194-ch; Reply Handling with no resume 25,607-ch), 0 code, 0 parse, plus entry + 2 condition nodes. Per reply run exactly one Reply Handling fires, then the Condition routes on next_action: intake $0.025 + 1 model_std $0.10 + Update Contact $0.025 + either {Send SMS 3 + Trigger Scoring = $0.05} or {Trigger Qualification = $0.025} -> $0.175–$0.20 per run (1.75–2.0 credits). No separately measured per-run figure exists (catalog cost_measured says so); cross-check against the measured journey: $1.16 = 11.59 credits per candidate across 4 agents / 6 executions, minus screening 4.0, qualification 2.5 and $0.15 (1.5 credits) of re-entry triggers leaves ~3.6 credits for ~2 reply executions ≈ 1.8 credits each — inside the 1.75–2.0 rate-card band at std tier. No tier gap; a mid-tier assumption on Reply Handling would push a run to $0.275–$0.30 and break the journey arithmetic.

Measured: No separately published per-run figure; the whole measured Favorite journey is $1.16 per candidate (11.59 credits across 4 agents, 6 executions), of which $0.15 (13%) is re-entry triggers between the split agents (credit-rail measured)

Models seen in the graph: preferredModel GEMINI_3_FLASH on all tool nodes (fallbacks GEMINI_3_PRO/GPT4_1/CLAUDE_4_SONNET, GPT4_1_MINI on Reply Handling); resume-branch conditionNode on GEMINI_3_FLASH, but the next_action routing Condition node is pinned to GPT40 — the only non-Gemini primary in the three graphs

Graph read: ama-solution/04-agents/favorite-staffing/prd-reply-process-agent/agent.json (18 nodes, graph.agent.name 'PRD_Reply Process Agent'; flags disregarded per probe rule). Variants: 04-agents/favorite-staffing-us/reply-process-and-job-matching-favorite/ and 04-agents/favorite-staffing-eu-public/2-reply-process-and-job-matching-agent/.

• One model call per run does all the parsing: a single ~25k-char Reply Handling prompt digests confirmations, hours, start dates and corrections and emits a next_action variable; a Condition node then routes on literal matches ('next_action = send_sms_3', 'next_action = trigger_qualification_agent'). 13 of 18 nodes are pure writes/triggers.
• The resume/no-resume duplication from the screening agent continues here (mirrored Reply Handling, SMS-3, Update Contact chains) — prompt changes must be applied to both 25k-char twins, which drift risk makes the priciest maintenance item.
• Cross-agent choreography is webhook-based: every terminal path ends in Trigger Scoring or Trigger Qualification custom API calls — this is exactly where the journey's 13% re-entry overhead is created, and where a merged single-agent build would save $0.15/candidate.
• The routing Condition still pinned to GPT40 amid an otherwise all-GEMINI_3_FLASH graph is a legacy model pin a rebuild should normalize.

• The no-resume lane is the fragile one: on the 2026-07-14 record day (93 candidates absorbed) 5 of 7 reply loops came from the no-resume path (ACTIVITY_LOG.md).
• Reply-loop severity was cut 57% in one week (ceiling 35 -> 15 tasks) during operations tuning — reply loops, not throughput, were the dominant health metric (2026-07-20 weekly, ACTIVITY_LOG.md).
• The structural fix — the EU reply-chat rebuild (agent 52d35526) — sat 7+ weeks without cutover and kept health At Risk; rebuilds modeled as in-flight artifacts (reply-processing/p2-build/01-eu-chat-rebuild/) stall without an owner (CLIENT.md open issue #1).
• 5 of the 9 migrated HubSpot nodes were in this agent (cv-screening 2, qualification 2, reply-processing 5) — the reply agent carries the most write-back surface and gained the most from the 2026-08-26 direct-API migration.

• hrReply Handling03-projects/26-hr/02-resources/module-library/07-候选人沟通-短信.md#1
• hrReply Handling with no resume03-projects/26-hr/02-resources/module-library/07-候选人沟通-短信.md#2