Recruitment: Three Loops, One Pool
Our recruitment process is not a pipeline, because almost no real process is. Three loops run continuously: demand (roles open, pause, reopen, close), sourcing (always on, across every channel), and selection (screen, interview as many rounds as it takes, offer). All of them orbit one candidate pool that never forgets. Candidates move backward as often as forward, and every exit from any loop is an entry into the pool.
Hiring is drawn as a line and lived as a loop
Most hiring processes fail in the gap between the tidy diagram and the messy reality:
Three loops orbiting one pool
Each loop runs on its own clock. None of them waits for the others, and all of them read from and write to the same candidate pool.
Roles churn, the system keeps up
A recruiter creates the requisition from the Job Reqs list: title, employment type, location, remote policy, salary band. The system seeds the same five-stage board every role uses (Screen, Interview, Offer, Hired, Rejected), so no two roles ever run subtly different processes. The req opens for hiring immediately but stays off the public site until the posting is ready.
The public posting is written in markdown on the req itself: the JD, a clean URL, and up to three screening questions. Flipping it public puts it on the careers page. Some roles never publish at all and are filled entirely from sourcing and the pool. The posting is one door among several, not the process.
Budgets move, priorities shift, and the role you started hiring for is not always the role you finish hiring for. A req can go on hold and come back; its JD, salary band, and screening questions can be edited mid-search. Candidates in flight keep their history through every change. Nothing resets because the role evolved.
Every close records an outcome (filled, closed without hire, or cancelled) and takes the role off the careers page automatically. The candidates in flight do not vanish: they exit into the pool with their screens, ratings, and notes attached, and the strong ones surface first when a similar req opens. Reopening a req picks up exactly where it left off.
Always on, across every channel
A candidate applies with a resume, cover letter, and answers to the role’s screening questions. The application lands in the talent system attached to the req. No inbox, no forwarding, no resume that only exists in one person’s email.
LinkedIn sourcing, team referrals, event contacts, and agency submissions all run in parallel with inbound. Sourcing is a standing activity, not a burst that starts when a req opens. Every channel is tagged at intake (sourced, referral, agency, LinkedIn, job board, event), so the system can later answer which channels actually produce hires.
Agency candidates enter through the same doors and get the same treatment as everyone else: the same AI screen, the same two gates, the same record. No parallel spreadsheet process for agency submissions. One system of record regardless of who found the person.
Sourced resumes arrive in bulk: a recruiter drops up to 25 files at once and AI reads each one, prefilling a draft with name, email, phone, LinkedIn, headline, and current title. The recruiter reviews and saves each draft. Ten minutes of drag-and-drop replaces an afternoon of data entry, and duplicates are impossible by construction: candidates are keyed by email, one application per person per role, and re-adding someone surfaces their existing record instead of creating a second.
When a req opens, sourcing starts from everyone the company has already met. The pool is ranked by best AI screen and grouped by role family, so last quarter’s strong runner-up surfaces at the top of this quarter’s search with full history attached. The cheapest candidate to find is the one you already found.
The real flowchart, every branch included
One candidate’s path through selection. Solid lines are the working process; dashed lines are the pool’s memory. Every “no” has a destination, and none of them is a shredder.
The moment an application lands, from any door, Claude reads the full resume against the JD and writes a structured screen: a 0–5 fit rating, an overview, concrete strengths and gaps, an English-proficiency read, and the salary expectation and notice period exactly as stated, never guessed. Every application gets the same depth of read whether it arrived first or five hundredth.
Scored candidates also stack-rank within their role family, not just the single job they applied to. A strong engineer who applied to the wrong opening still surfaces near the top of the engineering family.
Every application carries the AI’s score with its written reasoning and the recruiter’s own star rating, side by side. Weak on both gates: rejected, with the reason recorded, into the pool. Strong on both: on to the screening call. Gates disagree: a second human look decides, because disagreement is signal, not noise. Nobody is rejected by AI alone.
Before any formal interview, a recruiter talks to the candidate: motivation, expectations, notice period, the things a resume can’t say. Right role at the right time: on to interviews. Wrong role or wrong timing: parked as future consideration, or recorded as withdrew if the candidate steps back. Either way the call notes go on the record, and the pool keeps them.
Interviews are not a fixed count. A senior role may take three rounds and a follow-up with a different interviewer; a junior role may take one. Panel says yes: offer. Panel says no: rejected, with the reason recorded. Panel is split: another round, and that backward move is recorded like any other. No side-channel “can you talk to her once more” that the system never sees.
All working context lives on the application: the notes thread, the resume (replaceable when a better version arrives), the cover letter and answers, both ratings, and the stage history. Anyone on the team can open it and know exactly where things stand.
Offers get negotiated, and terms move both ways before they settle. Accepted: the application flips to hired and hands off to the New Member Onboarding workflow, which turns the applicant record into an employee record without re-typing anything. Declined: the search goes back to the warm shortlist, which is still ranked and still in the system, not back to square one.
Either way, the loop closes with an explicit status and a recorded reason. Nobody is left in limbo, and no outcome is silent.
Every exit is a pool entry
“Rejected” is a status, not a deletion. Every way out of the three loops lands in the pool with full history:
The ways out
- Rejected, always with a recorded reason
- Withdrew: candidates change their minds; the door stays open
- Future consideration: right person, wrong timing, parked deliberately
- On hold / passive: in flight but paused, usually with the req
- Hired: off to onboarding, still on the record
What the pool does with them
- Ranks everyone by their best AI screen, across every application
- Groups by role family so the next search starts pre-sorted
- Keeps every screen, rating, and note attached to the person
- Feeds the sourcing loop: resurfaced candidates skip the cold start
- Honors a do-not-hire flag where the decision is final
The seven elements
Every workflow we document has the same anatomy: seven elements, each assigned to a human, a machine, or both. This is the Centaur Map from our workflow design method.
No single trigger. A role opening, a strong inbound resume, a referral, or a pool resurfacing can each start motion, and usually several are running at once.
The JD and screening questions, resumes from every channel (careers page, LinkedIn, referrals, agencies, batch drops), and the full history of everyone the company has already met.
Two independent gates per candidate: the AI screen with written reasoning and the recruiter’s rating. Plus explicit human decisions at every exit and every backward move.
Not forward-only. Candidates move back a stage for another round, return to the shortlist after a declined offer, or exit to the pool and re-enter months later on a different req.
A living record per candidate: every application, every screen, both ratings, the notes thread, and every status change with its reason.
Ranked, sortable views wherever the work happens: per req, per role family, and across the whole pool.
Conversion inside each loop, AI-vs-recruiter disagreement, time from open req to hire, and how often the pool, not a job board, fills the role.
The standing rules
- Every role runs the identical five-stage board. The loops vary; the record doesn’t
- Every door produces the same structured record, agency or inbound alike
- Every resume is read in full by AI on arrival
- Backward is a normal direction, and every move is on the record
- No candidate is rejected by AI alone, and every exit has a recorded reason
- Closing a req never discards its candidates; nothing is ever deleted
Why it works
- The documented process matches the lived one, so people actually keep the system true
- One system of record ends the where-does-this-candidate-stand question
- Always-on sourcing means a new req starts warm, not cold
- Two independent gates catch what either one alone would miss
- The pool compounds: every search makes the next one faster
- Declined offers and paused reqs cost days, not restarts