AI Agents & Tool Use

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

Why C? And why not the others?

Correct answer: C. It grounds each later reasoning step in real information retrieved from the environment, reducing the hallucination and error propagation that can accumulate when a model reasons in one unchecked pass

This Thought/Action/Observation pattern is the ReAct approach: interleaving reasoning traces with actions lets the model's later reasoning steps update on real observations pulled from an external environment (such as a knowledge-base query), rather than continuing to build on an earlier reasoning step that may already have drifted from the facts. Yao et al. showed this measurably reduces the hallucination and error propagation that plain chain-of-thought reasoning is prone to on multi-step question-answering and fact-verification tasks, because a wrong intermediate claim gets corrected by an observation instead of being compounded further. The option claiming complete freedom from factual errors overstates the benefit -- retrieved sources can themselves be wrong or misread, so grounding reduces but does not eliminate error. The option describing reasoning as removed entirely misunderstands the pattern, since the Thought step is reasoning and remains essential to deciding what to look up next. The option about a permanently larger context window confuses a prompting pattern with a model's architecture; interleaving Thought/Action/Observation does not change how many tokens the underlying model can attend to.

Source: Yao et al., 'ReAct: Synergizing Reasoning and Acting in Language Models' (2022), arXiv:2210.03629

Why D? And why not the others?

Correct answer: D. An explicit termination condition -- such as a cap on the number of iterations, or a check for the model emitting a recognizable 'done' / final-answer signal -- so the loop halts instead of continuing indefinitely

Agent loops that repeatedly observe, decide, and act need an explicit stopping rule built into the loop itself; frameworks such as AutoGen make this concrete with settings like a maximum number of consecutive automatic replies and a check for a recognizable termination message, either of which ends the loop even if the underlying task was never actually solved. Without some such condition, an agent that keeps generating plausible-looking next actions has no built-in reason to stop, and will keep looping even when it is only repeating a failed attempt. The option pointing to too few tools is wrong because the number of available tools has nothing to do with whether the loop recognizes it should stop -- even a single-tool agent needs a stopping rule. The option pointing to a small context window is wrong because forgetting earlier attempts might make an agent repeat itself, but expanding the window is not what supplies a stopping condition, and plenty of agents loop indefinitely with plenty of room left in context. The option invoking retrieval-augmented generation is wrong because RAG is about pulling in external knowledge to ground answers, and has no special role in judging whether a task is complete.

Source: Wu et al., 'AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Framework' (2023), arXiv:2308.08155 -- describes explicit conversation termination conditions (e.g. a cap on consecutive automatic replies, and a check for a termination message) required to stop an agent loop

Why A? And why not the others?

Correct answer: A. It contains the blast radius of any command the model generates -- whether flawed, unexpected, or actively malicious (for example, from data the model was fed) -- so it cannot reach production systems, other users' data, or the internet at large

Because the code being run was generated by a model that can be wrong, manipulated by injected instructions in the data it processes, or simply buggy, isolating execution in a sandboxed container with restricted resources and no path to production systems limits how much damage any single generated command can do, regardless of why it went wrong. This is exactly why dedicated code-execution tools for agents describe themselves as running Python and bash in a sandboxed container rather than on the host directly. The option claiming models cannot produce valid code outside a container is wrong -- a model can generate syntactically correct code whether or not that code is ever executed, and containers do not affect what a model is capable of writing. The option claiming a sandbox rewrites unsafe commands into safe ones is wrong because isolation does not modify the code; it only limits what the code, however written, is able to reach and affect. The option about raw execution speed is wrong because sandboxing typically adds overhead rather than removing it; the point of the isolation is containment of risk, not performance.

Source: Anthropic, 'Tool use with Claude' documentation (platform.claude.com/docs/en/agents-and-tools/tool-use/overview), 'Code execution tool' entry: 'Run Python and bash code in a sandboxed container to analyze data and generate files'

Why B? And why not the others?

Correct answer: B. It scopes what the agent can be asked to do at the request-generation level: the model can only choose among the specific named, schema-defined tools it has been given, so issuing a refund or changing settings was never exposed as an option for it to request in the first place

Exposing only a fixed set of named tools, each with its own description and input schema, is how an agent's available actions are scoped at the request level -- the model chooses from whatever list of tools it was given, so an operation like issuing a refund, which was never defined or described to it, was never presented as something it could ask for. This is a design-time restriction on what gets offered, not a guarantee about what the model will output. The option claiming the model literally cannot generate text describing an unlisted operation is wrong, because a model can still produce free-form text or even attempt a malformed request referencing something outside the defined set; scoping the tool list reduces the chance of this but the calling application still has to check what comes back. The option claiming the calling application no longer needs to verify incoming requests is wrong for the same reason -- a smaller tool list lowers risk but does not remove the need to validate that a request actually matches a defined tool before running anything. The option claiming the tool list has no effect on what the agent can request is wrong because restricting the exposed tools is precisely what constrains the space of actions the model is prompted to choose among.

Source: Anthropic, 'Tool use with Claude' documentation (platform.claude.com/docs/en/agents-and-tools/tool-use/overview), 'Define tools' entry: 'Specify tool schemas, write descriptions, and control when Claude calls your tools'

Why C? And why not the others?

Correct answer: C. Because issuing a refund is a real, hard-to-reverse action with financial consequences, so requiring explicit human confirmation before that specific step limits the damage an incorrect or manipulated agent decision can cause, while lower-stakes, easily reversible steps can proceed without waiting on a person

Human-in-the-loop approval gates are placed at the specific steps where a mistake would be costly and hard to undo, which is exactly the distinction drawn between drafting a refund and actually issuing one: drafting can be revised or discarded with no real-world effect, but issuing moves real money and may be difficult or impossible to fully claw back, so it is that step, not the earlier read-only or draft steps, that gets a pause for explicit confirmation. Frameworks that support this kind of workflow let a human's input be required only for certain messages (for instance, ones that look like a completed, ready-to-execute action) rather than for every step the agent takes. The option claiming models are barred from drafting a refund amount at all is wrong, since drafting is explicitly the ungated step in this design. The option treating inventory checks and refund issuance as technically identical is wrong because they differ exactly on the dimension that matters here -- reversibility and financial consequence -- which is why only one of them is gated. The option claiming the payment tool cannot technically be called by an agent is wrong; the whole point of the design is that it can be called, which is precisely why an approval step is placed in front of it.

Source: Wu et al., 'AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Framework' (2023), arXiv:2308.08155 -- describes configuring human input to be requested at specific points in an agent's conversation rather than at every turn

Why D? And why not the others?

Correct answer: D. It avoids repeatedly re-feeding the full growing transcript of prior reasoning and results back into the expensive reasoning model at every single step, cutting redundant token consumption while remaining robust even if an individual lookup tool fails

Decoupling planning from execution -- as in the ReWOO approach's Planner, Worker, and Solver split -- lets the reasoning model produce a full blueprint of what lookups are needed just once, hand the actual tool calls to a separate lightweight component, and only bring the reasoning model back in to compose the final answer, instead of re-feeding the whole accumulating transcript of past thoughts and observations into the expensive reasoning model after every single lookup. Xu et al. report this cuts token consumption substantially compared to designs that interleave reasoning and tool calls at every step, while also holding up better when a tool call fails, since the plan does not have to be rebuilt from scratch. The option calling this the only way to use more than one tool is wrong, since interleaved reasoning-and-acting designs also chain multiple tool calls; the difference here is efficiency and structure, not tool count. The option claiming guaranteed higher accuracy on every task is wrong, since decoupling planning from execution can lose the benefit of adjusting the plan mid-task when an early result changes what is actually needed. The option claiming lookups can never fail or return something unusable is wrong -- the design is reported to be more robust to tool failure, not immune to it.

Source: Xu et al., 'ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models' (2023), arXiv:2305.18323

Why A? And why not the others?

Correct answer: A. That the model's own context window cannot hold the agent's entire history, so relevant past experience has to live outside the prompt and be selectively pulled back in only when needed, rather than resent in full every time

As an agent's history of observations and actions grows across many steps, that full history quickly exceeds what a single prompt can hold, and re-sending an ever-growing transcript on every turn would also be wasteful even where it does fit; the memory-stream/reflection/retrieval architecture Park et al. describe addresses this by storing the raw log and higher-level reflections outside the prompt entirely and pulling back only the entries judged relevant to the current situation, rather than the whole history. The option equating this with retrieval-augmented generation over documents is wrong -- RAG typically retrieves external factual/reference content, whereas this design retrieves the agent's own past experience and self-generated reflections, which is a related but distinct use of retrieval. The option claiming models retain nothing at all between turns within a single ongoing conversation is wrong; within the bounds of one context window a model does see prior turns directly, and the memory system exists specifically because that direct visibility does not scale indefinitely. The option claiming reflections gate every action regardless of simplicity is wrong -- reflections are generated periodically from accumulated observations, not required as a precondition for each individual action.

Source: Park et al., 'Generative Agents: Interactive Simulacra of Human Behavior' (2023), arXiv:2304.03442

Why B? And why not the others?

Correct answer: B. The overall task is decomposed across multiple specialized agents that communicate with each other through a structured conversation, so different roles (planning, generating, critiquing) are handled by different agents rather than one agent doing everything internally

The defining feature of a multi-agent design like this is splitting a task across separate, specialized conversable agents -- one for planning, one for generating a solution, one for reviewing it -- that pass messages to each other rather than a single agent handling every role internally in one uninterrupted stream of reasoning; frameworks such as AutoGen build agents specifically to converse with each other in this way, mixing roles and even combinations of models, human input, and tools per agent. The option restricting tool use to only one agent in the group is wrong -- nothing about a multi-agent design requires that only one participant may call tools, and different agents can each have their own tools. The option requiring every agent to share the exact same system prompt is wrong and actually contradicts the point of specialization -- giving each agent a distinct role-specific prompt is what lets the planner, coder, and reviewer behave differently from one another. The option claiming no termination condition is needed is wrong; a multi-agent conversation still needs an explicit stopping point (such as the reviewer signalling approval or a reply-count limit), or it risks looping the same way a single-agent loop can.

Source: Wu et al., 'AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Framework' (2023), arXiv:2308.08155

Why C? And why not the others?

Correct answer: C. As untrusted data to be read and summarized, not as instructions to be obeyed -- the fetched content should never be allowed to override the user's original request or trigger an unrelated action such as emailing credentials, regardless of what it appears to instruct

Content that arrives through a tool -- a fetched webpage, a search result, a document -- is data the agent was asked to process, not a second source of instructions with the same authority as the user who set up the task; treating anything appearing in context as an obeyable command is exactly the vulnerability that indirect prompt injection exploits, where an attacker plants instruction-like text inside content they know an LLM-integrated application will retrieve and feed to the model. The correct handling is to read and summarize the fetched text while refusing to let it redirect the agent into an unrelated action, such as exfiltrating credentials, that the actual user never requested. The option treating fetched content as a new authoritative instruction is wrong because that is precisely the failure mode being described, not the defense against it. The option saying fetched content can simply be ignored is wrong because the whole point of the tool is that its content is needed to complete the user's original request (summarizing the page); ignoring it defeats the task. The option treating any mentioned email address as an automatic trigger to send a message is wrong because it would let the mere appearance of text inside untrusted content directly cause a real-world action, which is the same failure mode restated rather than a solution to it.

Source: Greshake et al., 'Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection' (2023), arXiv:2302.12173

Why D? And why not the others?

Correct answer: D. Reject the request without executing anything, since it does not match any tool name or argument schema the application actually defined, and return an error observation to the model so it can retry with a request that matches an available tool

Because a model's tool-use request is generated text and not a guaranteed-correct reference to what was actually defined, it can name a tool that does not exist or supply arguments that do not match the declared schema -- this is a real failure mode, which is exactly why some tool-use implementations offer a strict mode specifically to make requests conform to the declared schema, implying that conformance is not otherwise guaranteed. The safe response to an unrecognized tool name or a schema mismatch is for the calling application to refuse to execute anything against real systems and instead return an error back to the model as an observation, letting the model correct itself and retry with a valid request. The option of executing against the closest-matching real tool is wrong because guessing at a destructive or unintended action (here, one that also deletes drafts) from a malformed request is far riskier than simply refusing and asking the model to retry. The option of silently renaming fields to match the schema is wrong for the same reason -- silently reinterpreting a request assumes an intent that was never actually validated. The option of extending the real tool's behavior at runtime to match the hallucinated request is wrong because it lets an unverified, possibly hallucinated capability (deleting drafts) actually happen, which is the opposite of containing the mismatch safely.

Source: Anthropic, 'Tool use with Claude' documentation (platform.claude.com/docs/en/agents-and-tools/tool-use/overview) -- 'Handle tool calls' entry: 'Parse tool_use blocks, format tool_result responses, and handle errors'; and 'Strict tool use' feature description noting schema conformance is not otherwise guaranteed

Why A? And why not the others?

Correct answer: A. As a new message containing a content block whose type marks it as the tool's result and whose identifier matches the unique identifier from Claude's original tool-call block, so Claude can associate the result with the specific request it made

In Claude's tool-use API, when Claude decides to call a defined tool it returns a content block marking the request along with a unique identifier for that call; the application executes the corresponding function and then sends the result back inside a new message as a content block explicitly marked as the tool's result, carrying that same identifier so Claude can match the result to the specific call it made, even if multiple tool calls were requested at once. The option describing an unstructured text append with no identifier is wrong because Claude's API relies on that explicit identifier match, not on message ordering alone, to associate a result with its originating request. The option describing a modification to the original tool-definition request is wrong because the result is sent as part of the ongoing conversation's messages in a follow-up request, not as an edit to the tool definitions themselves, which stay fixed. The option claiming tool results must appear as a system-level instruction outside the conversation is wrong because the documented round trip places the tool's result inside the message list alongside the user's and Claude's own turns, not in a separate system-level channel.

Source: Anthropic, 'Tool use with Claude' documentation (platform.claude.com/docs/en/agents-and-tools/tool-use/overview): 'the response carries a tool_use block, your code runs the lookup, and a second request sends the result back in a tool_result block'