A research assistant can produce a tidy paragraph, name a handful of papers, and still leave you with a difficult question: did the sources actually support what it wrote?
That question becomes harder when an agent searches several collections, follows references, retries a request, and condenses everything into a short answer. The final text hides most of those decisions. A failed search and a successful search with no relevant results can end up looking surprisingly similar.
For an agent helping with a literature review in machine learning or biotechnology, I would want to inspect the path from the question to the evidence. That means keeping enough information about tool calls to explain where a source came from, what the agent received, and which parts of the response still need checking.
Follow one claim back through the run
Consider a hypothetical assistant asked to find papers that compare two approaches to protein representation learning under the same evaluation conditions. It returns three references and says that one approach consistently performs better.
The first review task is to check that sentence. Do the papers compare the same task? Are their datasets comparable? Does the relevant result appear in the retrieved passage, or did the agent infer a broader conclusion from an abstract?
Suppose one reference came from an abstract search, another from a full paper, and the third from a citation mentioned in a review. Those are different evidence paths. Recording them lets a reviewer see why the answer sounds more conclusive than the available material warrants.
A useful investigation starts with one claim and follows its supporting references backwards. Each reference should lead to the retrieval event that supplied it. That event should lead to the query and the run that requested it. Without those connections, reviewing the answer becomes a second literature search.
Record the boundaries between actions
There is no need to capture every internal detail to make this review possible. Begin with the moments when the agent interacts with something outside the model: searching, fetching a document, extracting a passage, or returning an answer.
For each tool invocation, a small event record could include:
- A task identifier for the research question and a run identifier for this execution.
- A tool-call identifier, with a parent identifier when one action triggered another.
- The tool name, tool version, and attempt number.
- Start and finish times, plus a sequence number within the run.
- An explicit outcome such as completed, timed out, rejected, or cancelled.
- References to the input, returned documents, and any retained excerpts.
These fields answer different questions. A task identifier connects repeated evaluations of the same question. A run identifier distinguishes today's execution from yesterday's. The attempt number explains why the same request appears twice.
Timestamps help establish duration, but parallel work can make a simple time-ordered list misleading. Parent identifiers preserve the relationship between a search and the document fetches it triggered. A sequence number can help reconstruct the order in which one component observed events, while leaving concurrent actions identifiable.
Keep the meaning of each outcome explicit. A tool returning a response tells you that an interaction completed. Assessing whether its content supports a scientific claim requires a separate check.
Give empty results a precise meaning
Return to the hypothetical literature search. Imagine that its first request times out. The agent retries with a broader query, receives three documents, and writes its answer from those results.
If the record contains only the last response, the run appears straightforward. The missing timeout matters because the retry changed the question being asked of the search tool. A comparison constrained to one benchmark may have become a general search for the two methods.
It helps to distinguish several cases:
1. The search completed and returned no documents. 2. Documents arrived, but none passed the relevance check. 3. The request failed before a usable response arrived. 4. A response arrived, but the agent could not parse it.
Each case suggests a different next step. The first may justify another search formulation. The second calls for a look at relevance criteria. The third points towards request handling. The fourth puts the response format and parser under scrutiny.
An empty list should therefore carry a reason when the workflow can establish one. When the reason is unknown, preserve that uncertainty. Otherwise, a later reviewer may read “no supporting papers” into what was actually a temporary retrieval problem.
Keep the evidence available without copying everything
A reference identifier alone may be insufficient when a document changes or an extraction is repeated. Useful context includes the source location, retrieval time, document version where available, and the particular passage used to support a claim.
For a paper, the relevant passage might be a paragraph describing the evaluation protocol or a table caption explaining which split was used. Retaining its location makes a human check much quicker. Where retaining the excerpt is appropriate, record it alongside that location.
The same approach can apply to internal research material, with more care about what leaves the research environment. Tool arguments and responses may contain unpublished results, access credentials, or identifying information. Decide what may be retained before those payloads reach the event store. A restricted artifact reference can preserve the route to an input without making a second copy of its contents.
Document the omissions too. If a response body was deliberately excluded, a reviewer should see that it was withheld. An absent field without an explanation can look like a collection failure.
Make the event history easy to question
Return to the three papers cited in the protein representation answer. Before accepting the comparison, I would want to know what the assistant actually retrieved for each one. An abstract, a full paper, and a passing reference in a review provide different amounts of evidence about an evaluation protocol.
With the assistant's search and document-fetch events stored in RawTree, I could use SQL to pull up the retrieval attempts behind those three citations. Did the full-text request succeed? Did a retry drop the benchmark name from the search? The event records would need to preserve those details and the passage references so that a reviewer could follow the answer back to the material available when it was written.
That investigation might reveal that the assistant cited a paper after its full-text request failed. The next step would be to inspect the abstract or other material it did receive and check whether that material supports the claim. A failed fetch alone does not settle the question, but it identifies a specific part of the answer that deserves attention.
An incomplete event stream deserves attention as well. A run with no recorded completion should remain unresolved until its status can be established. Silently excluding it makes the visible history appear cleaner than the actual workload.
Compare fixes on the same research questions
Suppose a change makes the agent retry failed requests more patiently. A useful evaluation would rerun a fixed set of research questions and examine both the resulting answers and their evidence paths.
Keep the question set, document collection or snapshot, and evaluation criteria identifiable. Record the model and tool versions too. If the corpus changes between evaluations, acknowledge that difference when interpreting the result.
For the protein representation example, a reviewer could check whether each answer identifies compatible evaluation conditions, supports its comparison with the cited passages, and distinguishes missing evidence from an unsuccessful search. The event history helps explain a changed result. It does not independently decide whether the scientific comparison is valid.
Look for costs introduced by the fix. More retries could recover useful documents while extending the time required to answer. A broader query could improve retrieval while admitting less relevant papers. Reporting those effects together makes the decision about the change easier to assess.
Finish with a reviewable correction
When an investigation finds a problem, save the research question, affected run, supporting events, and correction together. A short note might say that a timeout triggered a broader query and that the resulting answer overstated the comparability of two studies.
That note gives the next evaluation something concrete to check: whether the retry preserves the research constraints and whether the answer marks unresolved comparisons clearly.
The useful endpoint is an answer whose evidence can be followed. A reader should be able to locate the relevant passage, understand how it was retrieved, and see where the agent encountered uncertainty. That makes the assistant's work easier to review before it becomes part of someone else's research.