Task 1.1: Design and implement agentic loops for autonomous task execution

• AKeep running tools and sending results while stop_reason is "tool_use", and return the reply once it is "end_turn"

  Correct

  stop_reason is the API's structured signal: "tool_use" means Claude is waiting for tool results, "end_turn" means it finished its response, however many lookups the case needed.

• BTell Claude to finish every resolved case with a marker such as [DONE] and stop when the marker appears in the text

  Incorrect

  Parsing natural-language markers is brittle: Claude may write the marker while still planning a call, or leave it out, while the API already reports the reason it stopped.

• CAllow a fixed number of round trips sized to the longest case seen in testing, then return the latest text

  Incorrect

  A count chosen in advance cuts off unusual cases that need more steps and says nothing about whether Claude has actually finished.

• DEnd the loop as soon as a response contains a text block, since that text is the answer the customer is waiting to see

  Incorrect

  A response can hold text and tool_use blocks together, for example a sentence of reasoning before a lookup, so text alone does not mean Claude is done.

Drive the loop from stop_reason. Continue while Claude asks for tools ("tool_use"), feeding each result back, and stop when it ends its turn ("end_turn"). Text blocks, fixed counts and invented markers are proxies for a signal the API already returns.

• ARaise max_tokens on each request so that Claude has enough room to keep the earlier lookups and the customer's goal in mind

  Incorrect

  max_tokens limits the length of the response Claude writes; it has no effect on what Claude can see from earlier turns.

• BTurn on prompt caching for the latest tool result so that Claude can recall it in the following requests

  Incorrect

  Caching reuses a prefix that you send again; it lowers cost and latency but does not let Claude see content that a request leaves out.

• CSend the full conversation each time, including the earlier lookups and the customer's first messages

  Correct

  The Messages API is stateless: Claude sees only what each request contains, so the history, earlier tool calls and their results included, has to be sent every time.

• DCopy each new tool result into the system prompt in place of the previous one, so the latest data is always visible

  Incorrect

  Overwriting one slot still throws away the earlier results and the customer's messages, so Claude still cannot see what it already checked.

Each request has to carry the conversation so far. Claude reasons about the next action from the tool results already in context, so dropping earlier turns makes it repeat work and forget the customer's goal.

• ASend each result in its own user message, one request per result, in the order the calls appeared

  Incorrect

  Splitting the results across separate user messages is the documented way to teach Claude to stop calling tools in parallel.

• BNumber the results in a text block and let Claude match them to the calls by position

  Incorrect

  Results are matched to calls by tool_use_id inside tool_result blocks, not by order in free text.

• CLeave out the results of searches that found nothing so that empty output does not distract Claude

  Incorrect

  Every tool_use block must be answered; an empty result is still a result, and Claude needs to know the search ran and found nothing.

• DPut the tool_result blocks at the start of that user message and any extra text after them

  Correct

  In a user message that answers tool calls, the tool_result blocks must come first; text placed before them is rejected.

• EReturn all three results in one user message, each tool_result carrying the tool_use_id of the call it answers

  Correct

  Every tool_use needs a matching tool_result, and the results of parallel calls belong together in a single user message.

Answer parallel calls with one user message whose content starts with one tool_result per tool_use_id. Separate messages or missing results break the pairing the API expects and discourage parallel tool use.

• AAppend the response as it is to the messages and send another request so that Claude can continue

  Correct

  pause_turn means the server-side loop hit its iteration limit; sending the paused response back lets Claude finish the turn.

• BRun the search with your own search API and return a tool_result for the server_tool_use block

  Incorrect

  The API runs server tools itself; the documented continuation is to send the paused response back, not to execute the search.

• CRetry the original request from the start with a higher max_tokens

  Incorrect

  pause_turn is an iteration limit, not a token limit, and restarting throws away the work already done.

• DAppend the paused response followed by a user message saying "please continue"

  Incorrect

  With a server tool call still unresolved, a user text turn is not the continuation the API expects; the request fails with an error naming the unresolved server tool.

Handle pause_turn in any loop that uses server tools: the server-side sampling loop reached its iteration limit, so add the assistant response to the messages as it is and make another request to let Claude continue. It is never returned while a client tool_use waits on you.

• Amax_tokens is too low, so the response is cut off before any content appears

  Incorrect

  A max_tokens cutoff reports stop_reason "max_tokens", not "end_turn".

• BClaude is refusing the request, which always appears as an empty end_turn response

  Incorrect

  Refusals have their own stop_reason, "refusal".

• CThe tool results are too long

  Incorrect

  Length is not the documented cause; the extra text pattern is.

• DThe text after each tool result teaches Claude to end its turn

  Correct

  Adding text immediately after tool results is a documented cause of empty end_turn responses.

Empty end_turn responses often follow a pattern of text blocks inserted right after tool results. Send tool results on their own, and if a response is empty, continue with a new user message rather than resending it unchanged.

• ARun the search itself with your own search API and return a tool_result

  Incorrect

  That is the client-tool pattern; server tools are executed by the API.

• BEnd the loop, since a server tool result means Claude has finished

  Incorrect

  Whether Claude is finished still comes from stop_reason.

• CNothing to execute; the API ran it, and you send no tool_result for it

  Correct

  Server tools run on Anthropic's side, and their results already sit in the response.

• DReturn an empty tool_result with the server tool's id so that the loop can continue

  Incorrect

  Server tool calls do not take a tool_result from your code.

Client tools are executed by your code and answered with tool_result blocks; server tools such as web search are executed by the API, whose result blocks arrive in the response.

• AIt includes built-in tools such as Read, Edit, Bash, Glob and Grep

  Correct

  The same built-in tools that power Claude Code are available.

• BIt requires your code to append every tool_result to the history by hand

  Incorrect

  Result handling is part of the loop the SDK runs for you.

• CIt cannot apply permission rules, so every tool runs unchecked

  Incorrect

  Permission modes, allow and deny rules, and hooks all apply.

• DIt ends after the first tool call so that your code decides each next step

  Incorrect

  The loop continues on its own until a response has no tool calls.

• EIt runs the agent loop itself, executing tools and feeding results back until Claude stops calling tools

  Correct

  The SDK embeds Claude Code's loop, so your code consumes messages rather than driving each turn.

The Agent SDK runs the agentic loop with Claude Code's built-in tools, permissions and hooks; you handle the stream of messages and the final result.

• AAs a tool failure, returning a tool_result with is_error set

  Incorrect

  No tool was called; there is nothing to return a result for.

• BAs an HTTP error, catching it in the client's exception handler

  Incorrect

  Refusals come back as successful HTTP responses, not exceptions.

• CAs a refusal with its own handling, such as a fallback model

  Correct

  A refusal is a normal 200 response with its own stop_reason and guidance for handling it.

• DAs the final answer, since there are no tool calls in the response

  Incorrect

  That would show a refusal message as if it were the resolution.

Always branch on stop_reason. "refusal" means Claude declined; read stop_details and handle it explicitly, for example with a fallback, rather than treating it as an answer.