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.
The table of contents
Section titled “The table of contents”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 themLook 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.
Large namespaces
Section titled “Large namespaces”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:
- the full map, as above;
- one line per document, without sections;
- titles only;
- 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.
Pinned documents
Section titled “Pinned documents”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
Section titled “Search”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.
Seeing it
Section titled “Seeing it”- 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.