A support-ticket assistant has access to a `close_ticket` tool. A user asks it to close ticket #482, and the model's response includes a request naming the `close_ticket` tool with the argument `{"ticket_id": 482}`. In a typical tool-use (function-calling) architecture, what happens next?
- The model opens a connection to the ticketing system itself and closes the ticket directly, since naming the tool already performs the action
- The calling application, not the model, executes the `close_ticket` function against the ticketing system, then sends the function's result back to the model in a new message so it can continue the conversation
- The ticketing system's own API silently intercepts the model's raw output and decides on its own whether to run the operation, without any code in the calling application being involved
- The request is discarded, because models are never permitted to reference a tool's name in their output; only a human working outside the conversation can trigger the close action
Why B? And why not the others?
Correct answer: B. The calling application, not the model, executes the `close_ticket` function against the ticketing system, then sends the function's result back to the model in a new message so it can continue the conversation
The model has no ability to execute code, open network connections, or otherwise act on external systems; it can only produce structured content describing which tool it wants used and with what arguments. Execution happens in the calling application's own code, which parses that structured request, runs the corresponding function against the real system, and returns the function's output back into the conversation as a new message so the model can use it to keep responding. The option describing the model executing the action directly is wrong because generating a tool-use request and actually performing an operation are different capabilities, and only the second requires access the model does not have. The option describing the target system's own API silently intercepting the response is wrong because nothing about a ticketing system's API watches a model's raw output; the calling application must explicitly contain the code that recognizes the request and invokes the matching function. The option claiming models are barred from naming tools is wrong because naming an available tool and its arguments is exactly the mechanism this architecture relies on; without it the calling application would have nothing to execute.
Source: Anthropic, 'Tool use with Claude' documentation (platform.claude.com/docs/en/agents-and-tools/tool-use/overview) -- describes the general client-tool execution model (model requests, application executes) shared across major vendor function-calling APIs