# Kijito Recall > Recall patterns that make Kijito answer hard questions well — decompose multi-part questions into per-hop sub-queries, merge under a fixed context budget, chain entities between hops, and keep abstention discipline. Use when a question needs several distinct facts from memory (a "multi-hop" question), when a single recall came back with a compromise neighborhood that misses the point, or when deciding how deeply to retrieve before answering. - Skill: `kijitoai/kijito-recall` (Agent Skill) - Install (CLI): `npx skillmds@latest add kijitoai/kijito-recall` - Raw SKILL.md: https://api.skillmd.com/api/skills/kijitoai/kijito-recall/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Finance & Business - Author: KijitoAI (https://skillmd.com/u/kijitoai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/kijitoai/kijito-recall --- # 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=, sub_queries=[, , ...])`. 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 (e.g. 3 recalls × limit 8 instead of 1 × 24) and merge + dedup the results yourself. Doing that against a server that HAS the parameter re-implements, client-side and less well, a merge the server has already measured. 3. **Keep the budget fixed.** Whichever path ran, keep the TOTAL context you carry no larger than what one deep recall would have given you (`limit` is the cap on the merged set). Decomposition is for aiming, not for smuggling a bigger context load. 4. **Chain the hops.** When an early hop's answer names the entity the next hop needs, rewrite the next sub-query around that entity and recall again — chaining is a second call, not a bigger first one. ## When NOT to decompose Leave single-part questions alone. A decomposition step on a simple lookup adds latency and near-miss context and helps nothing. Decompose only when the question genuinely needs several distinct facts joined together. ## Abstention discipline Abstain as readily as you would with a single recall. Decomposed retrieval surfaces more adjacent-but-wrong material, and near-miss context is exactly what tempts a confident answer to a question whose true answer is "that isn't in memory". If the merged results don't actually contain a hop, say so — don't bridge the gap with plausibility. ## Related - `kijito_guide(topic="recall")` — how recall scoring works (semantic + graph traversal + keyword boost) and why wording decides findability; this pattern is documented there too. - `kijito_guide(topic="writing")` — writing memories so future sub-queries can find them.