03 — SCAN AGENT

The Problem

After posting a role, recruiters face hundreds of applications. Reviewing every CV manually is slow, repetitive, and inconsistent, and the problem compounds at scale.

The bottleneck isn't effort. It's structure. Without a consistent framework, every recruiter applies different criteria, at different thresholds, on different days. The output is unreliable by design.

The real challenge wasn't automating the screening. It was doing it in a way recruiters would actually trust, and use.

The Solution

We implement a new tool : Scan Agent
SCAN analyzes applications against recruiter defined criteria and returns a prioritized candidate list. Recruiters configure must-have and nice-to-have requirements. SCAN suggests criteria extracted from the job description, recruiters stay in full control of what gets applied.

For roles requiring oral skills, the Voice Agent evaluates candidates through a structured conversation, assessing language proficiency and response quality where a CV simply can't.

The two tools cover different parts of the screening problem. Together, they form a system, not a feature set.

My Thinking

On trust as a design constraint, Speed without trust is useless. If a recruiter doesn't understand why a candidate ranked first, they'll ignore the ranking entirely, and default back to manual review. Every indicator was designed to answer "why is this candidate here?" before the recruiter thought to ask. Explainability wasn't a nice-to-have. It was the condition for adoption.

On where the AI stops : SCAN suggests criteria. It does not set them. That's a deliberate boundary, not a technical limitation. Recruiters hold institutional knowledge no job description captures — team dynamics, implicit role requirements, past hiring mistakes. An AI that silently decides removes that knowledge from the process. We designed SCAN to augment recruiter judgment, not replace it.

On a client request that shaped the roadmap : A client wanted to use SCAN for English proficiency screening. SCAN isn't built for oral evaluation, applying it there would have produced unreliable results and eroded trust in the tool. Rather than forcing a workaround, we designed a redirect flow toward the Voice Agent, and used that friction as the foundation for a hybrid agent combining both capabilities. That client feedback directly influenced the roadmap. The constraint became the feature.

On disabled states : The PM pushed for clickable disabled states. I held the position: clicking a disabled element is a UX anti-pattern. It creates false affordance and generates downstream confusion. I backed it with usage data showing interaction drop-off at those exact points. We kept the original behavior.

The thread across these decisions: every time we hit a pressure point, from a stakeholder, a client, or a PM, the question was the same: does this serve the recruiter's decision, or does it just serve the request? That distinction drove every call we made.

Accessibility

Every compatibility indicator is readable without visual context. Keyboard navigation is consistent throughout the flow. Color coding is always paired with a text label, never used as the sole signal. Recruiters screening hundreds of applications need a product that doesn't add cognitive load. Accessibility and usability were the same constraint.

Key Learning

The question isn't "how should the AI work?" It's "should there be AI here at all?"

And when AI is the right answer: where does it stop, and where does the human take over? On this project, that boundary wasn't a technical decision. It was the central design decision.