The 10 Anti-Patterns

Anthropic publishes ten anti-patterns that recur as wrong answers on the Architect and Developer exams. If you can spot them in an option, you can eliminate that option instantly. For each: what it looks like in a question stem, why it fails, the correct alternative with a snippet, and the phrasing examiners use to make it sound right.

The distractors are engineered to be tempting — they usually appear “reasonable”, “simpler”, or “more flexible”. The table below is your fast reference; the sections expand each one.

Anti-pattern 1 · Parsing natural language for loop termination

In a stem: “The agent loop stops when Claude’s response contains the phrase ‘task complete’.” / “We detect completion by scanning the output text for ‘done’.”

Why it fails: The model’s prose is not a control signal. It varies with phrasing, can be wrong, and can be manipulated by prompt injection in tool results. Loops that key off text stop early, never stop, or stop when hijacked.

Correct alternative: Drive the loop from the API’s stop_reason.

if resp.stop_reason == "tool_use":
    ...  # run tools, continue
elif resp.stop_reason == "end_turn":
    break  # done
elif resp.stop_reason == "max_tokens":
    raise OutputTruncated()  # not completion

Distractor wording: “For flexibility, terminate when the model says it has finished” — sounds natural-language-friendly and adaptive.

Anti-pattern 2 · Arbitrary iteration caps as the primary stop

In a stem: “The loop runs a fixed 10 iterations and then stops.” / “We limit the agent to 5 tool calls to keep it bounded.”

Why it fails: A cap alone tells you nothing about whether the task finished. If the loop only ends by hitting the cap, results are silently incomplete; if the cap is too high, cost runs away.

Correct alternative: stop_reason is the primary stop; the cap is a backstop against runaway loops.

iterations = 0
while resp.stop_reason == "tool_use" and iterations < MAX_ITERS:  # cap = safety net
    ...
    iterations += 1

Distractor wording: “To prevent infinite loops, cap iterations and treat reaching the cap as completion” — conflates a safety net with a completion signal.

Anti-pattern 3 · Prompt-based enforcement of critical rules

In a stem: “We added ‘never run destructive commands’ to the system prompt.” / “CLAUDE.md tells Claude to always run tests before committing.”

Why it fails: Prompt instructions are probabilistic and vulnerable to injection. A critical business or safety rule that must always hold cannot rely on best-effort compliance.

Correct alternative: Enforce with a deterministic hook (exit code 2 blocks) or programmatic guard.

# PreToolUse hook: block the action deterministically
if echo "$cmd" | grep -q 'rm -rf'; then echo "blocked" >&2; exit 2; fi

Distractor wording: “Strengthen the instruction and use an emphatic, all-caps rule in the prompt” — implies wording can make a probabilistic control deterministic.

Anti-pattern 4 · Self-reported confidence for escalation

In a stem: “The agent escalates when its self-reported confidence drops below 70%.”

Why it fails: Language models are poorly calibrated; their stated confidence does not reliably track correctness. Routing on it produces both false escalations and missed ones.

Correct alternative: Escalate on explicit user request (immediately) or an objective capability gap (after attempting resolution).

if turn.user_explicitly_requested_human: escalate()          # now
elif turn.needs_capability_agent_lacks and turn.attempts_exhausted: escalate()

Distractor wording: “Use the model’s confidence score to decide when a human is needed” — sounds data-driven and principled.

Anti-pattern 5 · Sentiment-based escalation

In a stem: “When sentiment analysis flags the customer as frustrated, escalate to a human.”

Why it fails: Sentiment is not complexity. A frustrated customer may have a trivial, resolvable request; a calm one may have a genuinely hard problem. Sentiment-driven routing sends resolvable cases to humans and can miss complex ones.

Correct alternative: Handle emotion with a good response; escalate on explicit request or capability gap. Use sentiment to adjust tone, not to route.

Distractor wording: “Improve customer experience by escalating angry customers immediately” — appeals to empathy.

Anti-pattern 6 · Generic error messages hiding context

In a stem: “On failure the tool returns ‘An error occurred’.” / “Errors are caught and a generic message is shown.”

Why it fails: The agent (and operators) lose the diagnostic detail needed to decide whether to retry, escalate, or fix the input. Recovery becomes guesswork.

Correct alternative: Return structured errors with category, retryable flag, message and any partial results.

{ "status": "error", "category": "rate_limit", "retryable": true,
  "retry_after": 12, "partial": [] }

Distractor wording: “For a clean user experience, hide technical details behind a friendly generic message” — sounds like good UX.

Anti-pattern 7 · Silently suppressing errors as success

In a stem: “On failure the tool returns an empty list.” / “Exceptions are swallowed and the agent continues.”

Why it fails: A failure disguised as “no results” or success propagates wrong data downstream. The agent cannot distinguish a real empty result from a broken call.

Correct alternative: Surface failures explicitly; distinguish {status:"ok", items:[]} from {status:"error", …}.

try:
    return {"status": "ok", "items": query()}
except BackendError as e:
    return {"status": "error", "category": "backend", "retryable": True, "message": str(e)}

Distractor wording: “To keep the agent robust, catch errors and return empty results so the flow never breaks” — sounds resilient.

Anti-pattern 8 · Too many tools per agent

In a stem: “The agent is configured with 18 tools covering every operation.”

Why it fails: Each tool schema consumes context, and past a handful the model’s selection accuracy drops — it picks the wrong tool or hallucinates arguments.

Correct alternative: Give each agent 4–5 focused tools; split responsibilities across subagents; for large catalogues enable the tool search tool and defer_loading: true.

tools = [
    {"type": "tool_search_tool_20250101", "name": "tool_search"},
    {"name": "search_kb", "defer_loading": True, "input_schema": {...}},  # loads on demand
]

Distractor wording: “Give the agent all available tools so it never lacks a capability” — sounds thorough and flexible.

Anti-pattern 9 · Same-session self-review

In a stem: “We ask the model, in the same conversation, to check whether its answer is correct.”

Why it fails: The reviewing turn shares the reasoning context that produced the error, so it inherits the same bias and tends to confirm the original answer.

Correct alternative: Use an independent evaluator — a fresh session, ideally a different model — scoring against an explicit rubric (evaluator-optimizer, LLM-as-judge).

judge = client.messages.create(model="claude-sonnet-5",  # different model/session
    messages=[{"role": "user", "content": f"<rubric>{rubric}</rubric><answer>{ans}</answer> Score it."}])

Distractor wording: “Have the model self-critique in the same chat to catch its own mistakes” — sounds efficient.

Anti-pattern 10 · Aggregate metrics masking per-type failure

In a stem: “Extraction accuracy is 94% overall, so the pipeline is ready.” (while one document type is at 60%)

Why it fails: A single aggregate number hides a category that is failing badly. The worst-performing segment is exactly where the business risk lives.

Correct alternative: Report per-segment / per-document-type metrics and gate on the worst type, not the average.

overall: 94%   ← misleading
invoices: 99%  contracts: 60%  receipts: 96%   ← the real picture; gate on contracts

Distractor wording: “The aggregate accuracy exceeds our 90% bar, so ship it” — sounds metric-driven and objective.

Distractor families: how examiners disguise each anti-pattern

The ten anti-patterns cluster into families that share a “sound good” surface. Recognising the family lets you eliminate two or three options at once.

Worked distractor elimination

Stem: “A support agent should hand off to a human. The customer is angry but their request (order status) is fully resolvable, and the model reports 62% confidence. Which is correct?”

A. Escalate due to negative sentiment.            → #5 sentiment    ✗ eliminate
B. Escalate because confidence < 70%.             → #4 self-report  ✗ eliminate
C. Resolve the request; neither sentiment nor     → explicit-request/capability rule  ✓
   confidence is a valid trigger, and it is within capability.
D. Cap the chat at 3 turns then escalate.         → arbitrary cap, not an escalation rule  ✗

Two distractors (A, B) belong to the trust-the-model’s-feelings family; D is a control-flow-by-vibes cap misapplied to escalation. C applies the actual rule.

How to use this list in the exam