Building an Agentic JD Reviewer: Why We Chose Guided Agentic Over Full Autonomy

Recruiting teams live inside job descriptions.

A weak JD slows sourcing, creates inconsistent screening criteria, confuses candidates, and can expose information that should never leave the organisation.

When we set out to build an AI agent that helps recruiters make a JD hire-ready, the hardest question was not:

“Which model should we use?”

It was:

“How much autonomy should the agent have?”

We knew we wanted something more capable than a chatbot that simply suggests wording. But we also did not want an autonomous system quietly changing hiring requirements or publishing content without human review.

The result is Smith, our guided agentic JD reviewer.

Smith can analyse an entire JD, identify what needs attention, decide what should be addressed next, and guide the recruiter through the remediation process.

But when a decision changes hiring intent, the recruiter stays in control.

This post explains the agentic model we chose, the alternatives we considered, how Smith works, and why guided agentic behaviour was the right level of autonomy for this workflow.

It sits inside a broader OPAL product rule: when to use guided screens versus agents across recruitment workflows. That platform thesis is in Guided screens or AI agents? Knowing when to use each.

The problem in plain language

A client sends an original job description.

Before that JD is reused for hiring, someone needs to make sure it is clear, complete, consistent, and safe.

For example:

Is the role title clear and aligned with what the person will actually do?
Are education, experience, and work eligibility requirements stated clearly?
Are the true must-haves obvious?
Are nice-to-haves clearly separated from mandatory requirements?
Is something written as a responsibility being accidentally treated as a candidate prerequisite?
Does the JD include a client name, email address, phone number, or specific office location?
Is important information still ambiguous?

Recruiters can already paste a JD into a general-purpose LLM and ask:

“Clean this up and make it ready to post.”

That can work surprisingly well.

It can also create a subtle problem.

Consider this sentence:

Obtain and maintain vendor certifications.

That describes something the employee may be expected to do in the role.

It does not necessarily mean:

Candidates must already hold vendor certifications.

A one-shot rewrite can easily make that jump.

And once an AI turns a responsibility into a mandatory candidate requirement, it has changed the Hiring Manager's intent.

That is the type of failure we wanted to prevent.

We wanted AI assistance inside our hiring workflow, but with guardrails designed specifically for recruitment.

The agentic autonomy dial

“Agentic” does not have to mean “fully autonomous”.

We think about agentic behaviour as a spectrum based on how much responsibility the system has for deciding what happens next and what actions it may take.

flowchart LR
  A["<div style='width:10.5rem;height:6.25rem;display:flex;align-items:center;justify-content:center;text-align:center;line-height:1.3'>Assistive AI<br/>suggests;<br/>human drives workflow</div>"] --> B["<div style='width:10.5rem;height:6.25rem;display:flex;align-items:center;justify-content:center;text-align:center;line-height:1.3'>Guided Agentic<br/>analyses broadly;<br/>one decision at a time</div>"]
  B --> C["<div style='width:10.5rem;height:6.25rem;display:flex;align-items:center;justify-content:center;text-align:center;line-height:1.3'>Supervised<br/>Autonomous<br/>agent does most;<br/>human approves</div>"]
  C --> D["<div style='width:10.5rem;height:6.25rem;display:flex;align-items:center;justify-content:center;text-align:center;line-height:1.3'>Fully Autonomous<br/>acts and publishes<br/>without an interrupt</div>"]

  style A fill:#1e293b,stroke:#94a3b8,color:#e2e8f0
  style B fill:#1e3a5f,stroke:#3b82f6,color:#e2e8f0
  style C fill:#1e293b,stroke:#94a3b8,color:#e2e8f0
  style D fill:#1e293b,stroke:#94a3b8,color:#e2e8f0

Level	What the system does	Human role
Assistive AI	Suggests wording or identifies issues	Human drives every action
Guided Agentic	Analyses the JD, prioritises issues, decides what to address next, and guides resolution	Answers business decisions and approves changes
Supervised Autonomous	Completes most remediation independently	Reviews or approves the final result
Fully Autonomous	Determines actions, modifies the JD, and publishes without requiring intervention	Minimal or none

Smith sits firmly in Guided Agentic.

It has agency over the review process.

It does not have unrestricted authority over hiring decisions.

The options we considered

Option 1 — One-shot LLM rewrite

Send the entire JD to a model with an instruction such as:

“Make this JD hire-ready.”

Pros

Very fast to build.
Low interaction cost.
Impressive in a demo.

Cons

Requirements can be invented or strengthened accidentally.
Responsibilities can become candidate prerequisites.
It is difficult to see why something changed.
Sensitive information can survive the rewrite.
Recruiters lose confidence when the system makes unexplained decisions.

The problem is not whether the model can write well.

The problem is whether it should be allowed to make every decision implicitly.

Option 2 — JD scorecard

Analyse the JD and show every issue at once:

Missing education · title unclear · eligibility absent · site address exposed · certification ambiguous · spelling issues · …

Pros

Transparent.
Familiar health-check experience.
Easy to implement.

Cons

Creates cognitive overload.
Does not help the recruiter decide what to fix first.
Issues remain unresolved unless someone manually works through the list.
Recruiters can easily edit one area while introducing inconsistency somewhere else.

Finding ten problems is not the same as safely resolving ten problems.

Option 3 — Fully autonomous agent

Allow the agent to:

detect → decide → rewrite → save

with no human gate.

Pros

Minimum recruiter interaction.
Fastest path from original JD to final output.

Cons

The system can make hiring decisions that were never explicitly provided.
Mandatory requirements may be inferred.
Preferred criteria may become required criteria.
Client-sensitive text can be altered or retained incorrectly.
The recruiter may never see which assumptions the agent made.

For hire-critical content, autonomy without appropriate boundaries creates unnecessary product risk.

Option 4 — Guided Agentic remediation

This is the approach we shipped.

Smith behaves agentically when analysing and navigating the JD, but it brings the recruiter into the loop whenever business intent needs to be confirmed.

The process is:

Analyse the entire JD.
Detect issues and gaps internally.
Prioritise what needs attention.
Present one type of decision at a time.
Prefer structured choices over open-ended questions.
Normalise recruiter-entered text where appropriate.
Confirm changes that affect meaningful wording.
Continue autonomously to the next unresolved issue.
Perform a final structural and language polish.
Present the completed JD for approval.

This creates a useful division of responsibility:

The agent decides what needs attention next.

The recruiter decides what the business requirement actually is.

That is the core of Smith's agentic model.

How Smith works

High-level flow

flowchart TB
  Start[Recruiter opens Ask Smith] --> Analyse[Analyse JD<br/>title · requirements · gaps · confidentiality]
  Analyse --> Queue[Build prioritised remediation queue<br/>skip categories with no issues]
  Queue --> Present[Select next issue<br/>show one decision only]
  Present --> Answer[Recruiter answers]
  Answer --> Free{Free text?}
  Free -->|yes| Norm[Normalise grammar / spelling]
  Norm --> Confirm{Meaningful wording changed?}
  Confirm -->|yes| ConfirmUI[Confirm polished wording<br/>Use this / Rephrase]
  ConfirmUI -->|Use this| Merge[Merge approved decision into working JD]
  Confirm -->|no| Merge
  Free -->|structured choice| Merge
  Merge --> More{Unresolved issues?}
  More -->|yes| Decide[Agent selects next issue]
  Decide --> Present
  More -->|no| Polish[Final structural polish]
  Polish --> Validate[Validate requirements and confidentiality]
  Validate --> Review[Completion summary + editable JD]
  Review --> Approve{Approve?}
  Approve -->|yes| Save[Save sanitised JD]
  Approve -->|no| End[Continue editing / cancel]
  Save --> End

The important part is the loop.

Smith does not blindly follow a long checklist presented to the recruiter.

It maintains an internal understanding of the JD, resolves one issue, updates its state, and determines what should happen next.

That is where the workflow becomes genuinely agentic.

Analyse broadly. Remediate narrowly.

This became one of the most important principles in the design.

Smith might identify ten issues during its initial analysis.

The recruiter should not have to deal with ten issues at once.

Internally, Smith may know:

Role title           → needs confirmation
Eligibility          → clear
Mandatory criteria   → certification ambiguous
Nice-to-have         → clear
Experience           → missing
Confidentiality      → client name detected
Location             → acceptable
Language             → three corrections

But the recruiter sees only the issue Smith has selected for resolution.

flowchart LR
  subgraph Internal["Agent State"]
    R[Full JD analysis<br/>title · eligibility · mandatory · preferred · gaps · confidentiality]
    Q[Prioritised unresolved issues]
    S[Current state]
  end

  subgraph UserSees["Recruiter Experience"]
    C[Current issue]
    I[One decision<br/>A / B / C]
    D[Working JD for context]
  end

  R --> Q
  Q --> S
  S --> C
  C --> I
  D --- I

The agent can think broadly.

The interaction stays narrow.

One decision at a time

Suppose Smith sees:

Obtain and maintain vendor certifications to validate expertise.

The system identifies an ambiguity.

Does this mean the candidate must already have the certification?

Or can they obtain it after joining?

Smith should not decide.

Instead, it asks:

When should the vendor certification be required?

A. Candidates must already hold it B. It can be obtained after joining C. It is preferred but not mandatory D. Keep it as a job responsibility only

Once the recruiter answers, Smith records that decision and moves to the next unresolved issue.

That behaviour is agentic without becoming reckless.

Role titles: research, recommend, confirm

Role titles are another area where we deliberately give Smith agency without giving it final authority.

A title such as:

Presales Professional

may describe the function, but it may not be the clearest market-facing job title.

Smith can:

analyse the responsibilities,
compare the title with common market terminology,
correct spelling or style,
recommend a stronger title,
present alternative titles.

For example:

Current: Presales Professional Recommended: Pre-Sales Engineer – Application & Data Security

But Smith does not silently replace the title.

The recruiter confirms the final choice.

Autonomy stops at the recommendation because title choice affects sourcing, candidate expectations, internal levelling, and sometimes compensation benchmarking.

Requirements are not all the same

One of the most important things Smith does is keep several concepts separate:

Responsibility
≠
Eligibility
≠
Mandatory requirement
≠
Nice-to-have
≠
Ambiguous requirement

That sounds obvious.

In real JDs, those categories are often mixed together.

For example:

Conduct customer demonstrations.

That is a responsibility.

It does not automatically mean:

Candidates must have five years of customer demonstration experience.

Likewise:

Obtain vendor certifications.

does not automatically mean:

Vendor certification is mandatory before joining.

Smith is allowed to identify the ambiguity.

It is not allowed to invent the answer.

Remediation priority

Not every issue deserves equal urgency.

Smith prioritises issues based on risk and their impact on recruitment.

A typical sequence looks like:

flowchart TD
  P1[1. Confidentiality / personal information] --> P2[2. Role title]
  P2 --> P3[3. Eligibility]
  P3 --> P4[4. Mandatory / must-have]
  P4 --> P5[5. Nice-to-have / preferred]
  P5 --> P6[6. Ambiguous requirements]
  P6 --> P7[7. Missing recruitment information]
  P7 --> P8[8. Location disclosure]
  P8 --> P9[9. Language / formatting]

This is a priority model, not necessarily a rigid script.

Empty categories are skipped.

If the agent discovers a higher-risk issue while progressing through the JD, it can prioritise that issue next.

That is another important difference between a checklist and an agentic workflow.

Free text still needs a human gate

Structured choices work well for many decisions.

But recruiters sometimes need to provide information directly.

Someone might type:

bachelros of computer science or equivelent

Smith should not simply paste that into the JD.

It can normalise the answer to:

Bachelor's degree in Computer Science or equivalent.

But if the agent meaningfully rewrites recruiter-provided content, the recruiter should see what is being inserted.

The interaction becomes:

You entered: bachelros of computer science or equivelent

Smith will write: Bachelor's degree in Computer Science or equivalent.

Use this / Rephrase

The model handles the language.

The recruiter retains ownership of the requirement.

Safe autonomy versus business autonomy

We found it useful to distinguish between two types of actions.

Smith can act automatically on low-risk corrections

For example:

spelling,
punctuation,
spacing,
British English consistency,
bullet formatting,
heading consistency,
obvious typographical errors,
approved confidentiality replacements.

Smith asks before changing business meaning

For example:

making a skill mandatory,
changing something from preferred to required,
adding minimum experience,
adding a certification requirement,
changing seniority,
changing the role title,
adding responsibilities,
adding technologies,
changing eligibility requirements.

This boundary lets Smith behave agentically without becoming the source of truth for Hiring Manager intent.

Where we draw the line on autonomy

Smith can do	Smith cannot do without approval
Analyse the entire JD	Invent duties
Decide what issue should be addressed next	Invent skills
Prioritise confidentiality and requirement problems	Add technologies
Research and recommend a role title	Change the role title
Detect ambiguous requirements	Decide what the Hiring Manager meant
Propose polished wording	Turn responsibilities into must-haves
Apply safe mechanical corrections	Introduce new eligibility requirements
Build and manage the remediation queue	Publish changes without final review

This is why we describe Smith as guided agentic, rather than fully autonomous.

It has meaningful agency.

It operates within deliberate boundaries.

Agentic does not require an agent framework

One implementation lesson surprised us.

The product behaviour matters more than whether every interaction runs through an “agent framework”.

Smith's remediation logic can support more than one execution surface:

flowchart TB
  Core[Shared Agentic Core<br/>analyse · prioritise · present · resolve · merge · validate]

  Core --> UI[Product UI<br/>request / response interactions]
  Core --> Graph[Workflow graph<br/>persistent state · pause / resume · experiments]

For the recruiter-facing product, the UI path fits naturally into the application's existing interaction model.

A workflow graph is useful when we want persistent execution, explicit state transitions, experimentation, or more autonomous loops.

But the product does not become agentic simply because LangGraph, or any other agent framework, is present.

The agentic behaviour comes from the system's ability to:

understand state,
identify unresolved goals,
choose the next useful action,
use tools when appropriate,
ask for human input when necessary,
continue from that decision,
know when the task is complete.

Agent frameworks are implementation choices. Agentic behaviour is a product design choice.

Why we did not choose full autonomy

Could Smith eventually take a JD, fix everything, and publish the result without recruiter involvement?

Technically, yes.

That is not the interesting question.

The interesting question is whether doing so produces a better hiring outcome.

Full autonomy becomes attractive when we can demonstrate, across real JDs, that the agent consistently performs well on:

Confidentiality — sensitive information is reliably removed.
Completeness — meaningful recruitment information is identified.
Requirement accuracy — mandatory and preferred criteria remain correctly separated.
Faithfulness — Hiring Manager intent is preserved.
Title quality — recommendations accurately reflect the role.
Recruiter acceptance — suggested decisions are consistently accepted.
Hallucination rate — requirements are not invented.

Until then, increasing autonomy simply because the technology allows it would optimise for fewer clicks rather than better hiring decisions.

The product lesson

Our initial question was:

How autonomous should the agent be?

The more useful question became:

Which decisions should the agent be trusted to make, and which decisions still belong to the recruiter?

That distinction shaped the whole product.

Smith can autonomously decide:

“This certification requirement is the most important unresolved issue.”

It cannot autonomously decide:

“Certification should be mandatory.”

Smith can decide:

“The current role title may not match the responsibilities, so I should investigate it.”

It cannot decide:

“I will change the published title.”

That separation gives us meaningful agentic behaviour without handing business policy to the model.

Takeaways

Agentic does not mean fully autonomous. A system can choose actions dynamically while still operating inside deliberate human gates.
Analyse broadly; remediate narrowly. Detecting fifteen issues does not mean showing fifteen issues.
Separate responsibilities from candidate requirements. AI should never silently turn “what the employee will do” into “what the candidate must already have”.
Prefer decisions over essays. Structured choices reduce ambiguity and make recruiter intent easier to preserve.
Use autonomy where confidence is high. Grammar and formatting can be highly automated. Hiring requirements deserve stronger controls.
Let the agent own orchestration, not business intent. Smith decides what needs attention next; the recruiter decides what the requirement should be.
Frameworks follow the product shape. LangGraph or another workflow framework can support the implementation, but using one is not what makes the experience agentic.
Keep a final human gate for hire-critical content. Agentic assistance should increase recruiter confidence, not remove recruiter ownership.

Smith is our guided agentic JD reviewer: part analyst, part orchestrator, part careful interviewer — but never the unsupervised owner of a hiring decision.