Most CCA-F prep material treats the exam like a trivia list: memorize what prompt caching does, know the MCP spec by name. That covers maybe half the exam. The other half is scenario-based — the exam guide publishes 6 full scenarios, and every real attempt draws 4 of them, then asks you to reason about architecture decisions inside that scenario.
This is the first in a 6-part series walking through each one, with a working reference implementation you can actually run — not just a diagram. Full source: aicert-labs/cca-f/scenario-1-customer-support-agent.
The scenario, as written in the exam guide
A support agent built on the Claude Agent SDK handles returns, billing disputes, and account questions through custom MCP tools — get_customer, process_refund, escalate_to_human — targeting 80%+ first-contact resolution.
It touches three domains at once, which is exactly why CCA-F uses scenarios instead of isolated questions — real architecture decisions rarely sit inside a single domain.
| Domain | Weight | Where it shows up in this scenario |
|---|---|---|
| Agentic Architecture & Orchestration | 27% | The loop that lets Claude call tools, read structured results, and decide whether to keep going or hand off |
| Tool Design & MCP Integration | 18% | Three tools with a real MCP server — and specifically, how process_refund reports failure |
| Context Management & Reliability | 15% | What stops the agent from looping forever, and what the system prompt does vs. what the tool enforces |
The one design decision worth studying
A naive version of process_refund takes an order ID and an amount, and the system prompt says "only refund under $100." That's fragile: it depends on the model reading and obeying prose instructions on every single call, with nothing enforcing it. Raise the limit, tweak the prompt elsewhere, or just get an off day from the model, and the rule silently stops holding.
The reference implementation moves the rule into the tool itself. process_refund doesn't refund-or-error — it returns a typed signal:
{ "needs_escalation": true, "reasonCode": "over_auto_approve_limit", "orderAmountUsd": 219, "priorRefunds": 2 }
The agent's job becomes mechanical: see needs_escalation, call escalate_to_human. There's no prose to misread. This is the gap between "prompting an agent to behave" and "designing a tool it can't misuse" — and it's precisely the kind of judgment CCA-F scenario questions are built to test.
What stops the agent from looping forever
The second failure mode this scenario is designed to surface: an agent that calls process_refund, gets told to escalate, and just... tries process_refund again. Or again. Two things in the reference implementation guard against this:
- The system prompt is explicit that a
needs_escalation: trueresult is not a retry signal — it's a routing signal toescalate_to_human. agent.tscaps the loop at a fixed number of turns and logs a warning if it's hit, instead of running indefinitely. On a real exam question, "the agent has no bounded retry logic" is exactly the kind of reliability gap you'd be expected to flag.
Run it yourself
git clone https://github.com/AICERT-STUDY/aicert-labs
cd aicert-labs/cca-f/scenario-1-customer-support-agent
npm install
cp .env.example .env # add your ANTHROPIC_API_KEY
npm run agent -- cust_1001 ord_9001 "the keyboard arrived with a broken key" # auto-approved
npm run agent -- cust_1002 ord_9002 "these headphones stopped charging" # forces escalation
The README in that folder has a few suggested edits to try (lower the auto-approve limit, remove the typed needs_escalation field and watch the agent misbehave) if you want to see the failure modes, not just read about them.
Test yourself
1. In the reference implementation, why does process_refund return needs_escalation: true instead of throwing an error when the amount is over the limit?
Answer: B) A typed result lets the agent branch programmatically, instead of depending on the model correctly interpreting an error message.
An error string still requires the model to read and correctly react to prose. A structured field is something the calling code (or the model's own reasoning over structured tool output) can check deterministically.
2. Which domain does the 8-turn cap in agent.ts primarily address?
Answer: Context Management & Reliability.
It's not an architecture-orchestration decision (that's the tool-calling loop itself) or a tool-design decision (that's the MCP server) — it's a guardrail against an unbounded agentic loop, which is a reliability concern.
3. The scenario asks for 80%+ first-contact resolution. Which tool design choice most directly supports that target?
Answer: Requiring get_customer before any account action, so the agent always has verified context before acting.
First-contact resolution drops sharply when an agent acts on stale or wrong account data and has to backtrack. Verifying identity and pulling order history up front is what makes single-pass resolution possible.
4. A customer with 2 prior refunds requests a $30 refund — well under the $100 auto-approve limit. What happens?
Answer: The tool still returns needs_escalation: true, because the repeat-refund threshold is checked independently of the amount.
This is deliberate: a customer above the repeat-refund threshold gets routed to a human regardless of the amount, because the behavior pattern — not the dollar amount — is the signal worth a human review.
5. If you swap the MCP server's mock CRM for a real one, what in this architecture has to change?
Answer: Only the implementation inside mock-crm.ts — the tool contracts in mcp-server.ts and the agent loop in agent.ts stay the same.
That's the point of putting the business rule inside the tool boundary: the agent and the MCP tool interface don't know or care whether the data comes from an in-memory object or a real CRM API.
Free CCA-F practice exam, covering all 5 domains: aicert.study/certifications/ccaf.