kijito-recalllisted

# Kijito Recall — aiming retrieval, not widening it `kijito_recall` embeds ONE query vector per call. A question that bundles several facts — *"where did X move after the job Y mentioned, and who introduced them?"* — retrieves a single compromise neighborhood that can miss every one of its parts. The fix is not a deeper recall; it is more, better-aimed recalls. ## The decomposition pattern (multi-part questions) 1. **Split** the question into at most 3 self-contained sub-queries, each phrased in the words its answer was likely *stored* under (recall matches wording — front-loaded concrete terms beat abstractions). YOU do the decomposition, in your own reasoning — the engine makes no LLM call. 2. **Recall them in ONE call** with the native parameter: `kijito_recall(query=<the original question>, sub_queries=[<sub-query 1>, <sub-query 2>, ...])`. Each sub-query runs the normal recall pipeline server-side and the ranked lists are merged for you — round-robin interleave, dedup, truncated to `limit` — so the result is already the aimed, budget-bounded set. The reply names the merge (`subquery_merge`); if it instead says it degraded to a plain recall (blank list, or a single entry equal to `query`), your decomposition was not used — fix the sub-queries rather than reading the plain result as decomposed. *Fallback only* — on a server whose `kijito_recall` has no `sub_queries` parameter, recall each sub-query separately with a smaller `limit` per call