{ "schema_version": 1, "builder_plan": { "scenario": "An assistant chooses the wrong API or sends arguments your product cannot use.", "change": "Apply the proposed tool-selection or argument-generation change in a sandbox.", "baseline": "Your current agent with the same tool schemas and task budget.", "steps": [ "Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.", "Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.", "Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.", "Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test." ], "measure": "Correct completed actions, invalid calls, retries, latency, and cost per completed task.", "decision": "Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation." }, "builder_review": null, "arxiv_id": "2609.16268", "title": "Spurious Tool Use: When RL Agents Learn the Wrong Reason to Act", "summary": "The method replaces purely outcome-based RL reward for tool-use policies with a dense, decision-level reward in which an LLM judge scores the necessity of each tool call. It costs judge inference on every tool decision during training, adds a judge-dependence and reward-design burden, and assumes the reader is already running RL fine-tuning of a tool-using agent. It can fail if the judge itself inherits cue biases or misjudges necessity, and the paper's evidence is limited to synthetic factual-QA and math environments, so transfer to production tool stacks is unverified.", "rationale": "The failure mode is real and the mitigation is API-cheap, but it only matters if the reader actually RL-fine-tunes tool-use policies, so it warrants a small-scale validation rather than immediate adoption.", "technique": "LLM-judged tool-necessity reward for RL agents", "family": "uso_de_ferramenta", "recommendation": "testar", "published": "2026-09-14", "as_of": "2026-10-18", "editorial_status": "indexed", "source_url": "https://arxiv.org/abs/2609.16268", "independent_implementations": 0, "total_implementations": 0, "stars": 0, "citations": 0, "claims": [ { "claim_id": "claim-01", "statement": "The method replaces purely outcome-based RL reward for tool-use policies with a dense, decision-level reward in which an LLM judge scores the necessity of each tool call. It costs judge inference on every tool decision during training, adds a judge-dependence and reward-design burden, and assumes the reader is already running RL fine-tuning of a tool-using agent. It can fail if the judge itself inherits cue biases or misjudges necessity, and the paper's evidence is limited to synthetic factual-QA and math environments, so transfer to production tool stacks is unverified.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2609.16268", "source_page": null, "source_excerpt": "" }, { "claim_id": "claim-02", "statement": "RL-trained agents show spurious tool invocation rates increasing by up to 39% under counterfactual cues; a dense tool-necessity reward from an LLM judge suppresses cue-driven tool use while preserving task performance, with no multiplicative improvement factor reported.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2609.16268", "source_page": null, "source_excerpt": "" } ], "exposure_map": [ { "dimension": "quality", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compute", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "latency", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "operations", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compatibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "security", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "data_and_training", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "reproducibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" } ], "risks": [], "minimum_test": [], "open_questions": [], "independent_tests": [], "lab_reproductions": [], "report_available": false, "validation_tier": "unknown", "evidence_tier": "unknown", "infrastructure_basis": "unknown", "equations": [], "equations_status": "not_formula", "core_kind": "evaluation_protocol", "equations_fetched_at": "2026-10-12", "equations_source_url": "", "equations_source_sha256": "", "exposures_reviewed_at": "", "exposures_source_sha256": "" }