The CCA Foundations exam, as its published guide describes it, 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 in the scenario-based questions the published guide describes: two answer choices that both look defensible, where one is architecturally correct and one commits a mistake you'll regret in production.
These seven anti-patterns map onto task statements in the published exam guide, cited in each section. Study each one until you can explain not just what's wrong but why it's wrong under load.
Here's the reframe: passing the CCAR-F (also written CCA-F) on your first attempt isn't about memorising a list of things not to do. It's about walking into exam day already thinking like the architects who get these questions right — recognising the trap, and reaching for the correct approach automatically. Each anti-pattern below pairs the mistake with exactly what to do instead, so working through this page once is enough to shift your instincts.
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.
Where the guide places it: Task Statement 1.4 covers programmatic prerequisites that block a downstream tool call until an earlier step has completed, and states that where deterministic compliance is required, prompt instructions alone have a non-zero failure rate. Read the condition with the rule. When the scenario needs the order guaranteed, because a miss is a business or safety failure, the answer that enforces it outside the prompt is the one the task statement describes. When the scenario needs the order to be reliable rather than guaranteed, the prompt is a legitimate answer and the enforcement option is more than the requirement asked for. How to tell the two apart is the subject of our post on guarantee questions and accuracy questions.
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: write the escalation criteria into the system prompt explicitly, with few-shot examples showing a case that should escalate beside a case that should be resolved. Task Statement 5.2 names the triggers that belong there: the customer asks for a person, the policy is silent or ambiguous on the specific request, or the agent cannot make meaningful progress. Every one of those is a condition about the case, not a reading of how sure the model feels about its own answer. Where a hard threshold exists, such as a transaction above a stated amount, a hook can enforce it, but the criteria themselves live in the prompt.
Where the guide places it: Task Statement 5.2 lists self-reported confidence scores, alongside sentiment, as unreliable proxies for how hard a case actually is, and its first skill is adding explicit escalation criteria with few-shot examples to the system prompt. Notice that this is a prompt-side answer. It is the clearest case of why the rule in Anti-Pattern 1 needs its condition: a badly calibrated escalation rule is fixed by a better-specified rule.
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.
Where the guide places it: Task Statement 4.5 draws the line at latency tolerance, not interactivity: batch processing for overnight reports and nightly test generation, synchronous calls for a blocking pre-merge check. The answer depends on the SLA stated in the scenario, not on whether the task is "background" or "async".
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.
Where the guide places it: Task Statement 5.1 names the lost-in-the-middle effect and keys placing key findings at the beginning of aggregated inputs and trimming verbose tool outputs before they accumulate. Task Statement 5.4 keys /compact for long exploration sessions. A larger window is not among the mechanisms either names.
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.
Where the guide places it: Task Statement 5.3 lists silently suppressing errors by returning empty results as success, and terminating a whole workflow on a single failure, as the two anti-patterns, and keys structured error context: the failure type, what was attempted, partial results and alternatives.
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, Task Statement 2.3 of the exam guide covers scoped tool access: giving agents only the tools needed for their 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, keeps each subagent scoped to its role, and limits blast radius if a subagent behaves unexpectedly.
Where the guide places it: Task Statement 2.3 covers scoped tool access and the reliability cost of giving an agent far more tools than its role needs. Read the scenario before reaching for it, because the same guide names tool descriptions as the primary mechanism the model uses to choose between tools (Task Statement 2.1), and keys improving an MCP tool's description when the agent keeps preferring a built-in one (Task Statement 2.4). An agent misrouting between two similar tools with thin descriptions has a description problem. An agent holding tools outside its role, or forty where it needs five, has a scoping problem. Our bank keys both, and the two are not interchangeable.
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.
Where the guide places it: Task Statement 4.3 names tool use with a JSON schema as the most reliable approach for guaranteed schema-compliant output, and adds that a strict schema eliminates syntax errors but not semantic ones, so validation still has a job. When the requirement is that the structure be guaranteed, prompt instructions alone are the wrong answer. The same task statement keeps a place for the prompt beside the schema: format normalisation rules belong there, and Task Statement 4.2 makes few-shot examples the technique for consistent output format. Ask whether the scenario needs the structure guaranteed or the content consistent, and the answer follows.
The Pattern Behind the Patterns: How to Pass the CCAR-F on Your First Attempt
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 mistake is not choosing a prompt. It is choosing a prompt where the requirement needs a guarantee. The published guide's task statements name both sides: hooks and gates when deterministic compliance is required (Task Statements 1.4 and 1.5), and explicit criteria, few-shot examples and tool descriptions where the requirement is accuracy or consistency (Task Statements 4.1, 4.2 and 2.1). Telling which one a scenario needs is the judgement the objectives describe, and it is what separates two options that 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 guide's objectives describe, and it is what your users will depend on in production.
How to Pass the CCAR-F on Your First Attempt: Next Steps
Ready to turn this into a first-attempt pass? Take our free 10-question readiness diagnostic to see exactly where you stand today, then build the pattern-recognition instinct with the 400-question practice bank, and go into exam day ready with the full 60-question timed simulation.