Agentic loops: CCAR-F task statement 1.1

CCAR-F · Agentic Architecture & Orchestration (27% of the exam)

Task statement 1.1 sits in Agentic Architecture & Orchestration, the largest CCAR-F domain at 27% of the exam. It tests whether you can build the loop that lets Claude call tools, read the results and decide what to do next until the task is finished.

What the official guide covers

The Claude Certified Architect Foundations exam guide (version 1.0, effective July 2026) lists this under task statement 1.1, "Design and implement agentic loops for autonomous task execution":

Knowledge of	Skills in
The loop lifecycle: send a request, inspect `stop_reason` ("tool_use" or "end_turn"), run the requested tools, return the results	Continuing the loop when `stop_reason` is "tool_use" and stopping when it is "end_turn"
How tool results are added to the conversation history so Claude can reason about the next step	Adding tool results to the conversation between iterations
The difference between model-driven decisions and fixed decision trees or tool sequences	Avoiding anti-patterns: parsing Claude's text to decide when to stop, using an iteration cap as the main stop rule, treating any text reply as "done"

How the loop works

Send the user's request, the system prompt and the tool definitions to the Messages API.
Read stop_reason on the response.
If it is "tool_use", the response contains one or more tool_use blocks. Run each tool in your own code.
Append Claude's response to the conversation, then add one user message that holds a tool_result block for every tool_use block. Each result carries the matching tool_use_id.
Send the updated conversation back and repeat from step 2.
If it is "end_turn", Claude has finished. Use the response.

while True:
    response = client.messages.create(model=MODEL, max_tokens=4096, tools=TOOLS, messages=messages)
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason == "end_turn":
        break                                   # the task is finished
    if response.stop_reason == "pause_turn":
        continue                                # server tool paused: send the turn back as it is
    if response.stop_reason != "tool_use":      # max_tokens, refusal, stop_sequence, context full
        raise RuntimeError(f"Loop stopped early: {response.stop_reason}")  # handle per the table below
    results = [run_tool(block) for block in response.content if block.type == "tool_use"]
    messages.append({"role": "user", "content": results})   # all tool_result blocks, one message

The loop exits normally only on end_turn. Every other stop reason gets its own handling, set out in the table below. Claude chooses which tool to call next from what it has learned so far. Your code decides nothing about the order. That is the model-driven decision-making the guide refers to.

Rules that decide exam answers

Stop on stop_reason, not on text. A reply such as "I'll check the order now" is not a stop signal. Only "end_turn" means the task is finished.
Return every result in one message. When Claude calls several tools in one response, send all the tool_result blocks together in the next user message. Separate messages break the format and make Claude call tools one at a time.
Results come first. In the user message, tool_result blocks must come before any text. Nothing may sit between the assistant's tool call and the user's results.
Report failures as results. If a tool fails, return a tool_result with is_error: true and a clear message. Claude can then correct the input and try again.
An iteration cap is a safety net, not the stop rule. Keep a cap to catch runaway loops, but the normal exit is "end_turn".

What to do with each stop_reason

`stop_reason`	What it means	What the loop should do
`tool_use`	Claude is calling one or more tools	Run them, return every result, continue
`end_turn`	Claude has finished	Use the response and exit
`max_tokens`	The reply hit your token limit	Raise the limit or continue; a cut-off tool call must be retried with a higher limit
`pause_turn`	A server-tool loop reached its iteration limit	Send the response back as it is to continue
`refusal`	Claude declined to respond	Read `stop_details`; do not treat it as success
`stop_sequence`	One of your stop sequences fired	Check which one and handle it
`model_context_window_exceeded`	The conversation filled the model's context window	Use what was returned, then trim or summarise the history before continuing

Agent loop or fixed workflow?

The exam also tests when not to use an agentic loop. Anthropic separates workflows, where your code fixes the order of steps, from agents, where Claude decides the next step from what it has learned.

Situation	Better choice	Why
The steps are known and always run in the same order	Fixed workflow	Cheaper, faster and easier to test
The next step depends on what a tool returns	Agentic loop	Claude chooses the next tool from the results
A step must happen every time, such as a compliance check	Workflow step or hook, not a prompt instruction	Code guarantees it; Claude's choice does not

Where it appears in the exam

Domain 1 is a primary domain in three of the six exam scenarios: Customer Support Resolution Agent, Multi-Agent Research System and Developer Productivity with Claude. Four scenarios are drawn for each exam, so expect loop questions in most sittings.

Two sample questions

These are original Timo practice questions. They are not official exam questions.

Question 1

A support agent built on the Messages API sometimes stops before it has looked up the customer's order. The loop exits when Claude's reply contains no question mark. In the failed cases, Claude's last reply was "I'll look up your order now." What should the team change?

A. Raise the iteration cap from 5 to 20.B. Continue the loop while stop_reason is "tool_use" and exit when it is "end_turn".C. Add "always finish with a question" to the system prompt.D. Exit the loop when the reply contains the word "done".

Answer: B. The loop must follow stop_reason. The reply that ended the loop was a tool call in progress, so stop_reason was "tool_use". A and D still decide from the wrong signal, and C relies on wording that Claude may not produce.

Question 2

Claude returns one response with two tool_use blocks: get_order and get_refund_policy. How should the application return the results?

A. Send two user messages, one per result, in the order the tools finished.B. Send one user message that starts with a text summary, followed by both tool_result blocks.C. Send one user message containing both tool_result blocks, each with its matching tool_use_id.D. Return only the get_order result, because the policy is fixed.

Answer: C. Every tool_use block needs a tool_result with the same tool_use_id, all in the next user message, with results before any text. A splits the results, B puts text first, and D leaves a tool call unanswered, which the API rejects.

Build exercise

Build a loop with two tools, get_order and get_refund_policy, against the Messages API.

Log stop_reason on every iteration and confirm the loop exits only on end_turn.
Ask a question that needs both tools and check that Claude calls them in one response and that you return both results in one user message.
Make get_order fail for one order ID and return is_error: true with a clear message. Watch Claude correct the input and retry.
Add an iteration cap of 10 and log a warning if it is ever reached. If it is, find the cause instead of raising the cap.

Practise this topic

Claude Certified Architect practice exam: free, 20 questions, no sign-up
Claude Certified Architect hub
CCAR-F study guide: all topics
Worked example: Production Claude tool loop
Next topic: 1.2 Coordinator and subagent patterns

Sources

Claude Certified Architect Foundations Exam Guide, version 1.0, effective July 2026 (Anthropic), task statement 1.1
Anthropic documentation: Stop reasons
Anthropic documentation: Handle tool calls
Anthropic documentation: Parallel tool use
Anthropic: Building effective agents