Skip to content

Talent-finder core

talent_finder_process receives a typed TalentSearchIntent. It compiles that intent into a deterministic query for the active database backend, applies staff-level mapping, previous-result and self-exclusion filters, then projects the fields requested by the tool together with available first and last names. MongoDB uses Atlas Search. PostgreSQL uses accent-folded full-text, prefix and per-token fuzzy expressions over the equivalent relational fields.

The current flow returns at most five users and one combined rationale. Each candidate rationale is generated as two or three separate sentences through the shared provider-independent structured-output connector. The application checks that every candidate appears exactly once and restores input order. The model writes complete sentences and may use a supplied first name, last name or both according to context, without translating names or inventing missing identity parts. Candidates sharing a first name remain distinguishable through their supplied surnames or other supported context. Unnamed candidates use neutral references. Explanations follow the conversation language and use the configured default profile. Invalid or incomplete output is rejected without a second generation call. When no matching criterion is supported, the text invites review instead of inventing a match or describing missing profile fields. Optional debug output can include the generated query.

Each sentence must add a distinct supported fact or a useful next step. When only one relevant skill is listed, the explanation states it once and invites a conversation about the searcher's needs around that skill. It does not repeat the skill match to fill the sentence count or assume prior projects, experience or a proficiency level.

Experience titles alone do not establish that a role is current or has ended. When timing is not explicit in the supplied evidence, explanations use neutral wording such as "The profile mentions experience as a Data Analyst". A current role may be described as such only when the evidence explicitly supports it.

User-facing streaming emits:

  • talent.criteria before compiling search criteria;
  • talent.matches before Atlas retrieval;
  • talent.summary before the combined rationale.

Returned user IDs are stored in the successful tool message's artifact.returned_user_ids, separately from its user-facing text. Conversation checkpoints preserve this metadata. The next talent search collects distinct IDs from the last 25 messages and excludes them when the user requests more results; a new search does not apply these exclusions. Tracking does not depend on the model's wording or choice of names. Historical messages without this metadata cannot contribute IDs to the exclusion list.

No LLM is used to invent database syntax in this flow; the model resolves typed intent upstream and the core builds the query deterministically.

Education, certification and total-experience-duration criteria are not part of TalentSearchIntent and are not projected into candidate rationales. The work-arrangement criterion remains optional: omitting it adds no filter, while a provided value is enforced. PostgreSQL keeps strict semantics when its aihub_user_v1 projection does not expose the requested work arrangement and returns no match rather than silently dropping the constraint.