A water-utility agent calls a tool and must continue the Claude conversation with that result. Where do tool results go?
Select an answer to reveal the explanation.
Short Explanation
Tool answers aren't souvenirs for the server drawer—they have to come back to the chat. Put those results into the messages array so Claude's next turn can actually use them.
Full Explanation
When a water-utility agent calls a tool, the Claude conversation continues only if tool results are returned into the Messages API turn structure. Sending tool results back into the messages array for the next Claude turn is correct because tool-result round-tripping is how the model observes external facts—meter readings, account statuses, outage tickets—before producing the next assistant message. Conceptually this closes the tool loop: the tool executes outside the model, then the result re-enters the conversational messages so deliberation stays grounded in real utility systems.
Merging tool results into the revised system instructions for the next Claude conversation turn fails by concept: system instructions are meant to hold stable policy and role framing, not per-call telemetry, and stuffing a one-off meter reading there conflates a transient fact with the durable configuration the model should treat as fixed. Returning tool results directly to the customer as the final response fails the round-trip: it skips Claude's next turn entirely, so the model never gets to reason over, validate, or explain the reading, and the conversation loses the chance to catch an obviously bad value before it reaches the resident. Inserting tool results into a new assistant message for the next Claude turn fails by concept: the assistant role represents the model's own output, not externally supplied tool data, so placing telemetry there misrepresents who said what and breaks the API's expected role semantics for tool results.
Exam caveat: Messages API tool-use items hinge on returning tool results into the messages array for the subsequent turn—not system instructions, a skipped turn, or a mislabeled assistant message. Keep water-utility meter/tool framing. Operational check: after each tool invocation, append the tool result message to the messages array, continue the Claude turn, assert the assistant cites the returned reading, and alert if tool outputs are logged but omitted from the API conversation.