Agent search: chat to a shortlist, no filters, no criteria forms

For the last year Taleva worked like every other modern sourcing tool: you opened a query builder, added a stack filter, an "is or contains" location, a list of must-be-at companies, a list of must-not-be-at companies, then a handful of weighted criteria below all of that. The product was strong. The interface was a form.

The new agent mode replaces the form. You write a sentence in a chat. The agent translates it into a search. You get a shortlist. If you don't like the shortlist, you say so — in words — and it adjusts. That's the whole product.

What changed in the workflow

Before: you read a brief, then translated it into the app — role family, seniority, stack equivalents, salary band, work authorisation, exclusion lists, criteria with priorities. Thirty minutes of UI operation before the first profile loaded. If you wanted to remove a competitor from the pool, you opened the company filter and pasted a URL. If you wanted to broaden, you went back into each constraint and softened it by hand.

Now: "Senior backend engineer in Madrid, 5+ years on Django, not at Glovo or Cabify." That single line is the search. The agent identifies the hard filters (role, location, exclusion list) and the soft criteria (Django depth, seniority signal), looks up the companies you named to resolve them to canonical LinkedIn entities (no more "did you mean Cabify the ride-share or Cabify the publisher?"), checks the resulting pool size, and runs the search. You see the shortlist with per-criterion fit on each candidate.

"I don't like this"

This is the part that matters most. The agent is built around critique, not configuration.

You can say:

• "Too senior. Show me 3–5 years instead."
• "None of these are actually Django. They're listing it as a side skill. Tighten."
• "Drop anyone currently at a consultancy."
• "Elena is exactly the kind of profile I want — find more like her."
• "Too narrow. We can compromise on the salary band."
• "Are these candidates actually open to switching, or am I about to send 30 emails into the void?"

The agent treats critique differently from a new instruction. It looks at the current shortlist before responding — it knows what it just showed you. When you say "tighten," it doesn't blindly add a filter; it inspects the candidates that didn't quite fit and refines the criterion that's letting them through. When you say "too few," it identifies the single most restrictive constraint and proposes a softening with the new pool count attached, so you can decide if 30 → 180 is worth it.

Exclusions stick. If you said "not at Glovo" three turns ago and now you ask for a fresh search, Glovo stays out. You don't re-state every constraint each time. The conversation is the state.

What the agent is actually doing under the hood

It isn't a thin wrapper that drops your sentence into a search box. A few things it handles that a form-based search can't:

• Company resolution — when you name a company, the agent looks it up against a canonical company database before adding it to a filter. Ambiguity is surfaced as a question ("Indra Group, Indra Inc. or Indra Sistemas?") rather than guessed silently.
• Group references — "FAANG", "the Big Four", "Spanish banks", "IBEX 35" all expand to their constituents. The agent infers the list, confirms it with you, then resolves each one.
• Stack equivalents — React ≈ Next.js ≈ Remix; Postgres ≈ MySQL for "relational database experience." A form would treat these as separate filters; the agent treats them as a single concept.
• Hard filter vs soft criterion classification — every requirement gets tested: would this candidate naturally write it on their LinkedIn? If yes, it's a soft criterion that scores candidates. If no (work authorisation, exact location radius), it's a hard filter that gates the pool. Mis-classifying these is the #1 reason form-based searches return zero results.
• Pool-aware editing — every filter change comes back with the new pool count and a bucket (empty / tight / healthy / loose). The agent reads that before running anything. If you ask for something that collapses the pool below useful size, it tells you and proposes a concrete softening before it runs.
• Durable state across turns — exclusions, criteria, location constraints all persist. You can re-run, refine, walk away for a coffee, come back, and the search is still the search you built together.

What this means for top-of-funnel

The whole point of the change: the part of your day that used to be "translate brief into UI" is now "have a conversation about what you actually want." The intelligence is the agent's, the judgment is yours, and the shortlist arrives in minutes.

It is, plainly, a very capable candidate search intelligence sitting at your disposal — one that reads briefs, runs lookups, weighs trade-offs, and asks for your input only when the brief is genuinely ambiguous.

Book a 30-minute demo and run it against a live opening of yours. Bring the messiest JD you have.