A Tool Loop Is Controlled Delegation
Claude may propose an action. Your application validates the request, grants the capability, observes the result, and decides whether the loop continues. Implement the complete tooluse and toolresult protocol loop. Design focused tool contracts and choose their execution boundary. Separate model selection of a tool from deterministic authorization. Compare a hand-written loop, SDK Tool Runner, and managed agents. Return failures as typed results and consume actionable runtime events. Bound autonomy and choose a fixed workflow when the path is known. A billing assistant receives "Refund the duplicate charge." Claude requests issuerefund. The application executes it. The response connection drops before the final text arrives. The application retries the entire turn, Claude requests the tool again, and the customer receives two refunds. The problem is not that the model used a tool. The application confused language generation with transaction control. A reliable tool loop has two contracts: The model can propose a named capability with structured arguments. Deterministic application code decides whether, how, and at most how many times that capability executes. Tool use gives Claude reach. It does not give Claude authority. Client tools are declared in the request. Each declaration gives the model a name, a description, and a JSON Schema input contract. Claude may return: Your client preserves that entire assistant content, validates and runs the tool, then…
A Tool Loop Is Controlled Delegation: Claude may propose an action. Your application validates the request, grants the capability, observes the result, and…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.