How I built an Autonomous Agent System for Hiring

I connected my Claude Code with Alchemist, and then I built this autonomous agent system end to end for hiring candidates for my company.

I built the system on Olbrain Agent OS. It handles a process that stretches across email, CVs, interviews, calendars and candidate conversations. The challenge was deciding where one agent’s responsibility should end and another’s should begin.

A candidate needs a consistent answer wherever they ask. The interviewer needs evidence about that person and the job. The hiring team needs an assessment it can inspect, and control over consequential decisions. I approached those as separate responsibilities connected through tools and a shared application record.

What autonomy means in this hiring system

I designed agents to carry work across intake, interview preparation, candidate conversations and assessment, with explicit handoffs and scoped tools. The system can move work forward within those boundaries. Human reviewers keep control of consequential decisions: people conduct later rounds and make every offer and hire.

Define the evaluation criteria before the score

A crucial part of this system is deciding what a good candidate means for the company and the role. For my company, the evaluation framework was MAD: Mastery, Ambition and Dominance.

• Mastery: depth of understanding and evidence of actually having built the work the candidate describes.
• Ambition: the reach toward something that does not yet exist, and the drive to turn understanding into something useful.
• Dominance: command over complexity, not power over other people.

I connect the evaluation to evidence. The job rubric establishes the requirements, the CV assessment extracts relevant evidence, and the interview plan identifies what needs probing. The interviewer gathers specifics. A separate scorer reviews the completed interview and returns scores, quoted evidence, confidence and a recommendation. The hiring team can inspect the reasons behind the assessment instead of receiving an unexplained number.

MAD is company-specific, not a universal hiring standard. Another company may prioritize different criteria for its roles. The rubric, interview questions and scoring guidance should reflect those criteria; copying the agents should not mean copying my company’s definition of a good candidate. I keep the evaluation criteria explicit so the handoffs can carry the right evidence into the assessment.

A score supports review and routing within the configured rules. It does not give an agent authority to make an offer or hire someone. Human reviewers handle AI shortlists and low-confidence cases, and people retain the final hiring decisions.

Three conversational agents, seventeen workflow targets

In the source configuration, I have 20 distinct Studio integration targets: 3 conversational agents and 17 workflow agents. This is the configured inventory, not a count of agents currently enabled in production. A configured ID does not establish whether that component is off, running in shadow or handling live work.

The three conversational targets are the candidate assistant, recruiter assistant and interviewer. They take turns with a person, preserve conversation context and use scoped tools. The workflow targets take a defined input, perform a bounded task and return a result for another step to consume.

Five people-facing roles, with different boundaries

I separate the product into five people-facing roles. These roles do not map one-to-one to the three conversational targets: the mail desk uses workflow components, and selected recruiter and operations conversations share the Studio recruiter agent. Local agent implementations remain available as fallbacks. The candidate-facing identity is Cognia.

I separated candidate-facing work from internal work because they need different information and authority. The system supplies the candidate identity to tools; the model does not choose whose application it may read. Internal team context reaches a candidate-facing agent only when explicitly marked as eligible for a reply.

The seventeen workflow agents, grouped by their handoffs

I group the configured workflow targets by the record each produces and the next component that needs it. A workflow agent can use AI inside its steps; it is different from a scheduled job that merely decides when to run work.

• Application intake — 5. CV OCR reads scanned documents; CV parsing structures the text; CV assessment extracts evidence against job criteria. Job intent interprets the application intent, and job matching suggests a suitable open role. The candidate confirms the suggested role before applying.
• Job and interview preparation — 3. JD extraction produces the job rubric. Job test items establish what the interview needs to test. Interview planning combines the job requirements and candidate evidence into a plan for the conversational interviewer.
• Assessment — 4. Interview scoring returns scores, quoted evidence, confidence and a recommendation. Character assessment surfaces values-related evidence. Job-specific fit and legacy fit are separate configured targets for their respective assessment paths; I do not count them as one just because both concern fit.
• Communication — 4. Email triage classifies inbound mail; email instructions prepares guidance for the reply; outbound produces stage messages. WhatsApp condensation adapts content for that channel. These bounded tasks support the mail desk and candidate experience rather than adding four more conversational agents.
• Offer processing — 1. Offer parsing extracts role, pay, start date and location from an uploaded letter. It does not authorize or make an offer.

I use larger Claude models for interviewing and scoring, and smaller models for quick reads and summaries. Model choice follows the task. Every AI call records token use and cost so I can inspect the expense of a candidate, interview or agent.

Connect the agents with explicit workflow steps

An emailed CV goes through intake, reading and job matching. Once the application and job are established, the job rubric and CV evidence feed an interview plan. The interviewer gathers further evidence; the scorer then produces the assessment consumed by first-round routing and human review.

Alongside those agents, scheduled jobs handle routing of scored interviews, reminders, failed-send retries and team digests. Their scheduling and routing logic is orchestration around the agents, not extra Studio agents in the count. A retry can invoke AI-backed work again, so I keep the job that triggers work separate from the agent that performs it.

Google Cloud supplies hosting, storage, scheduled jobs and alerts. Gmail carries the existing mail threads; the portal and WhatsApp expose candidate conversations. Google Calendar and Meet support booked interviews. The same application record connects those channels, so each conversation does not become a separate hiring process.

Make authority part of the architecture

I keep AI shortlists and low-confidence cases with human reviewers. People conduct later rounds and make offers and hires. Internal chat assistants prepare changes for confirmation. Mail the system cannot confidently handle enters a review queue.

First-round routing consumes the scorer’s recommendation and confidence under its routing rules; that limited automation does not authorize an agent to hire. An uploaded, human-approved offer can be accepted or declined online and has an expiry.

The safeguards live around the model too. An email leak check blocks scores and internal notes. System-authored receipts establish whether tool actions actually happened. A shared status-writing core keeps different paths from quietly disagreeing about where an application stands.

Build the handoffs, then test their failures

The most useful fixes came at boundaries. An expired Gmail subscription needed renewal, alerts and catch-up. An AI outage needed to lock and pause an interview instead of becoming poor candidate performance. Interview planning needed mandatory rubrics and retries, rather than an instruction that could be skipped.

I test with automated checks, replays against human decisions, shadow traffic and production acceptance checks. Incidents become permanent regression tests. Workflow components have off, shadow and on modes; candidate and recruiter chat can also be restricted to an internal allowlist. An interview records its selected runtime for that sitting. I check these activation settings separately from the configured inventory: the 3/17 split does not mean every target is live, and migration into Studio is gradual.

My advice to another builder is to start with responsibilities, tool permissions and the record each handoff must leave. Then decide which steps need an agent’s judgment, which need a scheduled job, and which must wait for a person.

Start building with Alchemist.