Retrieve with agentic RAG
Let an agent search your documents itself: it decides when to look, and looks again when the first answer is thin.
Ordinary retrieval works like a photocopied packet. Before the model sees your question, the system searches your documents once, staples the top few passages to the prompt, and hands the whole thing over. If the search picked the wrong passages, the model has no way to ask for different ones.
Agentic RAG gives the agent a library card instead. The agent gets a search tool it can call itself. It decides when to search, writes its own search wording, reads what came back, and searches again if the first result was thin. Then it answers from what it actually found.
"RAG" is retrieval-augmented generation: answering from your documents rather than from what a model happens to remember.
In chat, a turn searches your datasets once, answers, and cites the passages it used. See Datasets.
What the search tool can and cannot do
The tool the agent holds is called retrieve. It takes three things: which
dataset to search, the search wording, and optionally how many passages to bring
back (1 to 64, default 4). It returns passages in relevance order, each with the
text and enough identification to say which document it came from and which part
of that document it is.
Its limits are deliberate and enforced by the runtime, not by the model's good behaviour:
- Read-only. It searches. It cannot write anything, anywhere. Because it only reads, the human-in-the-loop gate lets it through without asking you (see Approvals).
- No network reach. It cannot call out to anything.
- No filesystem reach. It cannot read or write files. It reaches your datasets directly, never through a path on disk.
- Unknown arguments are refused. The argument shape is typed and rejects any key it does not recognise.
- It fails soft. A dataset that is missing, empty, stale, or has no way to embed the query comes back as an empty result with a plain-language note attached — not a crash. The agent reads the note and recovers: it can search a different dataset or answer from what it already has. Only a genuine failure stops the run, and it stops honestly rather than returning a fake empty.
- Long results are trimmed, and say so. If the passages together would be too large for the model's input window, the least relevant ones are dropped and the result carries a note saying it was truncated. The most relevant passage is always kept. Nothing is dropped silently.
The receipt
This is the part that separates agentic search from a black box.
Each retrieve call is recorded with the passages it actually read, in the order
it read them. So the record does not say "it searched the handbook and found
something useful" — it says "on turn 2 it searched for these words and read
exactly these passages, in this order."
Similarity scores are deliberately left out. The model proposes the search; what gets recorded is what was actually read. That keeps the record something you can check rather than something you have to trust.
A run's trail is read through Observability.
When to use it
Use plain single-shot retrieval when the question maps cleanly onto the words in your documents. It is faster and it is enough:
Use agentic RAG when the agent has to work out what to look for. Questions that span several documents, questions where the right search wording is not the question's wording, questions where a first search will probably come back thin. That is when letting the agent search again is worth the extra turns.
Search quality
The search behind the tool is hybrid: it matches on keywords and on meaning at the same time, so a term that a meaning-based search alone would misrank is still caught. For a fixed dataset and a fixed question you get the same order on any machine.
In chat there is a second pass where a model reorders the candidates. It runs on turns answered by your own provider connection, not on Kortecx hosted models, and it is fail-closed: if the model returns anything that is not a valid reordering, the original order stands. A rerank can never scramble your results into nonsense.
Retrieval quality is mostly a function of how you built the dataset — how the text is split into passages, and the choice of embedding model, matter more than anything on this page. See Datasets.
Keep memory between runs
Give an agent a notebook that survives between runs — remember a fact once, recall it by meaning later, and forget it when you want it gone.
Control what tools can do
How an agent uses tools, and how you decide which tools each run may use. A tool call you did not allow is refused before it happens.