I’ve spent enough time in staffing to notice a pattern: sales and recruiting are sitting on the exact same relationships, and most of the time neither side knows it.
Here’s what I mean. A recruiter on my team talks to a candidate today. That candidate works at a bank we’ve been trying to break into for months. My recruiter has no reason to think about that account, they’re just trying to place someone. Meanwhile, a sales rep three desks away is cold emailing a director at that same bank, with zero idea that someone on our own team already has a foot in the door.
Nobody did anything wrong. Recruiting and sales just have different priorities, different systems, different daily rhythms. Recruiters are heads down on candidates. Sales is heads down on accounts. The information that would connect the two exists, it’s just sitting in somebody’s call notes, buried in an ATS field nobody else is reading.
I don’t think this is a “my team” problem. I think it’s a staffing industry problem. We’re an industry built entirely on relationships, and we still don’t have a good way to see our own relationships at a glance. Everybody’s got a CRM. Everybody’s got an ATS. Everyone has notes scattered across those systems, LinkedIn messages, emails etc. Nobody has a way to ask a simple question like “does anyone on my team already know somebody at this account” and get a real answer in seconds.
So I built a demo to show what that could look like.
What I built
It’s a plain English search tool sitting on top of fake recruiting data (candidates, companies, recruiters, notes) that lets anyone on a team ask a question the way they’d actually ask it out loud, and get back a real answer pulled from what your team has actually logged.
Things like:
- “Who’s talked to anyone at Barings in the last 30 days?”
- “Show me QA engineers with Playwright in Charlotte we’ve talked to in the last 10 days.”
- “Does my recruiting team know anybody at SMBC?”
If somebody fits, it tells you exactly who, which recruiter talked to them, when, and why they’re relevant. If nobody fits, it tells you that too, plainly.
I also built in an “entire pipeline” view, so if someone just wants to see everything the team has been working, they can pull that up as a full list instead of asking a specific question.
How it actually works
This demo does not call a live language model. What it does is pattern match. When you type a question, the code looks for recognizable pieces, a company name, a skill like Playwright or SQL, a location, a time window like “last 30 days,” and it pulls those out regardless of how you phrase the sentence. Then it runs that against the underlying data like a filtered database query, and hands back a plain English answer.
It’s a simulation of the experience, built to be fast, predictable, and demoable without needing an API key or an internet connection in the room. But it’s genuinely doing the job it looks like it’s doing, just with simpler machinery than a live model.
In a real build, that pattern matching layer would get replaced by an actual LLM call. You’d send the person’s question to something like Claude, have it extract the same structured pieces (company, skill, location, time window) but with real language understanding instead of keyword matching, and then run that against your live data.
How I’d actually build this for a real company
Step one is an audit, not a build. Before writing a line of production code, I’d need to understand what a company is actually working with. What’s their ATS. What’s their CRM, if it’s even separate from the ATS. What fields exist for notes, calls, submissions, interviews, placements. A lot of platforms like Bullhorn already structure this more than people realize, notes are usually tied to a specific candidate, contact, or job order, with a real timestamp. That structure is what makes a tool like this possible at all.
Step two is watching how people actually log information. This is the unglamorous part nobody wants to hear, but it’s the part that decides whether this works. If recruiters are logging notes consistently but inconsistently formatted, that’s a solvable problem, you use AI to parse and structure the messy text. If recruiters aren’t logging notes at all, no amount of AI fixes that. You’d need to actually sit with the data for a week or two, pull real notes, and see what you’re working with before designing anything.
Step three is designing the actual system. Once I understand the data, I’d be picking the right pieces: an API connection into the ATS/CRM to pull activity (maybe MCP pending the workflow design), a structured database underneath to hold the parsed and tagged version of that data (company, contact, recruiter, date, skills, relationship type), and an LLM doing the entity extraction and plain English querying, not keyword matching like the demo. Whether that’s a Claude API integration, a custom internal tool, or something layered on top of what the company already owns depends entirely on what step one and two turned up.
Step four is making it run on its own. The real version of this doesn’t wait for someone to ask a question. I’d want it running on a schedule, weekly at minimum, combing through everything logged since the last run, parsing it, tagging it, and updating the database automatically. That’s what turns this from “a tool you check” into “a system that’s always current.”
The part that actually excites me: surfacing trends before anyone asks
Once the system is running weekly on its own, it can do more than answer questions, it can start noticing things and telling you before you think to ask.
A few workflows I’d want baked in:
Account overlap alerts. A recruiter logs a call with someone at an account sales is actively targeting. Instead of that sitting quietly in a note, the system flags it to both people directly: “your recruiter just talked to someone at the account you’re chasing, go compare notes.”
Dormant relationship nudges. Somebody with a real tie to a key account, current or former employee, hasn’t been talked to in 60 or 90 days. The system flags it as a relationship going cold, worth a re-engagement.
Cross-sell signals. A candidate mentions in passing that their company is hiring, restructuring, or short staffed on a specific team. That’s not just candidate intel, that’s a lead. Right now that kind of comment lives and dies in one recruiter’s memory. It shouldn’t.
None of this is in the demo I built, the demo is meant to show the “ask a question, get an answer” experience. But this is where I think the real value sits long term. The goal isn’t a tool people have to remember to use. It’s a system that’s watching the relationships your team already has and tapping you on the shoulder when two of them are about to matter to each other.
Why I think this matters for staffing specifically
Staffing is a relationship business running on tools that were mostly built to track transactions, submissions, placements, deals closed. Nobody built the layer that connects the relationships across roles, because it’s genuinely hard to do well, and because most agencies haven’t had the tooling or the AI to make it worth trying until pretty recently.
The technology to build something like this for real, properly, on a company’s actual stack, exists right now. What’s missing is somebody in the room who understands both sides of the business well enough to know what to build and why. That’s the part I care about. Not the “AI as a party trick”, but the actual gap it closes between two teams who are already closer to each other than they realize.