AI / LLM Integration
Tool calls: multiple-choice review
Crux Multiple-choice synthesis across the tool-calls unit — the round-trip loop, schema validation as a trust boundary, the iteration guard, parallel calls, and tool_choice.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. None is a definition to recite — each mirrors a decision you make wiring a real agent loop against real, sometimes-mutating tools.
Goal
Confirm you can connect the round-trip contract, the validation trust boundary, the runaway guard, parallelism, and tool_choice — the synthesis the lesson built toward.
Quiz
Completed
A user task needs four tool calls, all at distinct steps. Roughly how many model invocations does the loop make, and why does it matter for cost?
Heads-up The model never executes client tools; it only emits a tool_use request. Each execution requires your code to run it and send a brand-new request back with the results.
Heads-up Every request re-sends the full accumulating history plus the tools block, so input tokens grow each step. That compounding is exactly why prompt caching the static tools block matters.
Heads-up There is no separate plan/execute split. The loop iterates one model call per round of tool_use until stop_reason becomes end_turn.
Quiz
Completed
The model returns a tool_use for cancel_order with id 'ord_9f3c', an id that never appeared in the conversation. What is the senior move?
Heads-up The input_schema guides the model but does not bind it; models routinely emit plausible-but-fabricated ids. Treating tool arguments as trusted is exactly how a hallucinated id mutates the wrong record.
Heads-up Throwing out of the loop ends the turn and gives the model no chance to recover. Worse, a bare catch around an unvalidated mutation can still fire the bad request before it throws. Validate first; return the error as a tool_result.
Heads-up A fabricated argument is wrong, not transient. Blind retries just burn tokens and can repeat a destructive action. The fix is validation plus an error returned to the model, not retries.
Quiz
Completed
An agent in production occasionally racks up huge bills on single turns. Logs show it calling lookup_order, getting an error, and calling it again with identical arguments — over and over. What is the root cause and the fix?
Heads-up The call is not transiently failing — the model repeats identical arguments and gets the identical deterministic error. Backoff slows the burn but never terminates it; the missing piece is an iteration cap and repeat-detection.
Heads-up max_tokens limits the output length of one response, not the number of loop iterations. The runaway is the loop re-invoking the model, which no output-token setting bounds.
Heads-up Fixing the tool removes this trigger, but any future error — a different tool, a bad argument — re-creates the runaway. The loop guard is a structural defense you need regardless of which tool misbehaves.
Quiz
Completed
You have two chains. Chain A: get_weather(NYC) and get_weather(SF). Chain B: find_user(email) then cancel_user_order(userId). Which can the model parallelize, and why?
Heads-up The model cannot fill cancel_user_order's userId until it has seen find_user's result, so the dependent call cannot be issued in the same turn. The data dependency, not the runtime, blocks parallelism here.
Heads-up Modern models do emit multiple tool_use blocks in a single response for independent calls; that is the parallel-tool-use latency win. You can opt out with disable_parallel_tool_use, but it is not the default.
Heads-up Parallelism is about data independence, not mutation semantics. Chain B is the serial one precisely because its second call depends on the first's output; Chain A's reads are independent and parallelizable.
Quiz
Completed
You are building a classifier that must always return one of a fixed set of categories as structured JSON — prose is never an acceptable answer. Which tool_choice setting fits, and why not the others?
Heads-up auto lets the model answer in prose instead of calling the tool, which breaks the contract that the answer is always structured JSON. auto is for agents where prose is sometimes the right reply.
Heads-up any forces a tool call but lets the model choose among all tools; with one tool that is nearly equivalent, but the moment you add a second tool the model could pick the wrong one. Forcing the named tool is the precise control for guaranteed-shape extraction.
Heads-up none forbids all tools, so you would get free-form prose and have to parse it — exactly the fragile path tool-forcing exists to replace. none is for forcing a text summary after results are already in.
Quiz
Completed
A 10-tool agent runs a 6-step task and the latency and cost are far higher than expected even though each tool is fast. What is the dominant overhead, and the standard mitigation?
Heads-up The premise says each tool is fast. The overhead is the per-request token tax of re-sending the full schema array every round, not tool execution time.
Heads-up A smaller model may be cheaper per token but does not address re-sending 5,000 tokens of schema six times. Caching the static tools block targets the actual overhead and keeps model quality.
Heads-up Oversized toolsets can hurt selection, but the question's overhead is the re-sent token cost of the schema each round. Prompt caching addresses that directly without dropping needed tools.
Recap
The through-line is one contract: the model only requests a tool, your code executes it, and the loop re-invokes the model after every result — so cost compounds, schemas are re-sent each round (cache them), and an unguarded loop runs away. Validation is a trust boundary: schema-validate, then authorize and existence-check, then execute, returning errors as tool_result so the model self-corrects. Parallelism only helps independent calls; tool_choice (auto/any/tool/none) controls whether and which tool fires.