Daily AI Paper

Today’s paper is about a surprisingly subtle failure mode in LLM agents: even when the agent computes the right answer, it can still answer incorrectly because it reads the wrong evidence. That matters because modern agent harnesses increasingly try to save context window space by not pasting long tool outputs directly into the prompt. Instead, they may store the output in a file, give the model a table of contents, let it search for relevant lines, or read only selected ranges on demand. That sounds efficient, and often it is. But if accuracy drops, the key question is not just whether the final answer got worse. The deeper question is where the loss happened: did the model compute the wrong value, fail to see the right one, or see it and then mishandle it? This paper studies that question in a setting where the truth is unusually observable. The tool is PHREEQC, a widely used aqueous geochemistry simulator from the USGS. Its reports are long, highly structured, and deterministic. That determinism is crucial: every printed value can be traced back and checked. The authors evaluate LLM agents on 158 multiple-choice questions that ask for quantities from PHREEQC output, such as a pH at a reaction step, a saturation index, or a molality in a transport cell. They first re-verified the answer keys by execution, so the benchmark items they keep are ones where the simulator output matches the keyed option exactly and uniquely. The main idea of the paper is to separate three stages that are usually tangled together. First is build: did the agent’s own simulation actually produce the keyed value? Second is exposure: if it did, did that value reach the agent in the information it read? Third is closure: if the agent saw the value, did it answer correctly from it? That decomposition is important because each stage points to a different fix. If build is failing, the issue is with the simulation input or setup. If exposure is failing, the issue is with how tool output is delivered. If closure is failing, the model saw the evidence but still misused it. To make this concrete, the authors compare different ways of delivering PHREEQC’s report. In one setting, the report is pasted inline, truncated to a 100,000-character budget if needed. In another, the agent gets a table of contents for the report’s sections and reads line ranges from the file on demand. They also test a grep-style search interface that has no simulator-specific structure, plus a hybrid mode and a few interventions. The agents have a small tool set: write_file, read_file, list_file, and execute_phreeqc. They are given at most 24 steps and must commit to an answer by writing it to a file. The models studied include Claude Opus 4.6, Claude Sonnet 4.6, GPT-5.4, GPT-5.2, GPT-5.1, and Gemini 3 Flash Preview. The Claude models run at temperature zero without extended thinking; the GPT and Gemini models use API defaults. The paper also includes no-tool baselines using direct prompting and chain-of-thought prompting. The benchmark itself is carefully filtered. The original pool had 200 items, but 42 are excluded because they are defective in some way: an incorrect key, a numerically unstable redox quantity, or wording problems. The final main analysis uses 158 items from 19 setups. The authors note that exclusion never used model outputs, and the full pool leads to the same overall conclusions. So what happens? The first big result is that retrieval cost depends strongly on the model. For Claude Opus 4.6, Claude Sonnet 4.6, and GPT-5.4, the difference between table-of-contents delivery and inline delivery is essentially near zero: the pooled changes are around minus 0.6, minus 0.5, and plus 0.2 percentage points, with intervals that include zero. But for GPT-5.1 and GPT-5.2, retrieval hurts: accuracy drops by 11.3 points and 7.9 points, respectively, relative to inline output. After correction for multiple comparisons, the GPT-5.1 difference is significant, and the GPT-5.2 difference is not quite significant in the pooled analysis, though other analyses strengthen the case. A second important finding is that the loss is not mainly in computation. The authors re-run all 11,007 logged simulator calls offline and check whether the keyed value was actually produced. For GPT-5.1 and GPT-5.2, the share of trajectories where the simulation computed the keyed value is about the same under every interface. In other words, the models are not obviously getting worse at setting up or executing the simulation. The problem is what happens after the value exists. That leads to the paper’s central concept: evidence substitution. Under retrieval, the GPT models often do not read the simulator’s canonical report. Instead, they answer from their own auxiliary output files, especially SELECTED_OUTPUT files, which can print more digits than the report. That seems harmless at first, but it creates a rounding trap. The report prints the quantity at the precision that matches the answer options, while the auxiliary file often prints a more precise number. The model then has to round correctly. The paper finds that GPT-5.1 and GPT-5.2 frequently truncate or misround that more precise value to a neighboring option. A typical example is a value like pH = 2.75065 that should round to 2.751, but the model instead chooses 2.750. When the keyed value is seen in the report’s own precision, answers are almost always correct. When it is seen only in the more precise auxiliary form, accuracy drops sharply. Sonnet, by contrast, shows much less of this behavior. The authors test whether this is really about retrieval rather than about the simulation itself by freezing GPT-5.2’s logged inline run at its first successful execution and replaying the rest of the interaction twice: once with the report inline and once with the table of contents. In this paired setup, the simulation is held fixed. The only thing that changes is how the evidence is delivered. Even then, TOC delivery costs GPT-5.2 about 9.4 points of accuracy. That tells us the loss is downstream of computation. They then decompose the loss. For GPT-5.2 under TOC, most of the drop comes from closure, with a smaller share from exposure. For GPT-5.1, exposure and closure each contribute meaningfully. This is a useful distinction: sometimes the model never sees the right evidence; sometimes it sees it but mishandles it. Both are retrieval problems, but they require different remedies. The paper also shows that a null net effect can hide a real retrieval problem. GPT-5.4, for example, also substitutes evidence and loses about ten points on numeric items when it uses the wrong evidence form. But it happens to compute the keyed value more often under retrieval, so the gain in build offsets the loss in closure. The final net change is near zero. That is an important warning: if you only look at final accuracy, you can miss a meaningful degradation in evidence use. The authors test a simple intervention: explicitly tell the agent to answer from the report. This reduces report skipping to under 2 percent and raises closure to 99 percent without changing build. Relative to all table-of-contents runs, accuracy rises by 6.3 points for GPT-5.1, 7.9 points for GPT-5.2, and 7.8 points for GPT-5.4. Inlining reports that fit in context has a similar effect for GPT-5.1 and GPT-5.2. By contrast, simply asking for correct rounding does not help. So the issue is not just that the model forgot to round carefully; it is that it answered from the wrong evidence source. There are a few broader takeaways here. First, context-management choices in agent systems should be evaluated by where accuracy is lost, not only by the final score. Second, retrieval can change not just what the model sees, but what it chooses to trust. Third, when a tool produces multiple outputs, the most convenient one for the agent may not be the authoritative one for the task. The paper’s limitations are also worth noting. The benchmark is specific: PHREEQC, multiple-choice numeric questions, and a particular style of structured scientific report. The strongest claims are therefore about this setting, not about all tools or all agent tasks. The decomposition is observational, not a clean causal estimate of each stage in isolation. And some analyses depend on logged trajectories and on the exact way models were prompted and allowed to read files. Still, the design is unusually strong for this kind of study because the simulator is deterministic and the answer keys were re-verified by execution. The big lesson is simple but important: in agentic workflows, the same computation can support different evidence trails, and those trails can change accuracy. If a model is right for the wrong reason, or reads the right value in the wrong form, a retrieval-optimized harness may silently make it worse. The paper gives us a vocabulary for that failure, and a clear reminder that when tool outputs get long, the question is not only whether the answer is in the context, but whether the agent actually answers from the evidence that matters. That framing also connects this work to a broader pattern in tool-using systems: once a model is allowed to generate its own intermediate artifacts, those artifacts can become a kind of competing evidence stream. In many real workflows, that may be useful, because a summary file or selected output can make a long report easier to navigate. But this paper shows the tradeoff is not free. When the auxiliary file is more precise than the canonical report, the model has to do extra reasoning to map it back to the answer choices, and that extra step is exactly where some agents slip. So the issue is not simply long-context failure in the abstract. It is a mismatch between the form of evidence and the form of the question. That is why the authors emphasize precision and rounding so much: in these numeric items, the difference between the correct option and the distractor can live in the last printed digit. A small formatting choice can therefore turn a correct computation into a wrong multiple-choice answer. The paper’s intervention results are especially practical for harness design. If a system can cheaply tell the model to answer from the authoritative report, that instruction alone may recover a large part of the lost accuracy. If the report fits, inlining it may be just as good. But if the system only asks the model to be careful about rounding, that does not fix the underlying evidence-selection problem. In other words, guidance about arithmetic is weaker than guidance about source selection. That is a useful lesson for any agent that mixes raw tool output with derived summaries, because the model may otherwise prefer the easiest-to-read artifact rather than the one the task was defined against. More generally, this kind of analysis is a template for studying agent failures in other domains. Finance, code execution, scientific simulation, and data analysis all produce long outputs where the authoritative answer may be buried inside a larger report. If harnesses increasingly store those outputs off-context, then future systems will need better ways to preserve not just access, but provenance. A model should know which file is canonical, which file is derived, and which one should be used to justify the final answer. This paper suggests that without that discipline, an agent can look competent on the surface while quietly drifting away from the evidence that actually matters.