The Anti-Patterns in Agentic loops
When engineers first build an agentic loop, they reach for signals that feel natural but are fragile:
- Parsing the model's prose — scanning the assistant's text for phrases like "I'm done" or "task complete."
- Iteration caps as the primary brake — hard-stopping at, say, 10 turns and treating that as the design.
- Checking for text content — assuming that if the model wrote something instead of calling a tool, the job must be finished.
Each of these confuses a symptom of completion with the signal for it. Prose can be misread, a legitimate task can exceed an arbitrary cap, and a model can emit text mid-task while still intending to call another tool.
The correct pattern
Drive the loop off stop_reason. Continue while it's tool_use; terminate on end_turn. Append each tool result back into the conversation so the model reasons about the next step with full context. Iteration caps still belong in the design — but as a safety net against runaways, never as the primary termination logic.
Why the exam cares
The distinction separates model-driven decision-making from a pre-configured decision tree. An agent is supposed to reason about which action comes next; if your control flow is really just string-matching on natural language, you have not built an agent — you have built a brittle parser wearing an agent's clothes. On the exam, scenario questions will hand you a plausible-looking loop and ask what's wrong with it. The answer is almost always: it stops for the wrong reason.
Note: exact domain weightings and question specifics come largely from third-party prep material. Anthropic's own API reference, Claude Code docs, and the MCP spec are the source of truth.
Join the conversation