The 7 Anti-Patterns: How Wrong Answers Are Built
Every distractor on the CCA-F exam is one of a small set of plausible architectural mistakes. Learn to recognise these seven instantly and you can often eliminate two or three wrong options before you finish reasoning through the right one — with two minutes per question, that is the difference between a comfortable pass and a rushed guess.
Domain 1 (Lesson 1) already introduced several of these anti-patterns in passing, wherever the underlying architecture naturally called for it — prompt-based enforcement in §1.8, silent subagent failure in §1.3, unrestricted tool access in §1.6, flat topology in §1.5. This lesson is the opposite move: instead of meeting each mistake once, in context, you get a dedicated, systematic pass over all seven — the definition, why it is tempting, a wrong-vs-right contrast, and the exact phrasing the exam uses to signal it.
Treat this page as a reference to revisit in the final week before the exam, not a one-time read. The goal is pattern recognition fast enough that it happens before you have consciously finished the question stem.
7.1 Anti-pattern #1: Prompt-based rule enforcement
Definition:relying on system-prompt wording — "never do X", "always do Y" — for a rule that must be absolutely guaranteed, instead of deterministic code enforcement (a PreToolUse hook, a deny permission rule, input validation).
Why it is a tempting distractor
It is fast to write, costs nothing to add, and reads like a policy document — confident, direct language that sounds like it settles the matter. Candidates under time pressure often pick the option that states the rule most forcefully, mistaking forceful wording for enforcement.
| Wrong | Right |
|---|---|
| "Never modify files in /prod" in CLAUDE.md or the system prompt | A PreToolUse hook (or deny permission rule) that blocks Edit/Write on that path |
| Repeating the instruction in every subagent definition for good measure | One deterministic check, enforced at the tool layer, that every subagent inherits |
7.2 Anti-pattern #2: Self-reported confidence for escalation
Definition:using the model's own stated confidence ("I'm 80% sure") as the trigger for escalating to a human or another system, instead of a deterministic, objective trigger the calling code can check without trusting the model's self-assessment.
Why it is a tempting distractor
It feels like putting the model's own judgment to good use — efficient, and it avoids hard-coding business rules. The catch: a model's self-reported certainty is poorly calibrated. It can be confidently wrong, or unconfident about an answer that is actually correct, so it is not a signal your architecture can rely on.
| Wrong | Right |
|---|---|
| "If the model says it isn't sure, escalate to a human" | Escalate on a policy-boundary breach, a repeated tool failure, an explicit user request, or a loop-iteration cap being hit |
| Gate an answer on a confidence score crossing 70% | Gate on a dollar threshold, a retry count, or a validation failure the code can actually check |
7.3 Anti-pattern #3: Batch API for blocking/real-time workflows
Definition: using the Message Batches API — cheaper, but with turnaround up to 24 hours and no real-time SLA — for a flow where a user or another system is waiting synchronously for the response.
Why it is a tempting distractor
The cost savings look attractive on paper (roughly half the price for the same tokens), and a question that mentions volume or cost-optimisation nudges you toward "use the cheaper API" before you have checked whether anyone is actually waiting on the result.
| Wrong | Right |
|---|---|
| Route a live chat reply through the Batches API to cut cost | The real-time Messages API — the customer is watching the screen |
| Process a nightly, no-one-waiting extraction job with a synchronous loop over the Messages API | The Batches API — deadline-tolerant, async, and materially cheaper here |
7.4 Anti-pattern #4: Bigger context window as the fix
Definition:responding to a context or compaction problem by simply requesting more context window, or a larger model's context limit, instead of restructuring the approach — extracting durable facts to external state, decomposing into subagents, or processing in multiple passes.
Why it is a tempting distractor
It avoids the harder architectural work. A bigger window is a one-line configuration change; durable state extraction and decomposition require actually thinking about what should survive and where it should live. The exam rewards the latter every time.
| Wrong | Right |
|---|---|
| "The conversation got too long — use a model with a bigger context window" | Extract durable facts to external state as they happen; re-inject them every request |
| "The research task has too many documents — increase the context limit" | Decompose into subagents, each with its own slice, reporting structured summaries; use scratchpad files for working notes |
7.5 Anti-pattern #5: Silent subagent/tool failure
Definition: a subagent or tool call that fails returns an empty result, a blank string, or is silently skipped — rather than returning structured error information: what failed, why, and whether it is retryable.
Why it is a tempting distractor
It lets the pipeline "keep going" without an ugly error surfacing, which reads as resilience. In practice it hands the model a gap it cannot distinguish from a real, empty answer — the agent hallucinates a success path instead of recovering.
| Wrong | Right |
|---|---|
Return "" so the loop does not break | Return a tool_result with is_error: true, an error category, and a retryability hint |
| "Skip the failed step and continue" | Let the calling agent reason over the structured error and decide whether to retry, route around it, or surface the gap |
7.6 Anti-pattern #6: Unrestricted tool access
Definition:giving every agent or subagent access to every available tool "just in case", instead of scoping tools tightly to each agent's actual role.
Why it is a tempting distractor
It looks more flexible, and it avoids the upfront design work of deciding exactly what each subagent needs. The cost is invisible until it is not: reasoning overload from a bloated tool list, and a much larger blast radius if the agent misfires or is manipulated.
| Wrong | Right |
|---|---|
| Connect every MCP server and every tool to every agent "for flexibility" | A read-only research subagent gets Read/Grep only; a test-runner gets test-execution tools, not deploy tools |
| Rely on the system prompt to tell an over-permissioned agent which tools not to use | Never grant the tool in the first place if the role does not need it |
7.7 Anti-pattern #7: Flat/peer-to-peer multi-agent topology
Definition: letting subagents communicate directly with each other instead of routing all coordination through a single coordinator (hub-and-spoke).
Why it is a tempting distractor
It sounds more efficient — cutting out a "middle step" feels like removing overhead. In practice it removes the one thing that made the system debuggable: a single owner of "done" and a single point where every decision can be audited.
| Wrong | Right |
|---|---|
| "Let agent A send its results directly to agent B for efficiency" | A sends a structured report to the coordinator, which curates what B receives |
| "Peer agents coordinate among themselves" | The coordinator owns the plan, the completion decision, and the single audit trail |
Rapid elimination drill
Here is the skill in action, on a sample question in the CCA-F's own format: one scenario, four options, three of them are anti-patterns wearing a plausible disguise.
- A.The failing subagent returns an empty summary so the coordinator's synthesis step is not interrupted. → struck: anti-pattern #5, silent failure
- B.Escalate to a human whenever the subagent's self-reported confidence drops below 70%. → struck: anti-pattern #2, confidence as trigger
- C.Route the failing subagent's partial results directly to the writer subagent so the coordinator is not a bottleneck. → struck: anti-pattern #7, flat topology
- D. The subagent returns a structured
is_errorresult (category: timeout, retryable: true); the coordinator retries once with backoff, then reports the gap if it still fails. → survives: correct
Read the stem once: a tool failed mid-task inside a multi-agent system. That alone is enough to scan every option for the three usual suspects — a result that disappears (#5), a decision routed through the model's own confidence (#2), and a shortcut that skips the coordinator (#7) — strike all three, and D is the only option left standing before you have spent ten seconds on it. That is the whole skill: it is not that D is obviously well-written, it is that A, B and C are each obviously one of the seven.
Checkpoint quiz — The 7 Anti-Patterns
Exam-style: one scenario, one correct answer, three plausible mistakes. Click an option to lock in and see the explanation.
Team policy: Claude Code must never commit directly to main, or write to infra/prod/. Which design guarantees this?
The support agent is mid-way through a billing dispute. Which trigger set correctly decides when to hand off to a human?
A team extracts six fixed fields from invoices while the customer waits on a confirmation screen. Which processing approach is correct?
The research coordinator's conversation spans 40 source documents. It keeps hitting compaction and losing track of which sources were already checked. What is the correct fix?
This is a headless, non-interactive CI/CD pipeline (Claude Code's -p mode). A step's Bash tool call to run the test suite fails because the runner ran out of disk space. What should the tool result contain?
You are setting up a subagent whose only job is to review generated code for security issues before merge. Which design is correct?
A coordinator delegates to a search subagent and a writer subagent. The search subagent finishes first. What should happen next?
Quick glossary
Every term below appears somewhere in this course. If a question uses a word you're unsure of, check here before re-reading the whole lesson.
Agentic loop
The repeating cycle behind any Claude-powered agent: send a request, check what Claude wants to do next (stop_reason), run a tool if asked, send the result back, repeat until Claude is done.
stop_reason
A field on Claude's response telling your code why it stopped talking — e.g. it wants to call a tool (tool_use), it finished (end_turn), or it ran out of room (max_tokens).
tool_use / tool_result
tool_use is Claude asking your code to run something (a search, a database lookup...). tool_result is your code's answer, sent back so Claude can continue.
Subagent / Agent tool
A helper Claude spawns to do one focused piece of work in its own separate memory space, then reports back a summary — so the main conversation doesn't get cluttered with the helper's scratch work.
Hooks (PreToolUse / PostToolUse)
Small scripts that run automatically around a tool call — one right before it (can block it entirely) and one right after (can react to the result). Used for rules that must always hold, not just usually hold.
MCP (Model Context Protocol)
A standard way to connect Claude to external systems — databases, internal tools, company APIs — through a shared plug-in format instead of custom one-off code every time.
MCP Tools vs Resources vs Prompts
The three things an MCP connection can offer: Tools are actions Claude decides to call itself; Resources are data the surrounding app decides to hand Claude; Prompts are ready-made instructions a person picks, like a menu option.
.mcp.json
A config file listing which external MCP connections a project uses — shared with the whole team via version control, with any secret keys kept out of it and read from environment variables instead.
CLAUDE.md
A plain-text file Claude reads automatically at the start of every session in a project — the place for standing instructions like coding conventions or how the codebase is organized.
.claude/rules/
Instructions that only switch on for certain files (e.g. only when editing test files), instead of loading into every single session the way CLAUDE.md does.
Agent Skill
A packaged set of instructions Claude loads by itself when a task matches, without anyone typing a command — think of it as an instruction manual Claude picks up automatically off the shelf.
allowed-tools vs disallowed-tools
Two different settings that sound alike: allowed-tools just skips the usual 'are you sure?' prompt for tools you've pre-approved — it doesn't block anything else. disallowed-tools is what actually removes a tool from what's available.
Plan mode
A mode where Claude describes what it's about to do and waits for a yes before touching any files — used for bigger or riskier changes, skipped for small obvious ones.
Message Batches API
A cheaper way to send Claude a large pile of requests when nobody is waiting on the answer right away — costs about half as much, but can take up to a day to come back.
Prompt caching
A way to avoid Claude re-reading the same large, unchanging block of text (like a system prompt or a codebase) on every single request — it's remembered for a while, which is both cheaper and faster.
Context window
The total amount of conversation and text Claude can 'see' at once for a given request. When a conversation runs long, older parts may need to be summarized or dropped to make room.
Hub-and-spoke (multi-agent)
A setup where one coordinator agent hands out tasks to several helper agents and collects their answers — the helpers never talk directly to each other, only to the coordinator.
Anti-pattern
A design choice that looks reasonable but causes real problems in practice — this course names seven specific ones the exam likes to hide inside wrong answers.