A tool succeeds but the agent cannot see its result: how do you repair feedback?
If a tool succeeds but the agent reports no result, check that the result enters the next request in the correct format and under the correct call ID. A successful tool log does not establish that the model received its content.
Start troubleshooting here
If a tool succeeds but the agent reports no result, check that the result enters the next request in the correct format and under the correct call ID. A successful tool log does not establish that the model received its content. Parallel calls require individual matching; do not attach several results to one ID or silently replace business errors with empty text.
Save the call and the next actual model request together
This applies when results are visible in logs but the model repeats the query or uses another call’s result. Save a short trace containing the call and the subsequent model request, then inspect what was actually transmitted. A “not found” answer does not prove that execution failed, and a function return value alone does not verify message assembly.
Match each call ID to its result message
List the call IDs generated in the current turn and match every result message, checking omissions and crossed identifiers. Check whether message cleanup removed a result or placed it in an unsupported location. With streamed tool calls, wait until arguments are complete and execution has a result before returning feedback; intermediate state is not a final result.
Return results according to the client or server tool loop
Preserve the original call according to the API’s tool-message format and append a result tied to its ID. Client tools normally require the application to execute and return results; the model service does not automatically read local logs. Preserve failure markers and reasons. For long results, explain truncation and provide a way to continue rather than returning an unusable empty shell.
Test call matching with two distinct return values
Use two read-only tools with different outputs to verify matching, check that the next turn uses each correctly, and then make one fail. Success requires results to appear in messages actually sent to the model and the next task to proceed without repeating the same request. The final answer still needs checking; legal message structure alone does not establish business success.
Client-side and server-side tool loops differ, so fields from one API cannot simply be transferred to another system. This article explains official result formats without querying private services. External result text remains untrusted reference material; repairing missing feedback must not promote that content into system instructions.
Checked sources
These sources support the concepts and methods described here. Examples and test scope are labeled separately; check the version of the tools you use.