A recruiter posted a request that stuck with me: they're the one doing hiring, they feel the age gap when chatting with younger candidates, and they want an AI that helps them reply. Their plan was straightforward — feed in the company's benefits and some industry background, then paste the chat context from a messaging window and let the model suggest the best response. They even said plainly that their field is cutthroat, that they're competing with other firms for the same people, and that they need real conversational skill, not a mechanical bot.
That last line is the whole thing. They already know a canned chatbot won't cut it. What they're circling around, without quite naming it, is that the clever reply isn't the asset. The asset is the pile of facts only they have — the actual benefits, the comp bands, the honest read on the industry — plus a reliable way to turn pasted context into a usable draft. The prompt is disposable. The knowledge is not.
Why I'd stop chasing the "smart chat" framing
Two other things in the same community feed sharpened this for me. One day DeepSeek's API went down and people noticed a coding tool that depended on it kept working, which kicked off a whole thread guessing whether it had quietly built its own capacity or just signed a deal for reserved compute. Separately, someone compared ChatGPT and DeepSeek on the same question and got a clean answer from one and a bare "Server is temporarily unavailable" from the other.
If you build your recruiter tool as "paste text, hit one model, hope it's up and hope it's clever," you've bet your workflow on a single provider's good day. The part that survives an outage, a price change, or a model swap is the stuff you own. So I'd design around that: a store of your facts you can retrieve from, and a thin endpoint that drafts against those facts. Swap the model underneath whenever you want; the knowledge stays put.
The shape of the build
Three pieces, each small.
First, the facts. I'd load the company benefits, comp notes, common objections, and whatever industry context the recruiter trusts into a LanceDB knowledge base. The point of putting it in a retrieval store rather than stuffing it all into a prompt is that you can keep adding to it, correct a wrong number in one place, and only pull the two or three snippets relevant to the current conversation. When a candidate asks about remote policy, you retrieve the remote-policy entry, not the entire handbook.
Second, the drafting logic. I'd run Python online as a small endpoint: it takes the pasted conversation context plus the candidate's latest message, retrieves the most relevant facts from the knowledge base, and calls a model available through the platform's Model Center to produce two or three draft replies in different tones. Returning a few options instead of one matters here — the recruiter said they want range, not a single mechanical answer, so give them a warmer version, a more direct version, and let them pick.
Third, the surface the recruiter actually touches. A plain paste-and-suggest page, nothing fancy: a box for the pasted context, a box for the latest message, a button, and a column of draft suggestions they can copy. That's a static HTML front end calling the endpoint, and I'd lean on web app hosting to put it somewhere they can open on any machine without installing anything. If you want to track which drafts got used or flag facts that keep coming up, a small SQLite table behind the endpoint handles that without adding infrastructure.
The boundary, stated out loud
Here's where I'd be firm with the recruiter, because it changes the design and the expectations. This tool drafts replies for a human to review and send. It does not auto-reply, and it does not read the messaging app directly. The recruiter pastes context in by hand — exactly as they described in their own plan — and a person decides what actually goes out.
That's partly a capability boundary: wiring into a specific chat client to read and send messages isn't something I'd claim here, and I won't pretend it is. But it's also just the right call for hiring conversations. You want a person owning what gets said to a candidate, especially when you're making representations about pay and benefits. A draft the recruiter can edit in two seconds beats an auto-send they have to apologize for later. I like how some of the other builders in that same feed handled this — the ones shipping small AI-assisted tools tended to say flatly what their thing does not do, like "no account access" or "not official," and that honesty is what makes a narrow tool trustworthy.
What this actually buys the recruiter
No grand claims here, because I haven't run this with their data. What I can say about the design: the facts live in one place they control, so fixing a stale benefit number is a one-line edit, not a prompt rewrite. The model is swappable, so a provider outage or a price jump doesn't strand the workflow. And the draft step stays under human judgment, which is the only responsible way to run it for candidate-facing messages. Whether it makes them faster or wins them more hires is unverified until they use it — the point is that the parts worth keeping are built to be kept.
If you're an operator with a similar "I just want AI to help me answer people" itch — support, sales follow-ups, FAQ triage — the same three pieces apply. Put your real facts in a retrieval store, draft against them through a small hosted endpoint, keep a human on the send button, and don't bolt your whole process to one chat trick that works great right up until it doesn't.