AI recruiting in Ashby works because Ashby exposes funnel data through its public API, so an agent can read stage conversion, time-in-stage, and source-of-hire numbers the same way a recruiter would. The job of the agent is not to send outreach. It is to read the funnel every morning, flag the one stage that is leaking, and propose a fix the recruiter can ship before standup. The recruiter still owns the decision. The agent owns the diagnosis.
The workflow
1. Pull yesterday's funnel from Ashby. A scheduled job hits Ashby's application.list and interview.list endpoints and writes the deltas into a working table. ChatGPT or Claude reads the table and answers one question: which stage moved worse than its 30-day median? This is the only question worth asking before 9am.
2. Diagnose the stage. If recruiter-screen-to-onsite dropped, the agent pulls the last 20 rejected candidates from that stage and clusters the reject reasons. If sourced-to-replied dropped, it pulls the last 50 Gem sequences and compares reply rates by template. Naming the cause matters more than naming the metric. See our broader take on AI candidate screening for how this looks across the funnel.
3. Propose one change. The output is never a dashboard. It is a single recommendation: pause sequence X, reword the screen rubric, add a second sourcer to the SDR req. The agent drafts the Slack message to the hiring manager and the Ashby comment on the affected req.
4. Capture the decision. When the recruiter agrees or overrides, that decision needs to live somewhere a future agent can read. Ashby holds the candidate record. The reasoning lives elsewhere.
5. Re-check in 72 hours. The same agent runs again on Thursday and answers: did the change move the number? If yes, write it into the playbook. If no, escalate.
Worked example: a 25-person Series B hiring 4 AEs
The funnel agent flags Tuesday that onsite-to-offer dropped from 38% to 19% in two weeks. It pulls the eight onsite rejections, sees six cite "ramp risk", and traces the pattern to a single hiring manager who started weighting territory experience after a bad Q1. The agent drafts a calibration note, the head of sales agrees, the rubric gets rewritten in Ashby, and offer rate recovers in nine days. The agent did not hire anyone. It found the leak. Compare this with the Greenhouse-flavored version of the same loop, which leans more on structured-interview kit data than on Ashby's raw funnel deltas.
Where this workflow breaks
The diagnosis is the asset. The diagnosis is what dies. Today the funnel-leak conversation lives in a Slack thread that scrolls away by Friday, a Notion doc nobody updates, and a recruiter's head. Six weeks later a new sourcer joins, hits the same recruiter-screen drop, and rediscovers it from scratch. Bardeen and Gem will both happily re-run the workflow. Neither remembers what was tried last quarter.
One way to solve this is a workspace like Dock that holds the agent's interpretive layer (the funnel diagnoses, the reject-reason clusters, the calibration notes, the reviewer overrides) as durable rows with pointers back to the Ashby application_id. Ashby stays the system of record for the candidate. Dock holds what the agent learned about the funnel. The audit trail for those agent actions is its own discipline: see agent audit and compliance and agent identity lifecycle for the primitives.
Why it matters
Analytics-first hiring only compounds if the analysis persists. According to LinkedIn Talent Insights, the teams that beat their benchmarks are the ones who act on funnel data weekly, not quarterly. The agent makes weekly possible. The workspace makes it cumulative.
If you are setting up this loop end to end, start with the pillar: how to do hiring with AI in 2026, then read Dock for HR for the persistence layer.
FAQ
Does Ashby have an open API for AI agents? Yes. Ashby publishes a REST API at developers.ashbyhq.com covering candidates, applications, interviews, jobs, and webhooks. Agents authenticate with an API key and read the same data the Ashby UI reads.
Can ChatGPT or Claude read Ashby data directly? Not without a connector. The pattern is to pull Ashby data into a working table on a schedule, then let the model read that table. Bardeen and custom MCP servers both handle the pull step.
How is this different from Ashby's built-in analytics? Ashby's dashboards show you what happened. The agent workflow tells you which one number to act on today and drafts the fix. The dashboard is the input, not the output.
Where should the agent's diagnoses live? Not in Slack. The candidate record stays in Ashby. The funnel diagnosis, the reject-reason clusters, and the reviewer decisions need a durable home with pointers back to the Ashby application ID, so the next agent or the next recruiter can read what was already tried.