Domain 1 · Lesson 1 · Agentic Architecture (27%)

The Agentic Loop Lifecycle

Task Statement 1.1 — how an agent actually runs, and the three loop-control mistakes the exam loves.

Course progress: Domain 1 ▸ lesson 1 of ~4

An "agent" is not magic. It is a loop wrapped around a single stateless API call. Master the loop and half of Domain 1 collapses into common sense.

The four steps

Send the conversation (system prompt + messages + tool definitions) to Claude.
Inspect stop_reason on the response.
If stop_reason == "tool_use": execute the requested tool(s), then append the tool result(s) to the message history and go back to step 1.
If stop_reason == "end_turn": the model is done — stop and surface the final text.

The single load-bearing fact stop_reason is the loop's control signal. Continue on "tool_use", terminate on "end_turn". Everything else is a distractor.

Why tool results must go back into history

The API is stateless — each call only knows what you send it. When a tool returns (say lookup_order → status, dates, amount), you append that result as a message. On the next iteration Claude reads it and reasons about what to do next. Drop it, and the model is blind to its own tool's output.

This is also model-driven decision-making: Claude picks the next tool from accumulated context. That is different from a hard-coded decision tree or fixed tool sequence — and the exam treats model-driven flexibility as the default agentic pattern (you only override it with enforcement when you need a guarantee — Lesson 3).

while True:
    resp = claude.create(messages=history, tools=TOOLS)
    if resp.stop_reason == "tool_use":
        for call in resp.tool_calls:
            result = run(call)                 # execute
            history.append(tool_result(result)) # feed back
        continue                                # loop
    else:  # "end_turn"
        return resp.text                        # done

The three anti-patterns (memorize these)

The exam builds distractors out of "reasonable-sounding" loop controls that are actually wrong:

Anti-pattern	Why it's wrong
Parsing natural-language signals ("looks like Claude is finished") to end the loop	Brittle and non-deterministic; the structured `stop_reason` already tells you exactly.
Using an arbitrary iteration cap as the primary stopping mechanism	A cap is a safety backstop, not the control signal. It truncates legitimate work or masks a stuck loop.
Checking for assistant text content as a completion indicator	Claude can emit text and still request a tool. Text presence ≠ done.

Exam tellIf an option proposes stopping the loop by reading the message text, counting turns, or "detecting" completion in prose — it's a distractor. The correct answer keys off stop_reason.

Check yourself

Your agent loop sometimes ends a turn while the model still wanted to call a tool, dropping work. Which is the correct loop-termination condition?

Stop the loop once the response contains any assistant text content
Stop only when stop_reason equals "end_turn"; continue otherwise
Stop after a fixed maximum number of agent iterations is reached
Stop when the assistant text reads as a complete final answer

Correct: option 2. stop_reason == "end_turn" is the only reliable signal that Claude is finished; "tool_use" means keep going. The other three are the canonical anti-patterns: text-presence (Claude can emit text and request a tool), iteration caps (a backstop, not a control signal), and prose "completion detection" (non-deterministic).

After a tool executes in your loop, the model on the next turn acts as if the tool never ran. The most likely cause is that your loop:

Did not append the tool result back into the conversation history
Did not raise the configured maximum output token limit
Did not switch the model into its extended thinking mode
Did not set the tool_choice parameter to force a tool

Correct: option 1. The API is stateless; if the tool result isn't appended to history, the next request literally doesn't contain it, so Claude can't reason over it. Token limits, thinking mode, and tool_choice are unrelated to whether the model sees prior tool output.

Decision rule to carry forward Loop control = stop_reason. State persistence = append tool results. Next-action choice = model-driven (default), unless a guarantee forces enforcement.

I'm your teacher — ask me anything. Unclear on stateless calls, parallel tool calls in one turn, or how max_tokens interacts with stop_reason ("max_tokens" is a third value)? Ask and I'll go deeper before we move on.