A recruiting workflow that actually runs
People ask us for real use cases — not "imagine if." So here's one you can rebuild today, with every step tied to a feature that's actually in the product. The scenario: a hiring team that receives a steady trickle of résumés and wants them screened, shortlisted, and handed off — without anyone reading 50 PDFs by hand.
This runs end-to-end on shipped capabilities. The only outside setup is a Slack webhook (a two-minute step), and even that's optional — email-to-yourself covers it.
Set up once
- A role to hire for. Put the job description in a Library folder (say, Open roles → Backend Engineer). The Library indexes it, so agents can screen against it. (RAG / Library — shipped since launch.)
- A place for incoming résumés. A Library folder, Inbox → Résumés, where new CVs land. (File library — shipped.)
- Where to be notified. Verify your email in Settings → Messaging, and (optional) create a Slack incoming-webhook for your #hiring channel. (Verified destinations + Slack node — new in v1.4.0.)
The workflow
Open the Workflow Builder (it's now a team of experts that drafts and wires this with you) and describe it, or build it node by node:
- Run input — the workflow asks which role to screen for, through a guided form instead of raw JSON. (Declared run inputs — v1.3.0.)
- Iterate over each résumé in the batch you feed the run — attach them to the run, or have an earlier step gather them from your Inbox → Résumés folder. (Iteration — v1.3.0.) For each one:
- Recruiter agent reads the résumé and scores it against the job description from your Library: a structured scorecard with a fit score, strengths, and gaps. (Recruiter — new in v1.4.0; grounded in the JD via RAG.)
- Switch on the score. (Switch — v1.3.0.)
- Strong fit → the Recruiter drafts a personalized first-touch email and adds the candidate to a shortlist. (Optional: hand off to the Chief of Staff agent to propose interview slots, if you've connected a calendar.)
- Not a fit → log a one-line reason and move on.
- The cross-run data store remembers who's already been screened, so re-runs skip duplicates instead of re-processing the same CV. (Cross-run data store — v1.3.0.)
- Compile the shortlist into a clean ranked summary and:
- Save it to your Library for the record,
- Post it to #hiring on Slack, and
- Email the summary to you. (Slack node + Email-to-self node — v1.4.0.)
- Put it on a schedule — daily at 9am, or trigger it on demand. (Scheduling — shipped.)
What you get
Every morning: a ranked shortlist in #hiring and your inbox, each candidate with a fit score, a short rationale, and draft outreach ready to send — and no human has opened a single PDF to get there. Adding a new role is just dropping another job description in the Library.
Why this isn't hand-waving
Each step above names the exact feature it relies on, and every one of them is shipped: Library + RAG, the Recruiter agent, iteration, switch, the cross-run data store, the Slack and Email nodes, and scheduling. Swap the domain and the same skeleton covers a lot of ground — support (triage tickets → draft replies → escalate the hard ones), sales (research leads → draft outreach → log + notify), or finance (categorize transactions → flag anomalies → notify). The pattern is the product.
Rebuilt this for your own team? Post your version — we'd love to see what you screen for.