Retrieval logs
Retrieval logs record which context a client or file retrieval touched, so teams can trace an agent's output back to the files behind it.
What are retrieval logs?
Why do retrieval logs exist?
When an agent produces an answer, it's not obvious from the answer alone which files it actually read to get there, or whether a client is reaching further into the repository than it should. Without a record of what got retrieved, debugging a wrong answer means guessing at what the agent saw, and there's no way to confirm a client's access matches what it's supposed to use. Retrieval logs give a direct trace from an output back to the files behind it.
How do retrieval logs work?
From the per-API-key view, retrieval logs show what a given client has been retrieving over time, which is the view to check when debugging an agent, verifying a client is set up correctly, or investigating an unexpected output. From the per-file view, retrieval logs show how often a specific file has been retrieved and by what, helping to understand a file's usage or how it influenced a particular response.
Together, the two views let a team audit access to the context repository from either direction: starting at a client and asking what it touched, or starting at a file and asking what touched it.