Agentic Loops and stop_reason: What CCA-F Actually Tests

The single most-weighted concept on the exam, and the three anti-patterns that show up disguised as reasonable-sounding wrong answers.

Agentic Architecture & Orchestration is 27% of the CCA-F — more than any other domain — and the agentic loop is its foundation. Get this concept solid and a large share of Domain 1's scenario questions become straightforward.

The lifecycle

An agentic loop has four steps: send a request, inspect stop_reason on the response, execute any requested tools if stop_reason is tool_use, and return the tool results as the next message — repeating until stop_reason is end_turn. That's the entire mechanism. Everything else is orchestration built on top of it.

Why stop_reason and nothing else

stop_reason is the only reliable, structured signal the API gives you for loop control. It's deterministic, documented, and doesn't depend on how the model happens to phrase its output this time.

Three anti-patterns the exam tests

1. Parsing natural-language signals. Looking for phrases like "I'm finished" or "no further action needed" in assistant text to decide whether to keep looping. This breaks the moment phrasing varies even slightly.
2. Arbitrary iteration caps as the primary mechanism. A max-iteration count is a legitimate safety net, but it is not loop control — using it as the main way a loop terminates means the agent either stops too early on legitimate multi-step work or spins uselessly until the cap hits.
3. Checking for assistant text content instead of stop_reason. A response can include commentary text alongside a tool_use block — checking "did it say anything" instead of checking stop_reason produces false terminations.

A worked exam trap

A scenario describes an agent that stops after its first tool call returns a result, even though the task clearly needs a follow-up action. The "premature termination" bug here is almost always a design that treats "received a tool_result" as equivalent to "the model is satisfied" — instead of sending the result back to the model and letting it decide, via its next stop_reason, whether more work is needed.

Once stop_reason-driven control is second nature, move to orchestration patterns: the Domain 1 glossary covers prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer with the exam-context notes that matter for picking between them. Then drill it with Domain 1 practice questions.