A deep search is a multi-stage AI pipeline, not an instant lookup. You type a query in natural language, switch the query bar to AI mode, and Chosen plans the search, pulls a candidate set, has an LLM read and score each resume, and streams the results into a table as they finish. A run takes from about 30 seconds to a few minutes.

What it is

Smart search matches the fields already parsed onto a candidate. Deep search goes further: it reads the resume body, expands the terms in your query, scores how well each candidate fits, and builds result columns specific to what you asked. It is the tool for queries that need judgment — "engineers who led a small team at a Series B" — rather than a field match.

The four phases

A run moves through four phases, and the status row at the top of the results tells you which one you're in.

Plan. An LLM reads your query and writes a search plan. It expands shorthand — "FANG" becomes Google, Meta, Apple, Amazon, Netflix, Microsoft — and decides which columns the results table should show for this specific query.
Recall. Chosen pulls candidates three ways: a meaning-based vector match, a literal keyword match, and a field-level match. It unions the three, removes duplicates, and caps the set.
Score. An LLM reads each recalled candidate, rates their fit from 0 to 100, and fills in the per-query columns. This runs in parallel batches — which is why results arrive in groups.
Complete. The status row shows the final count and how long the run took.

Why results stream in

Scoring happens in batches, in parallel, and each batch writes its results the moment it finishes. So the table fills in over the run rather than appearing all at once. Watching it populate is normal.

One thing to know: results are not ranked in the order they arrive. A late batch can contain your best candidate. The table sorts by fit score, so once the run completes you are looking at a ranked list — but mid-run, the order is still settling. Wait for the run to finish before reading the top of the table as a final ranking.

The per-query columns

A deep search table is not your usual candidates table. The planning phase decides what columns would help you judge fit for this query, and the table rebuilds with them.

Ask for "people who worked at FANG" and you might get a column listing which FANG companies appear on each resume, plus a seniority column. Ask for "candidates with a master's degree" and you get a single column showing the degree. The columns are query-specific by design — a generic set of columns wouldn't tell you what you actually wanted to know. Each scored candidate also gets a fit score and a one-line explanation of the rating.

The 150-candidate cap

Recall caps the candidate set at 150. If your pool has more than 150 plausible matches, deep search scores the strongest 150 and the rest are never seen by the scorer.

This is rarely a problem for a specific query. It becomes one for a broad query — "engineers" against a pool of thousands will hit the cap and quietly leave good people out. The fix is to narrow the query: add a location, a seniority, a domain, a tool. A tighter query is also a better query.

When it gets it wrong

A candidate you expected is missing. They likely didn't make the recall set. Recall depends on the resume containing the right signals — narrow the query so the candidate ranks higher in recall, or check that their resume parsed (see resume parsing).
A row says scoring was unavailable. A scoring batch can fail. The rest of the run still completes; re-run the search if a placeholder row matters.
The columns aren't what you wanted. The planner picks columns from your wording. A vague query gets vague columns — rephrase with the specifics you care about and run it again.

Limits

Deep search runs against candidates already in Chosen — it does not search the open web. It also takes real time; there is no instant version. If you need speed, smart search is the answer. To go find new people entirely, that is sourcing.