Candidate screening, from hours to minutes

The problem

The recruitment team held around a thousand CVs and a set of open role descriptions. Bringing the two together meant manual reading and filtering in Excel: hours per role.

The real cost wasn't the hours. It was that good candidates already in the database went unseen, because nobody had time to reach them. A CV from eight months ago may as well not have existed.

What I built

A retrieval agent that indexes the CV corpus alongside the client's own role definitions and cross-matches candidates against a specific open position on request. The recruiter holds a conversation with it rather than reading a ranked list.

Architecture

The security requirement determined the topology, not the other way around. The application runs in a private subnet, reachable only across the client's own VPN. Serverless components were kept wherever the security boundary allowed, reached through VPC endpoints rather than the public internet.

Client network

1

Recruiterinside the client's own network

the only route in

2

Client VPNno public endpoint exists to find

VPC · private subnet

3

Application & agentsinference runs beside the data, not across the internet

private routing

4

VPC endpointsgateway and interface, so serverless stays serverless

retrieval

5

Knowledge Base1,000 CVs indexed with the client's role definitions

1. A recruiter works from inside the client's own network.
2. Access is over the client's VPN and nothing else. There is no public endpoint to discover, so candidate data never crosses a public path.
3. The application and the agents both sit in the private subnet, which keeps inference next to the data rather than sending it out and back.
4. The components that could stay serverless did. They are reached over gateway and interface endpoints instead of the internet, so the security boundary costs nothing in architecture.
5. CVs and the client's own role definitions are indexed together, which is what lets the agent explain why a candidate matched a specific role.

Decisions that mattered

Security drove the topology

My default is serverless. Here the client needed candidate data never to traverse a public path, which meant a private subnet behind their VPN. Rather than abandon serverless entirely, the components that could stay serverless did, reached over gateway and interface endpoints. The agents themselves were deployed inside the VPC so data and inference stay close together, minimising both latency and transfer.

Sized for ten users, not ten thousand

Two or three administrators and three or four recruiters. Building for imaginary scale would have billed the client for capacity nobody was ever going to use. Right-sizing to real demand is a decision, not a shortcut.

A ranked list nobody trusts is a tool nobody opens

The agent explains why it surfaced each candidate, cites the CVs behind every answer, and will compare candidates directly when that makes the difference clearer. The recruiter can push back and ask again. Trust is the feature that decides whether the tool is still being used in six months.

The client defines what "a good candidate" means

Role specifications are entered by the client, not hard-coded by me. They describe the capabilities a role actually requires, and the agent matches against that. Combined with client-managed CV ingestion, the whole system stays theirs.

Outcome

A recruiter goes from a thousand unread CVs to a contactable shortlist in a few minutes of conversation.

The system has been in daily use since February 2026. The same client subsequently asked for the sister system, the accounting assistant delivered in the same engagement, to be extended to another company in their group.