The CCA Foundations exam doesn't test whether you know Claude's API. It tests whether you know how to architect with it — and the fastest way to calibrate that judgment is to study the mistakes that well-intentioned architects make repeatedly. Every anti-pattern below has a recognisable signature on the exam: two answer choices that both look defensible, where one is architecturally correct and one commits a mistake you'll regret in production. Candidates who have seen these patterns fail less often. Candidates who haven't encounter them for the first time under exam conditions.
These seven anti-patterns appear across all five CCA domains. They were identified from production incident post-mortems, from the patterns that distinguish strong from weak architectural decisions in scenario-based questions, and from what the exam is specifically designed to surface. Study each one until you can explain not just what's wrong but why it's wrong under load.
Anti-Pattern 1: Using Prompts to Enforce Tool Ordering
The mistake: an agent has two tools that must be called in a specific sequence — say, validate_input before process_payment — and the developer instructs Claude in the system prompt to always call them in that order.
Why it fails: prompts are probabilistic. They influence Claude's behaviour but do not guarantee it. Under novel inputs, edge cases, or after context compaction has summarised away part of the instruction history, the ordering instruction can be ignored or deprioritised. In a payment flow, that means process_payment executes on unvalidated input.
The correct approach: enforce prerequisites programmatically. Gate the process_payment tool at the infrastructure level so it cannot be called unless validate_input has returned a success response. The orchestration layer — not the model — is responsible for enforcing control flow with hard dependencies. Reserve the system prompt for guidance, not guarantees.
How it appears on the exam: a scenario presents a multi-tool agent with a sequential dependency and asks how to ensure the correct execution order. The correct answer always enforces the constraint outside the prompt. Any answer that relies on prompt instructions alone for safety-critical ordering is wrong.
Anti-Pattern 2: Using Model Confidence for Escalation Routing
The mistake: an agent is configured to escalate to a human operator when Claude's confidence in its answer is low. The developer treats Claude's expressed certainty as a reliable signal for routing decisions.
Why it fails: large language models — including Claude — are not well-calibrated for confidence. A model can be highly confident in an incorrect answer. It can be hesitant about a correct one. Expressed uncertainty in the output text does not reliably track actual accuracy on any specific query, particularly on out-of-distribution inputs that are exactly the kind that most benefit from human review.
The correct approach: base escalation routing on explicit, verifiable signals — tool call failures, constraint violations, user-defined triggers (e.g. "involves a transaction above $10,000"), or task-type classification. Where uncertainty thresholds are needed, build separate evaluator agents or heuristic classifiers to assess output quality, rather than asking the generating model to self-report it reliably.
How it appears on the exam: a scenario asks how an agent should handle low-confidence situations. Answers that route on the model's expressed confidence are incorrect. The correct answer routes on structured, externally-defined conditions.
Anti-Pattern 3: Routing All Async Work to the Batch API
The mistake: a developer learns that the Batch API offers 50% cost savings and decides to route all non-interactive workloads through it — including workflows that have implicit or undocumented SLA requirements.
Why it fails: the Batch API is optimised for throughput, not latency. Batch requests are processed within a 24-hour window. "Non-interactive" does not mean "without time constraints." A nightly report generation job, a partner integration that expects a webhook response within 30 minutes, or an internal pipeline with a downstream dependency all have time constraints that make batch routing incorrect regardless of whether a human is watching a loading spinner.
The correct approach: classify tasks by their latency requirements, not their interactivity. Use the Batch API exclusively for workloads with genuinely flexible completion windows where cost is the primary constraint. Use synchronous requests for any workflow with a defined SLA, even if that SLA is hours rather than seconds.
How it appears on the exam: a scenario describes a background task and asks which API to use. The correct answer depends on the SLA stated in the scenario — not on whether the task is "background" or "async." Candidates who default to Batch API for all non-interactive tasks lose these marks predictably.
Anti-Pattern 4: Treating a Larger Context Window as an Attention Solution
The mistake: a production system is producing inconsistent outputs on long inputs. The developer's diagnosis is that Claude isn't "seeing" all the relevant content, and the fix is to increase the context window size or use a model with a larger window.
Why it fails: attention distribution in transformer models is not uniform across the context. Research consistently shows that content in the middle of a very long context receives less reliable attention than content at the beginning or end — the "lost in the middle" problem. Adding more context can make this worse, not better, by burying relevant content deeper into the attention trough.
The correct approach: restructure the input. Place the most critical information — the precise instructions, the most relevant context, the content the model needs to act on — at the beginning or end of the input, not the middle. Use retrieval to surface only the relevant content rather than loading everything. Shrinking the context to what's necessary is often more effective than expanding it.
How it appears on the exam: a scenario presents an agent producing poor results on long documents and asks for the best fix. Increasing context window size is an incorrect answer. The correct answer restructures, retrieves, or compacts the input.
Anti-Pattern 5: Returning Empty Results on Subagent Failure
The mistake: in a multi-agent system, one subagent fails — a tool times out, a permission is denied, an API returns an error — and the orchestrator silently omits that subagent's contribution from the final output without surfacing the failure.
Why it fails: silent failure propagation is one of the most dangerous patterns in agentic systems. The user receives a result that appears complete but is missing a component they're unaware of. In a research agent summarising five data sources, a silent failure on one source produces a summary missing 20% of the relevant information — presented with the same confidence as a complete result.
The correct approach: surface all failures explicitly. Return results from successful subagents, but clearly identify which subagent failed, why it failed, and what was not completed. Give the user or orchestrator the information needed to decide whether to retry, continue with partial results, or abort. Transparency about incomplete results is always preferable to silent omission.
How it appears on the exam: a scenario describes a subagent failure and asks how the orchestrator should respond. Any answer that silently returns partial results is wrong. The correct answer surfaces the failure and gives the user actionable information about what is missing.
Anti-Pattern 6: Giving All Tools to All Agents
The mistake: a multi-agent system is built with a shared tool registry, and every subagent — regardless of its specific role — is initialised with access to the full set of available tools.
Why it fails: tool selection quality degrades as the tool set grows. A model choosing from 40 tools makes worse selection decisions than the same model choosing from 8 tools scoped to its specific task. Beyond selection accuracy, the minimal-footprint principle requires that agents be granted only the permissions needed for their defined role. A summarisation subagent with access to a delete_database_record tool is an accident waiting for the right edge case.
The correct approach: scope tool access to role. Each subagent receives only the tools required to complete its specific task. A research subagent gets read-access search tools. A writing subagent gets content tools. An orchestrator gets coordination tools. This improves selection accuracy, enforces the minimal-footprint principle, and limits blast radius if a subagent behaves unexpectedly.
How it appears on the exam: scenarios involving agent tool access almost always test this principle. An agent that has been given broad tool access and is making poor selections is almost always fixed by narrowing — not improving descriptions, and not adding more tools.
Anti-Pattern 7: Using Prompts Alone for Output Schema Enforcement
The mistake: a production system needs Claude to return JSON in a specific schema. The developer adds detailed instructions to the system prompt describing the required format and relies on those instructions to guarantee valid JSON output.
Why it fails: like tool ordering, prompts are probabilistic. Claude will follow formatting instructions with high reliability under normal conditions. Under novel prompts, unusual inputs, or long context windows where instruction salience diminishes, schema deviations occur. In a downstream system that parses the JSON and passes the result to a database write operation, a single malformed response can cause a silent failure or an exception that breaks the pipeline.
The correct approach: use structured output tools. Claude's API supports forced JSON output via tool_use with a defined input_schema — this constrains the output format at the generation level, not at the instruction level. Combine structured output with server-side validation. Treat prompt instructions as guidance for content, not enforcement for structure. Structure is the infrastructure layer's responsibility.
How it appears on the exam: a scenario describes a system that needs reliable JSON output and asks how to ensure schema compliance. Prompt instructions alone as the answer is always wrong. The correct answer uses structured output via tool use, or structured output combined with validation.
The Pattern Behind the Patterns
Every anti-pattern above shares a common root: treating the model as more reliable than it is for tasks that require guarantees. Prompts guide. Infrastructure enforces. The CCA exam is designed to verify that you understand this distinction at the architectural level — not just intellectually, but in enough practical detail to make correct design choices when two options both look reasonable.
The fastest way to internalise these patterns isn't to memorise this list. It's to practise enough scenario-based questions that the distinction between "good-enough for demos" and "correct for production" becomes automatic. That calibration is what the exam is measuring, and it's what your users will depend on in production.
Ready to test your pattern recognition? Our platform has 300 scenario-based questions across all five domains, each with a detailed explanation covering exactly this kind of architectural reasoning. Start with the free practice question bank, or jump directly into the full 60-question timed simulation.