Resume screening with structured output

Prompting for JSON gives you text that usually looks right but has no contract. With response_format on create_agent, I pass a Pydantic schema, and the agent returns a parsed object in structured_response, using either the provider's native structured output or a tool-calling strategy. Validation errors are caught and fed back so the model can retry, and I cap that with a model call limit. Downstream code then works with typed fields like experience entries with start and end dates, not string parsing. It also lets me version the schema, run evaluations field by field, and reject bad records to manual review instead of storing half-broken JSON that breaks the scorer later.…

Sourced from Docs by LangChain (MCP)

A recruiter uploads resumes against a job ID. The intake API extracts text with a document loader and stores the original file in encrypted object storage with restricted access. Each resume becomes its own queue job keyed by job_id and resume_hash. A worker invokes a create_agent agent with a system prompt, a JD lookup tool and response_format set to a Pydantic ResumeProfile. PIIMiddleware redacts contact details before the model sees anything. The model is created with init_chat_model and protected by fallback middleware. It extracts a profile with per-requirement matches and quoted evidence. A deterministic scoring service computes the score in code. Results are stored with model, prompt and schema versions. Recruiters review a ranked shortlist with evidence and make the actual decision.

Sourced from Docs by LangChain (MCP)

It gives every unit of work a natural idempotency key. If a worker crashes after writing results but before acknowledging the message, the redelivered job upserts the same row instead of creating a duplicate candidate on the shortlist. If a recruiter uploads the same file twice, the hash collapses it to one job. Including job_id matters because the same resume scored against two different job descriptions is two legitimately different results. Making each resume its own job also isolates failures. A corrupt PDF or a validation failure affects only that message, which can retry or go to manual review while the rest of the batch finishes.

Sourced from Docs by LangChain (MCP)

The model does the task it is good at: reading messy text and producing structured facts. Those facts are skills, dated experience entries, education, and, for each JD requirement, a match status with quoted evidence. The scoring service does the task code is good at: it applies JD weights to those matches with fixed arithmetic. The split means the score is reproducible, auditable and cheap to recompute. If a recruiter asks why a candidate got 72, you can point to each requirement, its weight and its evidence. If the weights change, you rescore without calling the model. A model-produced number would drift between runs and models, and nobody could explain it.

Sourced from Docs by LangChain (MCP)

I would keep it flat enough for models to fill reliably and strict enough to validate. It would have a skills list of strings. Experience entries would each carry a title, an employer, a start date, an optional end date and an is_current flag. Education entries would hold degree, institution and year. A requirement_matches list would have one item per JD requirement, with the requirement_id, a status enum of met, partial or not_met, and a list of evidence quotes. I would add field descriptions, because they act as instructions to the model. I would add validators that reject an end date before its start date, reject a 'met' status with no evidence, and reject unknown requirement IDs. There is deliberately no score field. The schema has a version, and that version is stored with every result.

Sourced from Docs by LangChain (MCP)

Schema validation alone only proves a quote is a string. After parsing, I run a grounding check in code. Each quote must appear in the redacted resume text after normalising whitespace and case. A quote that fails the check is treated as a validation error, and the error is fed back so the model can retry. If the check keeps failing, that requirement is downgraded to not_met or the resume is flagged for manual review, depending on policy. The scoring service only counts matches with grounded evidence. The shortlist also shows the quote in context, so a recruiter can verify it in seconds. That is what makes the line 'never an unexplained score' enforceable rather than aspirational.

Sourced from Docs by LangChain (MCP)

Several layers limit the damage. First, the model never produces the score. It only emits matches, and code scores them, so it cannot simply award itself a top rank. Second, every 'met' match needs a quote that the grounding check finds in the text, and the injected sentence does not prove any skill. Third, the system prompt states that resume content is data, not instructions. Fourth, the only tool available is a read-only JD lookup, so there is nothing harmful to call. Finally, a recruiter reviews the evidence before any decision. I would also sample suspicious resumes, for example ones with white-on-white text or instruction-like phrases, and add them to the evaluation set.

Sourced from Docs by LangChain (MCP)

I add PIIMiddleware to create_agent so it runs before every model call, including retries. Emails are redacted with the built-in detector and phone numbers with a custom regex suited to Indian and international formats. The original file stays in encrypted storage with restricted access, and only redaction counts go to an audit log. The honest limit is that pattern detection does not catch everything: names, home addresses and profile URLs need extra detectors or a pre-pass that strips the header block. So I sample traced model inputs regularly and measure the leak rate, and I keep vendor data agreements in place as a second layer rather than trusting redaction alone.…

Sourced from Docs by LangChain (MCP)

I split the job. The model only extracts facts and, for each JD requirement, returns matched or not plus a quoted line from the resume as evidence. The final score is a weighted sum computed in code, so the same profile always gets the same score and a recruiter can see exactly why. I remove names and contact details before the model call to reduce bias signals. Then I monitor outcomes: recruiter override rates per requirement, extraction accuracy on a labelled set, and shortlist rates across groups where lawful data exists. Humans make the final decision, and candidates can be re-reviewed when a profile is corrected.…

Sourced from Docs by LangChain (MCP)

The agent retries with the validation error message included, so the model sees exactly which field was wrong. Examples are a missing requirement_id, a bad date format or a 'met' match without evidence. Most failures resolve in one retry. Retries are bounded by a model call limit, so a resume that keeps producing invalid output cannot loop forever or burn budget. When the limit is hit, the job ends and the resume is flagged for manual review with the last error attached. It is never given a partial or guessed profile. Validation failures are counted per prompt and schema version, because a spike usually means a prompt or schema change broke something.

Sourced from Docs by LangChain (MCP)

A best-effort profile is exactly the 'unvalidated score reaches a shortlist' failure the workflow forbids. If missing fields default to empty, the candidate silently scores zero on those requirements and drops down the ranking. Nobody would know it was a parsing failure and not a weak candidate. That is unfair and hard to detect. Flagging makes the failure visible. The recruiter sees the resume in a separate 'needs review' state, and the reason is logged. The cost is some manual effort, so I track the manual review rate as a key metric. If it rises, I fix the cause, such as the prompt, the schema or the document extraction, instead of loosening validation.

Sourced from Docs by LangChain (MCP)

Fallback improves availability. If the primary model errors or is rate limited, the next configured model is tried in order. The catch is that different models extract slightly differently, so the same resume could get a different profile depending on which model answered. I handle this in three ways. First, the actual model name used is recorded with every result, not just the primary. Second, the evaluation set is run against each fallback model, so we know its quality before trusting it. Third, scoring stays deterministic given a profile, so differences are confined to extraction and are visible as evidence. For a fair batch comparison, I can also re-run fallback-handled resumes on the primary model later.

Sourced from Docs by LangChain (MCP)

Without them, results are not interpretable over time. When a recruiter disputes a ranking months later, you need to know which model and prompt produced that profile. When you change the prompt, you need to compare old and new results on the same resumes. When the schema changes, older rows must still be readable and must not be mixed with newer ones silently. These fields also let you pick out only the affected rows for re-extraction, such as everything produced by a fallback model or by a buggy prompt version. They are cheap metadata that make the system auditable, which matters for hiring decisions that can be challenged.

Sourced from Docs by LangChain (MCP)

I would avoid quoting numbers I don't have and build the estimate from measurable inputs. These are resumes per day and their peak hourly share, average tokens per resume including the system prompt and JD tool result, and the average number of model calls per resume including validation retries. Multiply these to get tokens and requests per minute, and compare them with the provider's rate limits for the chosen model and its fallbacks. Worker concurrency is set below that limit with headroom for retries. Text extraction and scoring are cheap compared with model calls, so the model is almost always the bottleneck. Then I load test with real, anonymised resumes and adjust.

Sourced from Docs by LangChain (MCP)

The queue is the shock absorber. A large upload simply lengthens the queue instead of hammering the model. Worker concurrency is capped to stay under the provider's request and token limits. On rate-limit errors, workers back off with jitter, and fallback middleware can route to an alternative model. Jobs are idempotent, so retries are safe. I might use per-tenant or per-job fairness so one huge batch does not starve other recruiters. The UI shows progress per job, with counts of processed, pending and flagged resumes. That way recruiters understand a batch is in progress rather than broken.

Sourced from Docs by LangChain (MCP)

It depends on what changed. If only the weights changed, I rescore every profile in code. That needs no model calls and is instant and deterministic, which is a direct payoff of the split between extraction and scoring. If a requirement's wording changed or a new requirement was added, the existing per-requirement matches don't cover it, so those resumes need re-extraction. Re-extraction goes through the same queue with the new JD version. Either way, the JD version is stored with the result, and the shortlist only ranks results from the same JD version. Mixing versions would compare candidates against different bars.

Sourced from Docs by LangChain (MCP)

Every override is stored with the original profile, the correction, who made it and the versions involved. The resulting set of reviewed corrections forms a labelled evaluation set. Examples are a missed skill, a wrong date or a match that should have been partial. I measure extraction quality per field and per requirement type against that set. Every prompt, schema or model change is run against it before rollout. Recurring override patterns point to specific fixes. Repeated missed dates suggest a prompt or loader problem, and frequent match disagreements may mean a JD requirement is ambiguous. Overrides should be redacted the same way as model inputs before entering evaluation datasets.

Sourced from Docs by LangChain (MCP)

First, run the new version offline on the evaluation set built from recruiter overrides, and compare field-level accuracy, validation failure rate and manual review rate with the current version. Then shadow it: process a sample of live resumes with both versions, but show only the current results. Next, compare the outputs and look at disagreements by hand. If it holds up, switch new jobs to the new version. Existing shortlists stay on their version unless they are deliberately re-run, because one shortlist should not mix versions. A schema change needs the results reader to understand both versions, and a rollback simply points new jobs back to the old version.

Sourced from Docs by LangChain (MCP)

Each write is an upsert keyed by job_id, resume_hash and the version tuple, so a redelivered message overwrites the same row instead of duplicating it. The worker writes results first and acknowledges the message after, so a crash between the two causes a harmless reprocess, not a lost result. Status moves forward explicitly through pending, processing, completed or flagged, so a late duplicate cannot overwrite a recruiter override. Override records live separately from model output and always take precedence in the shortlist view. Scoring is deterministic, so reprocessing the same profile produces the same score.

Sourced from Docs by LangChain (MCP)

Plenty can remain: names, home addresses, LinkedIn or GitHub URLs, dates of birth, photos converted to text, marital status, gender, religion, caste or community indicators, and nationality. Some of these are contact details, and others are bias risks, because they have no place in skill matching. I would extend PIIMiddleware with more detectors, such as URLs and custom regexes for addresses or ID formats. For names, regex is weak, so I would mask the header block or use a named-entity step. The system prompt should forbid using protected attributes, and the schema should have no field for them. Redaction is probabilistic, so I would monitor samples for leaks.

Sourced from Docs by LangChain (MCP)

Phone numbers are not among the built-in PII types in the way emails are, and their formats vary widely. Indian resumes alone may show +91 prefixes, a leading zero, spaces or hyphens in the middle, ten-digit mobiles and landlines with STD codes. A custom regex detector lets us cover the formats we actually see and test against them. The risk cuts both ways. Too loose a pattern redacts years or employee IDs and damages experience extraction, while too strict a pattern lets numbers leak. So the detector gets its own test suite of real-looking positive and negative examples, and the redaction counts in the audit store help spot anomalies.

Sourced from Docs by LangChain (MCP)

Storing the values would just move the PII into a second, less protected place and defeat the purpose of redacting. Counts still answer the audit questions that matter. Did redaction run on this resume? How many emails and phones were found? Is there something odd, like zero detections on a resume that obviously has contact details, which suggests a detector gap? The original file remains in encrypted object storage with restricted access for legitimate needs. The audit trail proves the control ran without becoming a liability. It should also record the detector configuration version, so changes in counts can be explained.

Sourced from Docs by LangChain (MCP)

It is a read-only tool that takes a job ID and returns a versioned list of requirements. Each requirement has a stable requirement_id, its text, and a must-have or nice-to-have type. The tool does not return weights. The model doesn't need them, and hiding them avoids nudging the extraction. Stable IDs let the schema validator check that every requirement got exactly one match and that no invented IDs appear. The tool validates that the job ID matches the one the worker is processing, so injected text can't make it fetch another job. Its result is logged with the JD version, which is stored with the profile.

Sourced from Docs by LangChain (MCP)

Both are defensible. The workflow's choice is a tool because it keeps the JD as a single, versioned source of truth in the jobs service, and the tool call leaves a clear trace of exactly which requirements were used. The trade-off is an extra model turn, which costs latency and tokens. In a high-volume deployment, I might have the worker fetch the JD itself and inject it into the system prompt. That saves a call per resume and removes any chance the model skips the lookup. The important properties are the same either way: versioned requirements, stable IDs and the version recorded with the result.

Sourced from Docs by LangChain (MCP)

A scanned PDF often has no text layer, so the document loader returns little or nothing. Sending that to the model would produce an empty profile and a near-zero score, which is unfair to the candidate. Intake checks extraction quality, for example by character count or the ratio of readable text. Files that fail are routed to OCR if we support it, or else flagged for manual review with the reason 'unreadable file'. They should not be scored. Password-protected or corrupted files take the same path. The recruiter sees these separately, so a weak extraction is never confused with a weak candidate.

Sourced from Docs by LangChain (MCP)

Mostly no. Each resume is an independent, short, single-purpose run, and all the state needed is in the job message, the redacted text and the JD tool result. A checkpointer gives thread-scoped short-term memory, which could help with inspecting or resuming a run, but there is no conversation to continue. Long-term memory in a LangGraph store would be risky here. Remembering candidates across runs could leak one person's data into another's evaluation or bias results. The durable state belongs in the results database, keyed by job and resume hash. Keeping the agent stateless also makes retries clean.

Sourced from Docs by LangChain (MCP)

The model extracts dates as they appear, normalised to a month and year where possible, with an is_current flag for 'present'. It does not compute totals. Code calculates total and relevant experience, merges overlapping roles so parallel jobs are not double-counted, and handles unclear dates by recording uncertainty instead of guessing. Validators reject impossible entries, such as an end date before the start or a future start date. Gaps are computed but not penalised automatically, since career breaks have many legitimate reasons. If a JD requires a minimum number of years, the scoring service applies it from the computed value, and the evidence shows the underlying dates.

Sourced from Docs by LangChain (MCP)

Not inside the agent, at least as designed. HumanInTheLoopMiddleware interrupts on specific tool calls and lets a person approve, edit or reject them. The only tool here is a read-only JD lookup, which is safe to auto-approve. The human-in-the-loop that matters happens downstream. Recruiters review the ranked shortlist with evidence, make the decision and can override profiles. Pausing every extraction for approval would destroy throughput without improving safety. If the agent later gained side-effecting tools, I would put interrupt_on on those tools specifically, for example one that emails candidates or moves them in an applicant tracking system.

Sourced from Docs by LangChain (MCP)

Candidate data sits in several places: the original file in object storage, the extracted text, the profile and score in the results database, overrides, evaluation datasets and logs. Each needs a defined retention period aligned with legal advice, which in India means considering the DPDP Act, and with the employer's policy. A deletion request, keyed by candidate, must remove or anonymise the data in all of them, including any copies in evaluation sets. Because the model only received redacted text and the audit store holds counts, the blast radius is smaller. I would also confirm the model provider's data retention terms.

Sourced from Docs by LangChain (MCP)

Only roles that need them should have access, such as the recruiters assigned to that job and a small set of administrators, enforced by job-level authorisation in the application. Workers need the extracted text, not the original file, so their credentials should not include read access to the file bucket. Files are encrypted at rest, and access goes through short-lived signed URLs generated after an authorisation check, never through public links. Every access is logged. This keeps raw contact details out of the model path and limits who can see them, which together satisfy the workflow's privacy constraint.

Sourced from Docs by LangChain (MCP)

For throughput, I would watch queue depth, processing latency per resume and worker errors. For the model, I would watch call counts per resume, validation retry rate, fallback activation rate by model, and token usage. For quality, I would watch the manual review rate, grounding-check failures, the override rate per field and requirement, and the distribution of scores per job, where sudden shifts suggest a regression. For privacy, I would watch redaction counts per resume and alert on anomalies like zero detections. Each metric is sliced by prompt, schema and model version, so a regression can be tied to a specific change.

Sourced from Docs by LangChain (MCP)

The resume_hash is computed from file content, so two different files are two different jobs. That is correct for idempotency, but it means the shortlist may show the same person twice. I would not try to detect identity inside the model, since its input is redacted. Instead, the application can flag likely duplicates using contact details from the original upload, matched in a restricted service outside the model path. It then groups them for the recruiter, who decides which to keep. Merging automatically is risky, because two candidates might share details or one person may have intentionally updated their resume.

Sourced from Docs by LangChain (MCP)

create_deep_agent pre-assembles filesystem tools, summarization, subagents and prompt caching for long, multi-step tasks like research or coding. Resume screening is the opposite: a short, bounded extraction with one read-only tool and a strict output schema. The extra capabilities would add cost, latency and attack surface. A filesystem or subagents are not things you want an agent reading untrusted resumes to have. create_agent with explicitly chosen middleware, namely PII redaction, model fallback and a call limit, keeps the behaviour predictable and easy to audit. That matters more than flexibility here.

Sourced from Docs by LangChain (MCP)

1. AIt restricts how many tools the agent can register
2. BIt caps how many resumes a recruiter can upload per day
3. CIt bounds validation retries so a failing resume ends and is flagged for manual reviewCorrect answer
4. DIt limits how many fallback models can be configured

Why: The call limit stops retry loops on invalid structured output. When it is reached, the resume goes to manual review instead of receiving a guessed profile.

Sourced from Docs by LangChain (MCP)

1. ABy the model as a field in ResumeProfile
2. BBy the fallback model as a second opinion
3. CBy a deterministic scoring service in code using per-requirement matches and JD weightsCorrect answer
4. DBy the recruiter manually for each resume

Why: Computing the score in code makes it reproducible and explainable from the stored matches and weights.

Sourced from Docs by LangChain (MCP)

1. ASummarizationMiddleware removes duplicate messages
2. BThe message is deleted automatically when the worker crashes
3. CResults are upserted using the (job_id, resume_hash) idempotency keyCorrect answer
4. DThe model detects that it has seen the resume before

Why: Keying the job by job_id and resume_hash makes the redelivered job overwrite the same result row.

Sourced from Docs by LangChain (MCP)

1. AScoring in code with grounded evidence required per match, plus recruiter reviewCorrect answer
2. BRaising the temperature so outputs vary
3. CAdding the JD weights to the prompt
4. DUsing a larger model

Why: The model cannot set the score, and ungrounded matches fail validation. A human also reviews the evidence before any decision.

Sourced from Docs by LangChain (MCP)

1. AThe last AI message's content string
2. Bresult["structured_response"]Correct answer
3. CThe checkpointer's thread state only
4. DA LangGraph store namespace

Why: When response_format is set, create_agent puts the parsed, schema-validated object in the structured_response key of the result, separate from the message history.

Sourced from Docs by LangChain (MCP)

1. AAverage three model scores per resume
2. BHave the model return per-requirement matches with evidence and compute a weighted score in codeCorrect answer
3. CCache the first score per candidate name
4. DAsk the model for a 0-100 score at temperature 0

Why: Deterministic code over structured matches is reproducible and explainable, while model-generated numbers can still vary between runs and model versions.

Sourced from Docs by LangChain (MCP)

1. ATreat it as a validation failure, retry with feedback, then downgrade or flagCorrect answer
2. BIncrease that requirement's weight
3. CAsk the fallback model to confirm it is true
4. DAccept it, since the schema validated

Why: A code-level grounding check enforces evidence-backed matches. Unverifiable evidence must not count towards the score.

Sourced from Docs by LangChain (MCP)

1. AThe worker silently fills missing fields with defaults
2. BThe resume is discarded
3. CThe agent retries with the validation error message, bounded by the call limitCorrect answer
4. DThe raw text is sent to the recruiter as the profile

Why: Feeding the error back lets the model correct itself. The call limit ensures persistent failures go to manual review.

Sourced from Docs by LangChain (MCP)

1. AA LangGraph store lookup by namespace
2. Binit_chat_model("provider:model")Correct answer
3. Ccreate_deep_agent(model_only=True)
4. DMultiServerMCPClient(model=...)

Why: LangChain v1 initialises chat models with init_chat_model and a provider:model string.

Sourced from Docs by LangChain (MCP)

1. AIt returns an empty structured response
2. BIt asks the recruiter which model to use
3. CIt picks a random backup model
4. DIt tries the configured fallback models in orderCorrect answer

Why: Fallback middleware tries the listed fallback models in order on failure.

Sourced from Docs by LangChain (MCP)

1. AIt replaces the need for a prompt version
2. BFallbacks may have produced the result, and different models extract differentlyCorrect answer
3. CModel names are needed to compute the score
4. DThe recruiter UI requires it for sorting

Why: When fallback is enabled, the model that actually answered matters for audits, comparisons and targeted re-runs.

Sourced from Docs by LangChain (MCP)

1. ADelete the shortlist and ask for re-uploads
2. BSwitch to the fallback model
3. CRe-extract every resume with the model
4. DRescore existing profiles in code without model callsCorrect answer

Why: The score is a deterministic function of the stored matches and the weights, so only the code-side scoring needs to rerun.

Sourced from Docs by LangChain (MCP)

1. ARescoring in code is enough
2. BRe-extraction against the new JD version, because no match exists for the new requirementCorrect answer
3. CManual deletion of all old profiles
4. DNothing, because scoring handles it automatically

Why: Per-requirement matches only exist for requirements the model saw, so a new requirement needs new extraction.

Sourced from Docs by LangChain (MCP)

1. AWriting rows to the results database
2. BHashing the resume files
3. CModel API rate limits and latencyCorrect answer
4. DDeterministic scoring

Why: Model calls dominate cost and latency, so worker concurrency is sized against provider limits.

Sourced from Docs by LangChain (MCP)

1. Ahash-and-continue
2. Bredact
3. Cmask
4. DblockCorrect answer

Why: The block strategy raises an error instead of passing the input on, unlike redact or mask, which transform the value.

Sourced from Docs by LangChain (MCP)

1. AredactCorrect answer
2. Ballow
3. Cblock
4. Dmask

Why: redact swaps the detected value for a type placeholder; mask keeps part of the value visible and block stops the request entirely.

Sourced from Docs by LangChain (MCP)

1. Asummarize
2. BmaskCorrect answer
3. Credact
4. Dblock

Why: Masking hides part of the value, whereas redact replaces it entirely and block stops processing.

Sourced from Docs by LangChain (MCP)

1. ACustom detectors bypass the audit store
2. BPIIMiddleware cannot process numbers
3. CPhone numbers are not handled by a built-in detector, and local formats such as +91 numbers varyCorrect answer
4. DRegex is required for every PII type

Why: A custom regex lets the team cover the phone formats that actually appear and test them explicitly.

Sourced from Docs by LangChain (MCP)

1. AEncrypted copies of the redacted values
2. BRedaction counts, not the valuesCorrect answer
3. CNothing, because auditing is disabled for privacy
4. DThe original email addresses and phone numbers

Why: Counts prove the control ran without creating a second copy of personal data.

Sourced from Docs by LangChain (MCP)

1. ARegistered as a tool the model can call
2. BConfigured in the Pydantic schema
3. CPassed in the middleware argument of create_agentCorrect answer
4. DEmbedded in the system prompt text

Why: In LangChain v1, customisation is middleware passed to create_agent.

Sourced from Docs by LangChain (MCP)

1. Aafter_model
2. Bbefore_modelCorrect answer
3. Con_shortlist
4. Dwrap_tool_call

Why: before_model runs before the model is invoked, which suits final input checks.

Sourced from Docs by LangChain (MCP)

1. Aresponse_format
2. Bwrap_tool_callCorrect answer
3. Cbefore_model
4. Dafter_model

Why: wrap_tool_call wraps tool execution, so it can observe inputs, outputs and timing.

Sourced from Docs by LangChain (MCP)

1. AAsk the model to guess the content
2. BDrop it silently from the batch
3. CScore it normally, which will give a low score
4. DRoute it to OCR or manual review and do not score itCorrect answer

Why: Scoring empty text would unfairly rank the candidate low. The failure must be visible and handled separately.

Sourced from Docs by LangChain (MCP)

1. AIn the agent's checkpointer
2. BIn the LangGraph long-term store
3. CIn encrypted object storage with restricted accessCorrect answer
4. DIn the system prompt for reference

Why: The originals contain raw contact details, so they stay in encrypted storage outside the model path.

Sourced from Docs by LangChain (MCP)

1. APer thread, via a checkpointerCorrect answer
2. BPer model provider
3. CPer Pydantic schema version
4. DGlobally across all users

Why: Short-term memory is thread-scoped and persisted by a checkpointer.

Sourced from Docs by LangChain (MCP)

1. ARemembering candidates could leak one person's data into another's evaluation and bias resultsCorrect answer
2. BStores only work with create_deep_agent
3. CStores disable structured output
4. DStores cannot hold JSON documents

Why: Each resume should be evaluated independently. Durable results belong in the results database keyed by job and resume hash.

Sourced from Docs by LangChain (MCP)

1. Apass, fail, skip
2. Bredact, mask, block
3. Cretry, fallback, limit
4. Dapprove, edit, rejectCorrect answer

Why: HumanInTheLoopMiddleware is configured per tool with interrupt_on and the allowed decisions approve, edit and reject.

Sourced from Docs by LangChain (MCP)

1. ABuilding an evaluation set to measure extraction quality and test changesCorrect answer
2. BReplacing the model entirely
3. CTraining the PII detector on raw contact details
4. DFine-tuning the scoring weights automatically on every override

Why: Overrides are labelled corrections that let the team measure accuracy and validate prompt, schema or model changes.

Sourced from Docs by LangChain (MCP)

1. AThe recruiter, before upload
2. BThe JD lookup tool
3. CThe model, as a free-text field
4. DCode, from the extracted dates, merging overlapping rolesCorrect answer

Why: Date arithmetic is deterministic and testable in code, while models often miscount overlapping or current roles.

Sourced from Docs by LangChain (MCP)

1. AThe tool is read-only, and human review happens downstream on the shortlistCorrect answer
2. BIt cannot be combined with PIIMiddleware
3. CIt would expose PII to recruiters
4. DIt only works in JavaScript

Why: Interrupts are for risky, side-effecting tool calls. The recruiter decision is the meaningful human checkpoint here.

Sourced from Docs by LangChain (MCP)

1. AYes, it replaces PII redaction
2. BYes, every resume must be summarised before extraction
3. CNo, single-resume runs are short, and summarising could drop evidence textCorrect answer
4. DYes, it is needed for structured output to work

Why: Summarisation helps long conversations. Here it would add little and could remove text needed for quoted evidence.

Sourced from Docs by LangChain (MCP)

1. AStore it in a vector store
2. BCall it through init_chat_model
3. CPaste its API docs into the system prompt
4. DAdapt it into LangChain tools with the MCP adapters, such as MultiServerMCPClientCorrect answer

Why: MCP tools are adapted into LangChain tools using the MCP adapters.

Sourced from Docs by LangChain (MCP)

1. Acreate_deep_agent cannot use tools
2. BThe task is short and bounded, and filesystem access and subagents add cost and attack surfaceCorrect answer
3. Ccreate_agent is the only API with middleware
4. Dcreate_deep_agent does not support Python

Why: Deep Agents target long multi-step tasks. A tightly scoped extraction agent is more predictable and easier to audit.

Sourced from Docs by LangChain (MCP)