Skip to content

Case study · CS·01 · AI Agent Development

How a 47-node LangGraph workflow reduced HR screening overhead by 75%

Last reviewed: 24 July 2026
ClientHR technology company (client confidential — industry and architecture described with permission-safe anonymity)
EngagementDesign and build of a multi-agent candidate-screening system, via Upwork
My roleSole architect and lead engineer — Rohan Jalil
ConstraintsNo candidate auto-rejection without human sign-off; per-candidate cost ceiling; EU applicant data kept in-region
StatusIn production, processing live requisitions
StackLangGraph · Python · OpenAI API · pgvector · FastAPI · Postgres · Redis

01 Summary

A recruiting team screening hundreds of applicants per requisition replaced its manual first-pass review with a 47-node LangGraph multi-agent workflow. The system parses applications, retrieves the role's scoring rubric, evaluates evidence claim-by-claim, drafts a structured recommendation, and routes every consequential decision through a human approval gate. Screening overhead fell by 75%, measured as recruiter-hours per filled requisition, while every AI recommendation remained traceable to its evidence and replayable for audit.

02 The business problem

Each open role attracted 300–800 applications. Recruiters spent the majority of their week on first-pass screening: reading CVs, checking them against role requirements, and writing short justifications for advance/decline decisions. First-pass quality also drifted — different recruiters weighted the same rubric differently, and the written justifications were too thin to audit later.

The goal was not to remove humans from hiring decisions. It was to remove the mechanical reading-and-collating work while making the remaining human decisions faster, more consistent, and fully documented.

03 Why a linear chatbot was insufficient

A single-prompt "screen this CV" chatbot fails this task in four specific ways:

  • No decomposition. A rubric with 12–18 criteria needs each criterion evaluated against specific evidence; one long prompt produces shallow, inconsistent scoring.
  • No state. Screening is a process — parse, retrieve, evaluate, cross-check, recommend, approve. A stateless chat turn can't checkpoint, retry, or resume.
  • No control flow. Ambiguous applications need a different path (clarification, secondary review) than clear ones. That branching is orchestration, not prompting.
  • No accountability. A chat transcript is not an audit trail. Compliance needed per-criterion evidence citations and a replayable decision log.

04 Agent architecture

The system is a LangGraph state machine of 47 nodes organised into five stages, with checkpointing at every stage boundary. Specialist agents do one job each; a supervisor routes between them based on typed state, not free-text.

# 47-node LangGraph workflow — stage view
intake        parse_application → extract_claims → normalize_profile   (9 nodes)
context       load_requisition → retrieve_rubric → retrieve_precedents (7 nodes)
evaluation    per-criterion evaluators, evidence_binder, contradiction_check
              confidence_scorer                                        (16 nodes)
synthesis     recommendation_drafter → counterargument_pass → redline  (8 nodes)
delivery      human_approval_gate → ats_writeback → audit_log → notify (7 nodes)

# edges: conditional routing on typed state; retry + fallback edges on
# every external call; low-confidence paths detour to secondary review

Three design decisions did most of the work:

  • Typed state over free text. Every node reads and writes a Pydantic-validated state object. Malformed model output fails the node — it never propagates.
  • Evaluators fan out per criterion. Each rubric criterion gets its own evaluator pass with only the evidence relevant to it, then a binder assembles the full picture. This kept individual prompts small, cheap, and testable.
  • A counterargument pass. Before any recommendation reaches a human, a dedicated node argues against it. Recommendations that don't survive get routed to secondary review instead of the approval queue.

05 Retrieval and memory strategy

Retrieval is scoped by stage rather than global. The context stage retrieves the role's scoring rubric and calibrated exemplars — previously approved decisions for similar roles — from pgvector, using hybrid search (dense embeddings plus keyword filters on role family and seniority). Evaluation nodes receive only the evidence spans bound to their criterion, which cut token usage and stopped criteria from bleeding into each other.

Long-term memory is deliberately narrow: approved decisions are embedded and become future exemplars, so calibration improves with use. Candidate personal data is excluded from that memory by schema — only role-relevant evidence summaries persist, and EU applicant data stays in an EU-hosted database partition.

06 Human approval points

The workflow has three gates where a person decides and the agent waits:

  1. Rubric confirmation. A recruiter approves the machine-drafted rubric weighting once per requisition, before any candidate is evaluated.
  2. Advance/decline sign-off. Every recommendation is presented with per-criterion evidence citations. Nothing is communicated to a candidate without a named human approving it — LangGraph's interrupt/checkpoint mechanism holds state until they do.
  3. Low-confidence escalation. Below a confidence threshold, or on any detected contradiction, the case routes to a senior reviewer with the disagreement highlighted.

07 Production safeguards

  • Full decision replay. Every node execution is logged with inputs, outputs, model, and token counts; any decision can be replayed step-by-step for audit or debugging.
  • Cost ceilings in code. A per-candidate token budget aborts to human review rather than overspending; model routing sends easy criteria to a cheaper model tier.
  • Retry with idempotency. Every external call (ATS, embeddings, LLM) has bounded retries and idempotency keys, so a resumed checkpoint never double-writes.
  • Evaluation-gated releases. A 120-case golden set — including edge cases like career gaps and internal transfers — runs on every prompt or graph change; releases ship only when agreement with human decisions stays above the accepted threshold.
  • Bias monitoring. Recommendation rates are monitored across cohorts, with drift alerts routed to the client's people-ops lead.

08 Measured results

75%
Reduction in screening overhead (recruiter-hours per filled requisition)
<48h
First-pass turnaround, down from ~2 weeks
100%
Decisions with human sign-off and replayable evidence trail

The 75% figure compares recruiter-hours per filled requisition in the quarter before launch with the second quarter after launch, once the golden set and rubric calibration had settled. Consistency also improved: per-criterion evidence citations turned decline reviews from opinion-versus-opinion debates into checks against cited evidence.

09 Technology stack

OrchestrationLangGraph (Python) — typed state, checkpointing, interrupts for approval gates
ModelsOpenAI API — tiered routing: frontier model for synthesis and counterargument, smaller model for extraction and per-criterion scoring
Retrievalpgvector with hybrid dense + keyword search; EU data partition
ServicesFastAPI, Postgres, Redis (queues and rate limiting), ATS integration via webhooks
ObservabilityStructured decision logs with full replay; token and cost dashboards per requisition

Engagement details are published with client confidentiality preserved: the client is identified by industry only, and all figures are as measured by the client's own reporting during the engagement.

Next step

Planning a multi-agent build?