Case Study
Agentic Job Search Copilot
Designing an evidence-based agentic workflow for discovering, evaluating and organising relevant product opportunities.
- AI-Native Product
- Personal Build
- Product Strategy
- Workflow Automation
- Human-in-the-Loop
- Go-live build in progress
Overview
Executive summary
The copilot turns repetitive job discovery into a structured, repeatable product workflow. Instead of running the same searches every day and manually judging relevance, the user configures their profile and criteria once, and the agent handles discovery, enrichment and assessment — while every consequential decision stays with the user.
The workflow is composed of discrete stages that can each be validated independently, which is what makes the output trustworthy: a match explanation is only as good as the evidence the evaluation stage actually matched.
- Profile and criteria configuration
- Scheduled discovery
- URL resolution and enrichment
- Normalisation and deduplication
- Structured JD extraction
- Evidence-based evaluation
- P1, P2 and P3 classification
- Human review and action
The problem
Product problem
Senior candidates spend significant time repeatedly searching job portals, validating relevance, resolving external application links and manually comparing opportunities against their experience and preferences.
The work is high-volume and low-judgment at the front end, and high-judgment and low-volume at the back end. Most tooling automates the wrong half — it either floods the user with keyword matches that ignore hard constraints, or it promises end-to-end automation that removes the user from decisions they should own.
Who it's for
Target user and jobs to be done
Primary user
Senior product professionals searching across remote and international opportunities while applying strict requirements around role relevance, location, remote eligibility and sponsorship.
Jobs to be done
- Find relevant opportunities without repeating the same searches every day.
- Understand why a role matches before spending time applying.
- Separate strong matches, transferable opportunities and hiring posts.
- Preserve human control over application decisions.
- Avoid duplicates, broken links and unsupported match explanations.
Ownership
My role and ownership
I own this end to end as the product decision-maker: product vision, requirements, workflow design, prioritisation, evaluation logic, acceptance criteria, testing and staged delivery. It is built hands-on with Claude Code — the implementation is AI-assisted, but the product judgment, scope calls, quality bar and every go/no-go decision are mine.
- Product vision and problem framing
- Requirements and acceptance criteria
- Workflow and stage design
- Evaluation and classification logic
- Safety and human-review boundaries
- Test design and release sequencing
Boundaries
Product scope
In scope
- Configurable profile, criteria and hard-constraint definitions
- Scheduled discovery across configured sources
- External application-URL resolution and enrichment
- Normalisation and duplicate suppression
- Structured extraction of job-description content
- Evidence-based evaluation with traceable explanations
- Three-tier opportunity classification
- A review surface for human decisions and actions
Explicitly out of scope
- Automatic application submission
- Automated messaging or outreach to recruiters
- Storing or transmitting credentials in the public showcase
- Any claim of relevance the evaluation stage cannot evidence
How it works
End-to-end workflow
Eight stages, each independently validatable. The separation matters: a match explanation is only trustworthy if the stage that produced the evidence can be checked on its own.
Profile and Criteria
Experience, preferences and hard constraints defined once as structured input.
Scheduled Discovery
Runs on a schedule across configured sources rather than on manual searches.
URL Resolution and Enrichment
Resolves the real application destination and adds missing opportunity context.
Normalisation and Deduplication
Standardises fields and suppresses repeats without collapsing distinct roles.
JD Structuring
Converts free-text job descriptions into consistent, comparable fields.
Evidence-Based Evaluation
Scores against relevant factors, recording the evidence behind every match.
P1 / P2 / P3 Classification
Sorts opportunities into strong, transferable and hiring-post tiers.
Human Review
The user reads the evidence, decides, and takes every application action.
Profile and Criteria
Experience, preferences and hard constraints defined once as structured input.
Scheduled Discovery
Runs on a schedule across configured sources rather than on manual searches.
URL Resolution and Enrichment
Resolves the real application destination and adds missing opportunity context.
Normalisation and Deduplication
Standardises fields and suppresses repeats without collapsing distinct roles.
JD Structuring
Converts free-text job descriptions into consistent, comparable fields.
Evidence-Based Evaluation
Scores against relevant factors, recording the evidence behind every match.
P1 / P2 / P3 Classification
Sorts opportunities into strong, transferable and hiring-post tiers.
Human Review
The user reads the evidence, decides, and takes every application action.
Judgment
Key product decisions
Do not automate job applications.
Why: Application submission is consequential and requires user judgment.
Do not treat the same domain as the same job.
Why: Different job URLs on the same company or ATS domain may represent different opportunities.
Route uncertain results to manual review.
Why: Preserving uncertainty is safer than silently overwriting or accepting weak resolution evidence.
Generate explanations from matched evidence.
Why: The explanation must accurately represent what the scoring engine actually matched.
Keep non-applicable factors outside the score denominator.
Why: A candidate should not be penalised for a factor that does not apply to the opportunity.
Evaluation
Evaluation and classification model
Evaluation is a product decision, not just a scoring formula. Each opportunity is assessed against the factors that actually apply to it — relevance to the target role, the capabilities the job description asks for, the hard constraints the user has declared, and the areas where experience is transferable rather than direct.
Four things are recorded alongside every assessment: the factors considered, the evidence matched for each, any exclusions that ruled the opportunity out, and the gaps between what the role asks for and what the profile evidences. That record is what the user-facing explanation is generated from, so an explanation can never assert a match the engine did not make.
What the model considers
- Relevant factors
- Only factors applicable to this opportunity are scored.
- Matched evidence
- Every contributing factor carries the evidence behind it.
- Exclusions
- Hard constraints that disqualify an opportunity outright.
- Transferable capabilities
- Adjacent experience recognised without being counted as a direct match.
- Identified gaps
- What the role asks for that the profile does not evidence.
Classification tiers
- P1
Strong or close-domain match
Direct relevance to the target role and domain.
- P2
Transferable skills match
Strong capability overlap across a different domain.
- P3
Hiring or opportunity post
A relevant LinkedIn hiring or opportunity post rather than a formal listing.
Safety
Human-in-the-loop and safety controls
Autonomy is bounded by design. Each control below exists because an unbounded agent fails in a way that costs the user something they cannot undo.
No automatic applications
The agent never submits an application. Every submission is a human action.
Manual review for conflicting URLs
Conflicting or ambiguous resolution results go to a human instead of being guessed.
Retry controls and bounded attempts
Failures retry within explicit limits rather than looping indefinitely.
Idempotency protection
Re-running a stage does not duplicate or corrupt previously processed opportunities.
Evidence-grounded explanations
Explanations are derived from matched evidence, never reconstructed after the fact.
Private credentials kept outside the public showcase
Secrets, endpoints and infrastructure identifiers stay out of anything published.
Evidence
Artifacts and product evidence
Sanitised product artifacts are being prepared and will be published here as they are cleared. Nothing below is a mock-up — an artifact appears only once the real asset exists.
What will be published here
- Product requirements and scope
- Agent workflow
- Evaluation framework
- Classification model
- Human-review decision flow
- Preview dashboard
- Test and acceptance criteria
Each artifact is being reviewed so nothing employer-confidential or infrastructure-identifying is published. Until then, the sanitised product documentation lives in the public showcase repository.
View GitHub Showcase(opens in a new tab)Verification
Testing and verification approach
Verification is organised by category rather than by count — the categories are what tell you whether the product behaves correctly under pressure.
Functional paths
Each workflow stage produces the expected output from valid input.
Boundary and exclusion cases
Hard constraints exclude correctly, including at the edges of each rule.
Retry behaviour
Failures retry within bounds and surface cleanly when exhausted.
Idempotency
Repeat runs converge to the same state without duplication.
Scoring arithmetic
Applicable factors, weights and denominators compute correctly.
Evidence integrity
Every explanation traces back to evidence the engine matched.
Failure handling
Unsafe or low-confidence outcomes route to review, not to acceptance.
Preview validation before production
Behaviour is confirmed in Preview before rollout.
Status
Current build status
- Core workflow stages are being implemented and validated in Preview.
- Production rollout remains controlled.
- Public portfolio content is sanitised — no credentials, private endpoints or infrastructure identifiers.
- The system does not submit job applications.
Reflection
Lessons learned
Agent autonomy requires explicit boundaries.
Evaluation quality depends more on evidence integrity than score complexity.
Operational failure paths must be designed as product behaviour, not treated as engineering afterthoughts.
Next steps
- Complete remaining go-live validation
- Add sanitised product artifacts
- Refine user-facing opportunity explanations
- Validate the end-to-end scheduled workflow
A public showcase of the product thinking behind this build
The showcase repository holds sanitised product documentation. The production system, its credentials and its infrastructure stay private.