Tracing in a Foundry multi-agent support solution shows that a troubleshooting agent sometimes issues more than forty tool calls for a single ticket, repeatedly querying similar telemetry endpoints with slightly rephrased parameters. Token spend and latency spike on those tickets even when a useful answer was available after five or six calls. Which optimization best reduces waste while preserving legitimate multi-step diagnosis?
Select an answer to reveal the explanation.
Short Explanation
The correct answer is C. The waste is not that tools exist; it is that the agent never stops calling them once diminishing returns set in. Per-request and per-turn tool budgets, plus an early-stop rule when new calls do not add information, cut the runaway loops while still allowing a normal multi-step diagnosis that finishes in a handful of calls. Escalating or answering with what you already have is how you keep customers moving without burning the token budget. Stripping all tools throws away the telemetry the agent needs. Bigger final-answer token limits do not stop the tool storm. Renaming the same tools just rearranges the same addiction.
Full Explanation
Option C is correct. Token optimization for multi-agent systems includes loop controls and tool-call limits so agents cannot unbounded-query tools. Budgets plus early-stop when results are redundant preserve legitimate multi-step workflows while capping pathological cases observed in tracing.
Option A is incorrect because removing tools eliminates the diagnostic capability the agent was designed for and forces hallucinated answers about live systems rather than evidence from telemetry.
Option B is incorrect because increasing final completion length does not reduce tool-call volume; tool tokens and latency would remain high while final answers might grow even more expensive.
Option D is incorrect because aliasing identical tools increases confusion and can worsen redundant calling; it does not implement a control that stops non-productive iteration.