The Tool Said "Found 20": Treat Tool Output as Evidence to Check, Not as Fact

Every Sentence the Tool Printed Was True—Why Was the Answer False?

Consider a legal or investment workflow where an agent queries an archive for a given year. The search tool runs cleanly and prints “Found 20 document(s)” above the list. The agent reports only 20 documents for that year, and a model verifier marks the answer supported. Yet the archive holds thousands of matches; the tool stopped at its default cap of 20 without printing that the list was cut.

Nothing here is adversarial. The tool computed its query correctly, and every printed sentence was true. In tool-using agents, the model—and any verifier after it—only sees the text a tool prints. When a formatter omits search limits, result caps, estimate labels, or identifier namespaces, or when a tool asserts a guarantee, two recent studies show agents treating partial text as exhaustive, verifiers approving the result^[1], and model auditors deferring to tool assurances far more than to tool alarms^[2].

Omitted Context and Asymmetric Deference: Two Ways Tool Text Misleads

The first mechanism is omission in the formatter—the code turning a tool’s internal result into the text a model reads. Jeffries (2026) audited a production research assistant he works on over a digitized archive of 17,807 historical documents queried only through tools^[1]. Each tool computed correctly, but the printed text omitted boundary facts in four families: (1) scope—an in-document search inspecting at most the first 1,000,000 characters said on a miss that it searched the full text; (2) completeness—a date search fetched at most 20 results and printed “Found 20 document(s)” while the archive held 4,772 matches for 1920 (after an earlier production incident where “Found 10” was printed when 191 matched, contributing to an agent giving a user incorrect information); (3) uncertainty—an estimated page number lacked an estimate label (caught in code review and recreated); and (4) provenance—document IDs and scan IDs were plain integers, and all but two of the 17,807 document IDs were also valid scan IDs of unrelated items, so a wrong ID returned a valid-looking wrong item^[1].

Rendering the same tool results two ways—warped versus clear wording stating scope, completeness, uncertainty, and identifier source—the author tested 40 cases (32 held out after tuning) across three model families and 5 replicates (1,200 agent runs) under frozen grading rules^[1]. Under warped wording, agents overclaimed on 62–100% of answers by family; clear wording cut overclaiming to 8% on scope, 0% on completeness, and 20% on uncertainty (+62 to +92 percentage points), with the remaining 20% on uncertainty from “estimate laundering” (hedging the labeled page while stating a derived archive page as fact); provenance stayed at 94% (+6 points; only 7/120 clear answers noted no scan ID was present)^[1].

Verifiers failed on the same warped text. On a fixed-answer measure (same false answer, only tool wording varies), verifiers accepted 30/30 false answers under warped wording and 0/30 under clear wording in scope, completeness, and uncertainty (90/90 verdicts flipped), while provenance moved from 18/30 to 14/30^[1]. On a 46-answer control (92 verdicts per cell), asking “is it supported?” with tool output only gave 96% acceptance, and adding verified facts left 61%; asking “is it correct?” with output only gave 98%, whereas adding the missing verified facts and asking “is it correct?” cut acceptance to 0%^[1]. Caveats: repaired wording combines disclosures with behavioral instructions (measuring the full text, not disclosure alone); identifier namespaces needed code types or validation; deeper fixes like removing a cap can beat disclosure; and this is one system audited by its author with an exploratory audit-prompt demonstration written with prior knowledge of the defects^[1].

The second mechanism is asymmetric deference to tool guarantees. Parasuraman and Manzey (2010) reviewed how human operators exhibit automation complacency and bias—over-relying on automated aids, missing what the aid fails to flag and following its wrong advice^[3]. Liu and Gao (2026) note that a model consuming tool output sits in that human user’s position^[2]. Using an intraprocedural C/C++ analyzer producing “proof obligations” (which guards hold on every path to a sensitive operation), they tested 916 vulnerable/patched function pairs in four disjoint sets across six evidence conditions differing only in the notes—including fabricated assurances (a missing check exists) and fabricated alarms (an added check is missing)—across eleven model configurations from four vendors and 16,572 audits with no model training^[2].

True notes barely helped (+0.02 accuracy, 95% CI −0.03 to +0.07), while false assurances cut detection of real vulnerabilities by up to 19 points relative to true notes on the same operations^[2]. False alarms never significantly lowered accuracy and were disputed far more often as models found the guard in code^[2]. An internally registered replication on seven new models found a mean asymmetry of +0.16 (95% CI +0.10 to +0.24)^[2]. Prompt instructions did not reliably help; the best study-set prompt (+0.18) failed to replicate on held-out data^[2]. Verifying each note against code in a separate call and showing refuted notes (“verify-show”) raised accuracy under false assurances by 12 points on 300 unseen pairs (p = 0.002) with no loss under true evidence, though for a second model the gain was about half and not significant, and it doubles calls^[2]. The authors conclude that an analyzer’s guarantees, not its alarms, most need checking—within the limits of isolated C/C++ functions ≤150 lines (300 held-out), by-construction evidence manipulation, and one prompt wording per condition^[2].

Engineering Mapping on rlab.works: Output Contracts, Separate Verification, and Human Gates

In our engineering view, teams should: (1) give every search tool an output contract (searched scope and limits, returned count versus true total or “unknown”, estimated versus confirmed flags, typed identifiers with namespace); (2) check the contract mechanically before text reaches the model (a fixed checker, as the author used on his 80 texts); (3) verify tool assurances in a separate step and show refuted claims; (4) give verifiers the missing facts and ask “is it correct?”; and (5) show coverage disclosures at the human gate.

Across AI Gateway and Intelligence on rlab.works, three proposed skill packs and three components map this structure:

• Permissioned search: In AI Gateway, Connect information search (S17) runs Collect permitted material → Build retrieval candidates → Prepare the summary → Check the sources (human gate) with Vector storage, embedding and rerank for filtered vector queries. Transferable to legal work (connecting document permissions and clause locations; summary output alone is not legal advice), its source check should see caps and true totals.
• Scoped reports: In Intelligence, Research and write a report (S24) runs Plan the search scope → Collect and extract material → Organize citations and findings → Review the evidence (human gate) → Format and export with Web search and research synthesis for normalized document metadata. Transferable to legal work (replacing paper sources and news topic models, reviewing legal validity and case applicability, without automating legal conclusions), its evidence review should see scope and estimate flags.
• Evidence memos: In Intelligence, Keep an evidence memo (S25) runs Collect source evidence → Resolve entities and relations → Compare claims and challenges → Review and save the memo (human gate) with Investment thesis evidence and verdict tracking (grading sources, separating support, challenge, and complication, with a human-overridable verdict). Proven in finance (supporting research, not trade instructions; entity and timing definitions still need alignment) and transferable to legal work, Compare claims and challenges is the step to verify tool guarantees before Review and save the memo (human gate).

All three packs are proposed, unintegrated compositions on synthetic data; the three components have “working” static-inspection maturity, and none implements the output contract, typed identifiers, or separate verification calls described here—a requirement we draw from the papers. Nothing here is legal or security-audit advice.

Three Pre-Deployment Checks for Tool-Using Agents

• Enforce output contracts and typed identifiers: Print searched limits, returned count versus true total, and estimated versus confirmed flags, and enforce identifier namespaces via code types.
• Verify tool guarantees separately and ask “is it correct?”: Verify tool assurances in a separate call, show refuted claims, and give verifiers boundary facts while asking if the answer is correct.
• Show coverage disclosures at the human gate: Display searched limits, true totals, and refuted assurances at each human-gate step.