recall_followup
Fetch results for follow-up queries from iterative recall, returning only new records not already retrieved. Pass prior_ids to preserve continuation state and avoid duplicate hits.
Instructions
MULTI-HOP recall, PHASE 2 of 2 — hand back the follow-up queries YOUR model wrote after reading
recall_iterative's round-1 hits, together with the prior_ids it returned. Each follow-up is retrieved
and only the records you do NOT already hold come back, so the second round costs you the bridge evidence
and nothing else.
prior_ids is the whole continuation state — there is no session on the server, nothing to expire, and
nothing that can be served to the wrong caller. Pass it. Without it every follow-up hit is reported as new,
including the ones round 1 already gave you.
Want a further round? Call this again with merged_ids from this result as the new prior_ids. Rounds
are your loop; the server holds no state between them.
Returns {followups_used, followups_dropped, new_hits, bridged, merged_ids, recall_calls, bounds}.
bridged is how many records this hop added — 0 is a legitimate answer and means the bridge was not there.
BOUND: at most min(len(followups), max_followups) recall() calls, max_followups itself capped at 8, and
at most k * max_followups NEW records. Worst case with both at their ceilings: 8 retrievals, 400 records.
Nothing here scales with store size. Honours the active project scope; all_projects=True crosses it,
and must match what you passed to recall_iterative or round 2 searches a different pool than round 1.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| full | No | ||
| query | Yes | ||
| user_id | No | ||
| agent_id | No | ||
| followups | No | ||
| prior_ids | No | ||
| session_id | No | ||
| all_projects | No | ||
| trusted_only | No | ||
| max_followups | No | ||
| snippet_chars | No |