A logistics agent drafts delay notices. Traces show the model returns quickly, while the carrier-status tool accounts for most of the wait on each run. What should the architect change first?
Select an answer to reveal the explanation.
Short Explanation
You do not buy a faster engine when the truck is sitting at a closed gate. The trace already shows the model returns quickly and the carrier-status tool takes the time, so you work on that tool. A new model leaves the gate where it is.
Full Explanation
A trace that splits time by step tells you which step to tune. Here the model returns quickly and the carrier-status tool accounts for most of the wait, so the first change is in that tool call: its latency, its failures, or how often the agent waits on it. Buying a faster model for that pattern leaves the wait in place and can hide it behind a new deployment name. A faster model deployment spends money on the step the trace has already cleared. A longer model timeout assigns the tool's wait to the draft step and does not make the carrier status return sooner. A shorter system prompt trims an instruction that the trace has not identified as the slow part. Retries on the carrier call belong in the same diagnosis, since a retry storm is still the tool and not the model. Exam caveat: tool time can include the network and the carrier system, not only the agent's connector configuration. The trace still says the wait is outside the model. Operational check: open a slow run, confirm the carrier-status span dominates, and record a change to that call before any model deployment is swapped.