AI infrastructure for recruiting

Recruiting is a context problem wearing a document problem's clothes. The CVs and scorecards are the obvious part, but the value is in the context that accrues across a hiring process, what came up in screening, what each interviewer thought, what a candidate is looking for, and most of that never makes it into the applicant-tracking system. If you're building hiring tools, the infrastructure you need underneath is extraction for the documents, memory that holds a candidate across stages, and isolation that keeps each role's pool separate.

This page is for teams building recruiting and hiring tools. Exabase gives you CV and scorecard extraction through Extract, candidate memory across stages through Memory, and per-role or per-candidate isolation through Bases. The result is hiring tools whose agents remember every touchpoint the recruiter didn't log, with each role's candidate pool kept its own. For the full build pattern, the HR and recruiting agents use case goes deeper.

What you can build

Recruiting tools tend to be one of a few shapes, each on infrastructure that already exists.

A recruiting copilot that remembers each candidate across screening, interviews, and debriefs, opening every stage already aware of what came before, the HR and recruiting agents pattern: Extract for CVs, Memory across stages, Bases per role.

A CV and scorecard processor that extracts structured data from resumes and feedback in any format, the document extraction at scale pattern applied to hiring documents.

A pipeline search tool that finds candidates matching a requirement across a role's pool by meaning, "candidates who have led a migration", returning real matches even when the CV phrases it differently, Deep Search over a candidate pool.

A candidate-relationship tool that holds context on past candidates for future roles, isolated and searchable, long-term memory plus per-pool Bases.

Recruiting problems, solved

The problems recruiting builders run into are specific, and each has an answer.

Context the recruiter didn't log. The most useful detail is often a remark in a debrief that never got written down. Memory holds what came up across screening, interviews, and feedback, extracted from the interactions rather than depending on someone logging it, so a candidate's full picture is there at every stage. It keeps that picture current through contradiction resolution, so a concern resolved in a later round stops being treated as open.

Structured data from CVs and scorecards. Resumes and feedback arrive in every format. Extract turns them into clean, structured text through one API, including scans, so a stack of differently formatted CVs becomes a usable, searchable pool.

Keeping candidate pools isolated. A company recruits for many roles, and one role's pool generally shouldn't bleed into another's. Bases make isolation structural, per role or per candidate, from a single API call. It's the multi-tenant memory pattern.

Searching the pipeline. Finding the right candidate means searching by what they've done, not the exact words on their CV. Deep Search matches by meaning, so a requirement surfaces matching candidates regardless of phrasing, scoped to the role's pool.

The infrastructure underneath

Three primitives carry most recruiting tools. Extract turns CVs and scorecards into structured data. Memory holds each candidate's context across the hiring process. Bases keep each role's pool isolated from a single API call. Deep Search finds candidates in a pool by meaning. One API key, rather than assembling extraction, memory, and isolation yourself. The HR and recruiting agents use case covers how they fit together in a single build.

Context that compounds across the pipeline

A recruiting tool on this foundation gets more useful as a process runs and as the organisation hires over time. Within a role, every stage adds to what the agent knows about each candidate, and the picture stays current rather than accumulating contradictions because the memory self-organises. Across the organisation, the structured, searchable record of candidates and processes builds up, so past candidates stay findable for future roles and the cost of getting a CV into usable form is paid once. Adding a role is one API call to create its isolated pool, so the per-role separation scales without getting fragile. The institutional memory of who's been considered and why becomes a lasting asset rather than something that resets each time a recruiter moves on.

Get started

Start with the getting started guide, then the use-case pages that match what you're building: HR and recruiting agents for the full pattern, document extraction at scale for CV processing, and multi-tenant memory for SaaS for per-role isolation. There's a free tier to build against.

FAQs

Can it pull structured data from CVs in any format?

Yes. Extract reads CVs and scorecards whatever format they arrive in and returns clean, structured text, so a stack of differently formatted resumes becomes a usable, searchable pool.

Does an agent remember a candidate across interview stages?

Yes. Screening notes, interview feedback, and debriefs go into Memory as the process unfolds, so the agent holds each candidate's full history and opens a debrief already aware of what came before, including context the recruiter didn't formally log.

How are candidate pools for different roles kept separate?

Each role gets its own Base, a structurally isolated environment, so one role's candidates never appear in another's search. It's the multi-tenant SaaS pattern.

Can I search the pipeline for candidates matching a requirement?

Yes. With CVs stored as searchable content, Deep Search finds candidates by meaning, so a query like "candidates who have led a migration" returns matches even when the CV phrases it differently, scoped to the role's pool.

How does it handle something about a candidate changing during the process?

The new state supersedes the old through entity resolution, so a concern resolved in a later round, or a shifted expectation, updates the candidate's picture rather than coexisting with the earlier note.

Is this a finished hiring product or something I build on?

Something you build on. Exabase is the infrastructure, extraction, candidate memory, and isolation, and you build the recruiting copilot or hiring tool on top. The HR and recruiting agents use case shows the full build.