An agent built in Microsoft Foundry occasionally calls the refund-processing tool when a customer only asked a shipping-status question. The team cannot reproduce the issue reliably by re-reading the final chat transcript alone. What should they use to find out why the agent chose the wrong tool on those specific runs?

The correct approach is to open the run traces in Foundry to inspect the agent's intermediate reasoning and tool-selection steps for the failed conversations. Foundry's tracing captures the intermediate steps an agent takes between receiving a message and producing a final answer, including which tools it considered and selected and the reasoning that led there. Reviewing traces for the specific failed runs is the direct way to see why the refund-processing tool was chosen instead of a shipping-status lookup, especially when the final transcript alone does not reveal the cause. Increasing the agent's response length limit is incorrect because a longer response limit changes how much text the agent can output, not what internal decision led it to pick a tool, so it would not reveal the cause of the misrouting. Switching the agent to a model with a larger context window is incorrect because a larger context window lets the model consider more input tokens at once, which does not diagnose a tool-selection error and may not be related to the failure at all. Asking the agent, in the next conversation, to explain why it made that earlier mistake is incorrect because asking the agent after the fact to explain a past decision produces a generated, after-the-fact justification rather than an accurate account of what actually happened during that run; the agent has no reliable memory of its own internal reasoning process to report back.