--- title: "AI candidate sourcing with Gem: outbound workflows that don't lose context" excerpt: "Gem is the sourcing + CRM layer above the ATS. AI agents augment prospect research, sequence drafting, and reply triage through Gem's API. The workflow that compounds: agent personalizes outreach, sourcer reviews, the candidate research persists across roles." author: mei category: Playbooks date: "2026-05-30" --- AI candidate sourcing with Gem works best when you treat Gem as the outbound CRM, not the brain. The agent does prospect research, drafts personalized first touches, and triages replies. The sourcer reviews and sends. Gem's API holds the sequence state. The ATS (Greenhouse, Lever, Ashby) holds the candidate record. The note that makes the workflow compound, the *why this person for this role*, is the piece teams keep losing. ## The four-step workflow sourcers are running in 2026 **1. Build the search in LinkedIn Recruiter or hireEZ, export to Gem.** LinkedIn Recruiter is still the dominant top-of-funnel because the graph data is richer than anywhere else. hireEZ pulls passive candidates from open-web signals (GitHub commits, conference talks, patents) that Recruiter misses. Both push into Gem projects via native integrations. Version the search criteria so the next sourcer can rerun it. **2. Run the agent over each profile to draft a research note and opener.** ChatGPT, Claude, or a Gem AI workflow earns its keep here. The agent reads the public profile, the company's last funding round, and recent posts, then writes a 3-sentence rationale plus a first-touch draft. A good prompt names the role, the must-have criteria, and the tone. The sourcer reviews inside Gem's composer and sends. The same pattern lives in the broader [AI candidate sourcing playbook](/blog/ai-candidate-sourcing). **3. Let Gem run the sequence, route replies to the agent for triage.** Gem handles sends, follow-ups, and reply detection. When a reply lands, the agent classifies it (interested, not now, wrong role, hard no) and drafts the next message. The sourcer approves. This step separates teams sending 200 thoughtful touches a week from teams sending 2,000 sloppy ones. **4. Push qualified candidates into the ATS with the research trail attached.** Gem syncs to Greenhouse, Lever, or Ashby. The rationale, opener, and reply thread should travel with them. If you run Lever, the [AI workflow patterns for Lever](/blog/ai-lever-recruiting) covers the handoff. ## One worked example: a Series B sourcing a staff infra engineer A 50-person Series B needs a staff infrastructure engineer in EU timezones. The sourcer builds a Recruiter search for SREs at Stripe, Datadog, and HashiCorp who shipped Kubernetes work. hireEZ adds 40 candidates from KubeCon speaker lists. Gem holds the project. A Claude-powered agent drafts a one-paragraph rationale per profile (*shipped multi-region failover at Datadog, blogged about Postgres in Feb*) plus a 4-line opener naming a specific project. The sourcer reviews 60 drafts in 90 minutes, edits 15, sends 45. Gem sequences them. 11 reply. The agent triages: 4 interested, 3 not now, 4 wrong-role. The 4 interested move to Greenhouse with the full thread. The hiring manager opens Greenhouse and sees not just a name, but *why this person for this role*. ## Where the workflow breaks: the research note vanishes Six weeks later, a different sourcer opens a similar search and the agent has no memory of which profiles were already reviewed, why three were marked wrong-role, or what tone landed replies. Gem stores engagement. The ATS stores the record. Neither stores the *agent's interpretation*. So the rationale gets rewritten, the same passive candidates get pinged with worse openers, and no audit trail exists for the pass-overs. One way to solve this is a workspace like Dock that holds the sourcing rationale, the reviewer's edits, and the reply-triage decisions as durable rows, with pointers (`greenhouse_application_id`, `gem_prospect_id`) back to the systems of record. The ATS stays canonical. The agent gets a memory. The [agent identity model](/blog/agent-identity) makes the writes attributable, and the [audit log](/blog/agent-audit-and-compliance) makes the pass-over reviewable. ## Why it matters Outbound only compounds when the candidate research outlives the role. LinkedIn Talent Solutions reports that companies with persistent talent pools are [24% less likely to reopen a role within 12 months](https://business.linkedin.com/talent-solutions). That edge comes from the notes, not the names. For the full pillar on running hiring with AI in 2026, including screening, interviewing, and offer workflows, read [the hiring-with-AI playbook](/blog/how-to-do-hiring-with-ai-in-2026). For how this slots into the broader HR stack, see [Dock for HR](/blog/dock-for-hr). ## FAQ **Does Gem replace the ATS?** No. Gem sits above the ATS as the outbound CRM and engagement layer. Greenhouse, Lever, Workday, and Ashby remain the system of record for the candidate. Gem syncs qualified prospects in once they reply. **Can the AI agent send Gem sequences automatically?** Technically yes through the Gem API, but most teams keep a human approval step on the first touch. Auto-send works for follow-ups and reply triage drafts. Per [Gem's documentation](https://help.gem.com/), the API supports both prospect creation and sequence enrollment. **What's the difference between Gem and hireEZ?** hireEZ is primarily a sourcing tool: it finds passive candidates from open-web signals. Gem is primarily a CRM and sequencing tool: it manages the outreach once you have the list. Most teams use both, with hireEZ feeding Gem. **How do I keep candidate research from disappearing between roles?** Store the rationale and reviewer decisions outside the ATS and outside Gem, in a workspace the agent can read and write across sessions, with pointers back to the canonical IDs in both systems.