An airline gate agent answers slowly. Traces show the gate-assignment tool timing out, and the model returns promptly once that tool responds. Leadership wants the model retuned. What should the architect change?
Select an answer to reveal the explanation.
Short Explanation
Retraining the pilot does nothing when the radio is the piece that drops the call. You repair the gate tool the traces show timing out, and you leave the model alone. A retune teaches the model to guess through a tool failure.
Full Explanation
Evaluation and traces are used to find the failing step, and then that step is what gets tuned. Here the traces already separate the steps: the gate-assignment tool times out, and the model responds as soon as the tool returns, so the repair belongs on the tool. Retuning the model on past gate chats would teach it to invent a gate during the timeout, which hides a broken dependency instead of restoring it. Lengthening the system prompt until the model is told to stop waiting does not make the tool return, and an instruction is not a timeout or a retry policy on the call. Dropping the traces for a passenger survey throws away the evidence that names the tool, and a survey score can fall for reasons that have nothing to do with gate assignment. Exam caveat: a slow agent is not automatically a model problem. The trace has to be read before any retune is funded. Operational check: replay one gate question in a test run, confirm the tool returns, confirm the model deployment was not replaced, and write the tool duration beside the model duration for that same run.