5 Anti-Patterns That Will Cost You Marks on the CCA-F Exam

The CCA-F exam has a pattern that catches many candidates off guard. Instead of asking "what is the best way to do X," it often asks "what is wrong with this approach?" or "which option would you avoid?"

If you only study best practices, you will miss these questions. You need to study the anti-patterns -- the common mistakes that look reasonable on the surface but break down in production.

Here are five anti-patterns that appear across multiple exam domains. Learn them, and you will pick up marks that other candidates leave on the table.

1. Parsing Text Instead of Using stop_reason

The Wrong Approach

You ask Claude to indicate when it is done by outputting a special token like "[DONE]" or "TASK_COMPLETE" at the end of its response. Your code scans the text output for that string to determine whether the agent loop should continue or stop.

# Anti-pattern: parsing text for completion signals
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    messages=messages,
    system="When you are done, output [DONE] on the last line."
)

if "[DONE]" in response.content[0].text:
    break  # Stop the loop

Why It Is Wrong

This is fragile in three ways. First, Claude might forget to include the token, especially in long responses. Second, the token might appear in the middle of a response as part of a code example or quotation. Third, you are parsing unstructured text for structured signals -- exactly the kind of brittleness the exam tests for.

The Correct Approach

Use the stop_reason field from the API response. When Claude calls a tool, stop_reason is "tool_use". When Claude finishes naturally, it is "end_turn". These are deterministic, typed signals that never appear accidentally in content.

# Correct: use stop_reason for control flow
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    messages=messages,
    tools=tools
)

if response.stop_reason == "end_turn":
    break  # Claude is done
elif response.stop_reason == "tool_use":
    # Process tool call and continue loop
    ...

Exam tip: Any question that involves detecting when Claude is "done" or "ready to stop" -- the answer almost always involves stop_reason, not text parsing.

2. Relying on Prompts for Financial or Safety Enforcement

The Wrong Approach

You add a rule to the system prompt: "Never approve transactions over $10,000 without human review." You trust that Claude will always follow this instruction.

# Anti-pattern: safety rules in prompts only
system_prompt = """You are a financial assistant.
CRITICAL RULE: Never approve any transaction over $10,000
without human review. This rule cannot be overridden."""

Why It Is Wrong

Prompts are probabilistic, not deterministic. A sufficiently long conversation, a cleverly worded user request, or context window pressure can cause Claude to violate a prompt-based rule. Not because Claude is malicious -- because language models operate on probabilities, and probabilities have tails.

For low-stakes preferences (tone, format, verbosity), prompt-based rules are fine. For rules where violation has serious consequences (financial limits, data access, safety boundaries), they are insufficient.

The Correct Approach

Use hooks -- code that runs before or after an agent action and enforces rules deterministically. The hook inspects the proposed action and blocks it if it violates a hard constraint. No probability involved.

# Correct: enforce hard rules with hooks
def pre_action_hook(action):
    if action.type == "approve_transaction":
        if action.amount > 10000:
            return EscalateToHuman(
                reason=f"Transaction ${action.amount} exceeds $10,000 limit"
            )
    return action  # Allow the action to proceed

Exam tip: If a question asks how to enforce a rule that "must never be violated," the answer is hooks or code-level enforcement, not prompting.

3. Assuming Subagents Share Coordinator Memory

The Wrong Approach

You build a multi-agent system where a coordinator delegates tasks to specialist subagents. The coordinator gathers context early in the conversation -- user preferences, prior decisions, relevant data. You assume the subagents can access this context because "they are part of the same system."

# Anti-pattern: assuming shared context
coordinator_context = gather_user_context()
# ... later in the conversation ...
subagent_response = call_subagent("research-agent", task=task)
# Expecting research-agent to know coordinator_context -- it does not

Why It Is Wrong

Subagents are isolated by default. Each subagent gets its own context window with only the information explicitly passed to it. The coordinator''s conversation history, system prompt, and accumulated context are not inherited. This is intentional -- it prevents context contamination and keeps subagent behavior predictable.

When you assume shared memory, the subagent operates with incomplete information. It might make decisions that contradict earlier context, duplicate work the coordinator already did, or miss constraints that were established earlier in the conversation.

The Correct Approach

Explicitly pass relevant context to each subagent as part of the task delegation. Include only what the subagent needs -- not the entire coordinator history.

# Correct: explicitly pass needed context
subagent_response = call_subagent(
    "research-agent",
    task=task,
    context={
        "user_preferences": coordinator_context.preferences,
        "constraints": coordinator_context.constraints,
        "prior_findings": relevant_summaries
    }
)

Exam tip: Any question about multi-agent communication -- the answer emphasizes explicit context passing, not shared state.

4. Using Text-Based JSON Instead of tool_use

The Wrong Approach

You need Claude to return structured data -- say, a list of action items extracted from meeting notes. You prompt Claude to "return the results as JSON" and then parse the text response.

# Anti-pattern: asking for JSON in text output
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    messages=[{
        "role": "user",
        "content": "Extract action items as JSON: " + meeting_notes
    }]
)
# Fragile: parsing text as JSON
items = json.loads(response.content[0].text)

Why It Is Wrong

Text output is unstructured by definition. Claude might wrap the JSON in markdown code fences. It might include explanatory text before or after the JSON. The JSON might have trailing commas, unescaped characters, or inconsistent field names. Every one of these issues breaks json.loads().

You are also throwing away Claude''s ability to validate its own output against a schema. When Claude uses tool_use, it generates output that conforms to a defined schema. When it outputs text, it is freestyling.

The Correct Approach

Define a tool with the output schema you want. Claude will "call" the tool with structured, schema-conformant data.

# Correct: use tool_use for structured output
tools = [{
    "name": "record_action_items",
    "description": "Record extracted action items from meeting notes",
    "input_schema": {
        "type": "object",
        "properties": {
            "items": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "task": {"type": "string"},
                        "assignee": {"type": "string"},
                        "due_date": {"type": "string"}
                    },
                    "required": ["task"]
                }
            }
        },
        "required": ["items"]
    }
}]

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    messages=[{
        "role": "user",
        "content": "Extract action items: " + meeting_notes
    }],
    tools=tools,
    tool_choice={"type": "tool", "name": "record_action_items"}
)

Exam tip: This is probably the single most-tested anti-pattern on the exam. If a question involves structured output, look for the tool_use answer.

5. Silent Error Suppression

The Wrong Approach

Your agent calls a tool and the tool returns an error. Rather than surfacing the error to Claude or logging it, your code catches the exception and returns a default value. The agent continues as if nothing happened.

# Anti-pattern: swallowing errors silently
try:
    result = call_external_api(params)
except Exception:
    result = {"status": "ok", "data": []}  # Fake success

Why It Is Wrong

Silent error suppression creates cascading failures. The agent makes decisions based on data that does not exist. Downstream actions build on a foundation of default values. By the time anyone notices the output is wrong, the error is buried under layers of apparently normal behavior.

In production, this pattern is catastrophic. The system appears healthy -- no errors in logs, no alerts firing, all responses returning 200. But the output is garbage, and tracing the root cause requires forensic analysis of every step.

The Correct Approach

Surface errors to Claude so it can reason about them. Log errors for observability. If the error is recoverable, let the model decide how to recover. If it is not, escalate to a human.

# Correct: surface errors for reasoning
try:
    result = call_external_api(params)
except Exception as e:
    logger.error(f"API call failed: {e}")
    # Return the error to Claude as a tool result
    result = {
        "error": True,
        "message": f"The API call failed: {str(e)}",
        "suggestion": "Try an alternative approach or ask the user for help"
    }

Exam tip: Questions about production readiness and monitoring frequently test this pattern. The answer always involves surfacing errors, not hiding them.

The Pattern Behind the Patterns

Notice what these five anti-patterns have in common: they all involve taking shortcuts that work in demos but break in production.

• Text parsing instead of typed signals
• Prompts instead of deterministic enforcement
• Assumed context instead of explicit passing
• Unstructured text instead of schema-validated output
• Silent failures instead of observable errors

The CCA-F exam is fundamentally testing whether you can build production-grade Claude applications. Every anti-pattern question is asking: "Do you know the difference between something that works in a notebook and something that works at scale?"

Study these five patterns until you can spot them instantly. They will appear in questions across all five domains.

Practice With Real Scenarios

Our CCA-F exam prep course includes scenario-based practice questions for every domain, with detailed explanations of why wrong answers are wrong. If you want to drill anti-pattern recognition until it is automatic, start there.

Know the wrong answers as well as the right ones. That is what separates passing from failing.