We've shipped a Recruitment agent: it discovers prospective students on social platforms, qualifies them against the institution's own ideal student profiles, deduplicates them against everyone it has already recorded, and writes the survivors into the CRM with a score attached.
The prompt in the screenshot above is the entire input — "please find and record at least 5 people (potential students) from instagram, who have posted recently that they are interested in taking an AI course."
Everything after that is the agent: checking its memory for prior runs, verifying it can reach the CRM and the scraper, choosing hashtags, capping the crawl to control cost, and scoring what it finds.
Watch the agent run
What does the recruitment agent actually do?
The Recruitment agent turns a sentence into a qualified pipeline. It runs a four-step loop, and each step is a real decision rather than a scripted stage.
It searches where the signal is. It picks hashtags and keywords from the request — for this run #aicourse, #artificialintelligence, #machinelearning, #learningai, #upskilling — and runs a hashtag scraper against them with a result cap it chooses to control spend.
It qualifies against a rubric, not a keyword. Each profile is scored against the school's ideal student profiles. In this run the top fits were ISP-1 (Career Advancer) and ISP-2 (Entrepreneur) — employed professionals and founders, not current students.
It deduplicates before it writes. The dedup cache is consulted before the search, not after, so a second run does not re-surface someone the admissions team already contacted.
It writes to the CRM. Qualified prospects land in Twenty with full profiles and qualification scores, split into hot and warm so outreach has an obvious starting point.
What did one run produce?
This is the agent's own summary of a single run, unedited.
| Metric | Result |
|---|---|
| Posts read | 738 |
| Run duration | 45.8 seconds |
| Profiles that cleared the rubric | 81% |
| Countries represented | 13 |
| Post recency | 24–48 hours |
| Prospects written to the CRM | 13 (5 hot, 8 warm) |
Recency is the part that is easy to undervalue. Every post the agent kept was less than 48 hours old — someone who said out loud, this week, that they want to learn this.
The 13 prospects came from Kenya, Nigeria, Brazil, Singapore, Germany, India, Pakistan, the UK, the USA, Canada, Mexico, the UAE, and Indonesia. A human recruiter working hashtags does not cover thirteen countries before lunch.
What does a qualified lead cost?
$1.70 for the run. 13 qualified prospects. About 13 cents per lead.
That number is the argument, and it only exists because the cost is usage-based. Per-seat AI pricing is the wrong shape for recruitment work, which happens in bursts around application deadlines and then stops.
| Pricing shape | Monthly cost | What drives the bill |
|---|---|---|
| Per-seat AI assistant, 12-person admissions team @ $40/user | $480 | Headcount. Billed in full in the months nobody searches. |
| Same team at 50 seats | $2,000 | Headcount again. The work did not change. |
| ibl.ai, usage-based | $1.70 per run | Tokens and scraper calls actually consumed. Ten runs a month is $17. |
The seat count is the thing to notice. A per-seat contract prices your org chart; a usage-based one prices the work. At any institution above a hundred users, those two numbers stop resembling each other.
How does it avoid recording the same person twice?
Memory, checked before the search rather than after it. The agent keeps two things between runs: a dedup cache of profiles it has already recorded, and a run ledger of what each prior run searched and found.
That is the difference between a demo and something an admissions office can actually use. A scraping pipeline without memory hands the same twenty people to your team every Monday, and by week three nobody opens it.
The ledger also makes runs auditable. Each entry records the platform, the hashtags, the actor, the result count, and the spend — so a director can ask where a lead came from and get an answer.
Memory is a first-class panel on every agent, not something bolted on for this one. See Agent Settings: Memory.
Where does the agent run?
On a dedicated sandbox server — its own execution workspace, registered to the agent and health-checked from the Sandbox panel, with configuration pushed to it on save.
That matters for this agent more than most. It holds CRM write credentials and a scraper API key, and it executes tools against the open internet. Giving it an isolated runtime means the blast radius of a bad tool call is one workspace, not the platform.
It is also where the ownership story becomes concrete: the runtime is a host you control, inside your perimeter, running a stack whose source code you hold.
What is the agent made of?
Markdown files, editable in the browser. The screenshot below is the identity file for this agent open in the editor.
It reads as prose, because it is prose: "My job is to discover prospective students across social media platforms, qualify them against the school's ideal student profiles, and maintain clean, deduplicated records of every prospect in the school's CRM."
The qualification rubric lives in the same place. If your institution weights a career-changer above a recent graduate, or refuses to record minors, you write that sentence into the file — no plugin, no deployment, no code review.
Everything else is a panel in the same editor: the model (this run used a small, inexpensive one), the integrations it may reach, its skills, its safety and privacy rules, and its sandbox host.
Which platforms come next?
The run ledger closes with the agent noting it is ready to repeat the process on LinkedIn, X, and TikTok. Nothing in the loop is Instagram-specific — the search tool changes, the rubric, the dedup cache, and the CRM write do not.
The same shape generalizes past admissions, too: the pattern is discover on a public platform → qualify against a written rubric → dedupe against memory → write to the system of record.
Corporate recruiting, alumni relations, and partnership sourcing are the same four steps with a different rubric.
Where to find it
The Recruitment agent is configured like any other agent in Agentic OS — identity, prompts, skills, integrations, memory, and sandbox, all in the same editor.
If you want to see what else agents on the platform can be given, the ibl.ai agent catalog has around a hundred pre-built configurations across higher education, K-12, enterprise, government, and regulated verticals — each one a set of Markdown files you can read, edit, and own.