Skip to content

How retrieval works

jitprompt gives an agent two ways in: browse (get_toc, then get_section) and search (search_instructions). No language model runs when an agent calls a tool, so calls are fast and deterministic.

get_toc returns one entry per ready document: its title, a one-line summary of what it is for, and — for documents with at most 8 sections — the sections inline:

## Refund policy [doc 3f2a9c1e]
Rules for refunding customers by plan and region; read before issuing any refund.
- [8c1d02aa] Enterprise refunds — refunds on annual enterprise contracts
- [b71e4f09] EU withdrawal right — 14-day cancellation for EU consumers
## Error codes [doc 77ab01c4] — 42 sections; get_toc(document_id="77ab01c4") lists them
Look up an API error code by number to explain it to a customer.

Larger documents show a count; the agent expands one with get_toc(document_id=…) or, better, searches it.

The map is kept to about 8,000 tokens. A namespace with hundreds of documents gets the most detailed view that fits, and the map says it is condensed:

  1. the full map, as above;
  2. one line per document, without sections;
  3. titles only;
  4. an overview: the namespace’s description and how many documents it holds.

The agent then asks for the map for its task:

get_toc(query="checking eligibility before a credit card application")

returns the documents that best match, best first — so the same agent prompt works for three documents and for seven hundred. Give a large namespace a description (on its page: what the documents are and how they’re organized); agents read it at the top of every map.

A few documents can be pinned: agents get them whole without asking, in the server’s instructions or at the top of their first answer, before any map or search. Pinning is for the procedures every task depends on, such as finding an account id or the escalation codes. Agents rarely search for these, because they search for the task itself. See Pinned documents.

search_instructions(plan) takes a description of what the agent is about to do — “writing a refund email to an enterprise customer” — and ranks sections by three signals, fused with reciprocal rank fusion:

Signal Finds
Section summary sections whose purpose matches the plan
Passage meaning sections containing a passage close in meaning
Exact words sections containing the exact identifiers (table names, codes, flags)

It returns whole sections, grouped by document, best document first, until a budget of about 4,000 tokens is used (from at most 6 documents). A small document — up to about 800 tokens — comes back whole, every section in order, so an agent reads it as one piece; a larger one contributes its best two matched sections — more when only a few documents matched and budget is left, as in a namespace of a few long policies. In a namespace’s default focused profile, documents whose match is weak next to the best one are left out rather than padding the result; the catalog profile (for hundreds of similar documents — set it on the namespace page) keeps everything that matched, because what a task needs there is often several documents that score alike. Either way, documents that matched but didn’t make it are named at the end, so the agent can open one if the ranking was wrong. An agent never gets half a rule. Every section says which document it comes from:

# Eligibility and pre-application checklist [id: 8c1d02aa]
From: Bronze Rewards Card: how to apply [doc 3f2a9c1e]
Minimum credit score: 640 …

A document’s title counts extra in search only when the plan names it specifically — a phrase from the title, or two of its words, that few other titles in the namespace share. So “Gold Rewards Card” finds the Gold Rewards Card and ranks it above the Business Gold Rewards Card, while a word that is in most titles (“card”, “account”, “promo”) earns nothing by itself. Name the product, system or identifier in the plan when you know it.

Ids in tool output are 8-character prefixes (8c1d02aa); every tool accepts them as-is, as well as full ids.

  • Try a search on a namespace shows a search’s results with the matching signal, score and size of each section.
  • Diagnostics shows real agent calls: latency, empty searches, which sections are never returned, and near-duplicate sections across documents.