Real CCAR-F scenario. Fully deployed on AWS.

Customer Support Resolution Agent Claude Certified Exam Project

Do not just memorize the Claude Certified Architect – Foundations objectives. Use a real application that verifies customers, looks up orders, grants service credits, enforces refund policy, and creates structured human handoffs.

The live DashAway support agent is connected to a working REST endpoint on AWS. It supports a real em-dash removal product, authenticated accounts, order data, credit balances, and policy-constrained resolutions.

Claude Java Spring AI AWS REST API Cognito DynamoDB MCP-ready tools

Customer Support Resolution Scenario

Talk to the deployed support agent.

The component below calls the AWS-hosted DashAway support API and runs the same type of multi-step resolution workflow described by the CCAR-F exam objectives.

Try a product complaint, a duplicate-charge concern, a request for credits, a refund request, or an explicit request for a human.

Loading customer support…

What happens behind the chat

A complete resolution workflow, not a chatbot wrapper.

This is the part I especially wanted to make tangible: not just a bot response, but a real workflow that shows reasoning, extraction, tool use, policy enforcement, error handling, and escalation.

01 Case intake

An intake agent extracts order ID, issue types, requested resolution, and human-support intent into a structured SupportCase.

02 Coordinator reasoning

The support coordinator evaluates the conversation and chooses the next safe action instead of following a hard-coded script.

03 Scoped tools

Tools verify the customer, retrieve the purchase, resolve the issue, process an eligible refund, or escalate to a human.

04 Deterministic controls

Code blocks unverified access, wrong-customer orders, repeat compensation, excessive usage, and refunds above policy limits.

05 Resolution or handoff

The agent returns a concise customer response or a structured handoff containing the customer, order, reason, and recommended next action.

The product behind the support case

Now use the em-dash remover.

The support agent is not solving imaginary tickets. It supports this working credit-based application, which uses Claude and deterministic validation to remove em dashes.

Loading the punctuation removal apparatus...

Project-driven learning

Learn every objective in the context of software you can run.

Each concept is attached to a decision you can see, a class you can read, a tool you can call, a failure you can reproduce, or a deployment you can inspect.

You will not study agentic loops, tool descriptions, structured output, context management, and escalation as disconnected vocabulary. You will build them into one coherent AWS application.

5
Exam domains connected
2
Working agent experiences
1
Deployed end-to-end project

Build, break, inspect, improve

Follow the same workflow used by real architects: define boundaries, implement tools, wire agents, enforce policy, test failure modes, deploy to AWS, and evaluate the result.

CCAR-F exam objective map

How the project covers the Claude Certified Architect objectives.

“Live project” items are visible in the deployed application. “Course lab” items extend the same codebase so even broader objectives remain grounded in one project.

Live project Course lab

Domain 1

Agentic Architecture & Orchestration

  • 1.1 Live
    Follow model-driven action selection, tool execution, and continuation until a customer-facing response is complete.
  • 1.2 Live
    Use a case-intake agent and support coordinator with clear responsibility boundaries.
  • 1.3 Lab
    Extend the coordinator with explicit context passing, Task-based subagent spawning, and isolated agent definitions.
  • 1.4 Live
    Enforce customer verification before purchase lookup and produce structured human handoffs.
  • 1.5 Lab
    Add tool interception and PostToolUse normalization for policy and data-shape guarantees.
  • 1.6 Live
    Decompose multi-concern support messages into issues, investigations, and one synthesized resolution.
  • 1.7 Lab
    Use named sessions, resumption, and forks while evolving the implementation.

Domain 2

Tool Design & MCP Integration

  • 2.1 Live
    Design distinct tools for customer verification, purchase lookup, issue resolution, refunds, and escalation.
  • 2.2 Live
    Return structured transient, validation, business, and permission errors with retryability metadata.
  • 2.3 Live
    Keep the support agent’s tool set tightly scoped and make tool-choice behavior explicit.
  • 2.4 Lab
    Expose the same support capabilities through MCP and configure project-scoped servers for Claude Code.
  • 2.5 Lab
    Use Read, Write, Edit, Bash, Grep, and Glob to trace and modify the real codebase incrementally.

Domain 3

Claude Code Configuration & Workflows

  • 3.1 Lab
    Organize project, directory, and user guidance with CLAUDE.md and imported rules.
  • 3.2 Lab
    Create project skills and slash commands for tests, deployment, support evaluation, and release checks.
  • 3.3 Lab
    Apply path-specific rules to Java, frontend web components, tests, and infrastructure files.
  • 3.4 Lab
    Use plan mode for architecture changes and direct execution for narrowly scoped fixes.
  • 3.5 Lab
    Improve prompts and tools iteratively with concrete conversations, tests, and failure feedback.
  • 3.6 Lab
    Run independent Claude Code review and structured checks in CI/CD.

Domain 4

Prompt Engineering & Structured Output

  • 4.1 Live
    Use explicit refund, apology, compensation, and escalation criteria instead of vague instructions.
  • 4.2 Lab
    Add few-shot examples for ambiguous requests, multiple issues, and boundary cases.
  • 4.3 Live
    Extract a schema-constrained SupportCase and use typed tool inputs and outputs.
  • 4.4 Live
    Validate tool prerequisites and use specific error feedback to guide safe recovery.
  • 4.5 Lab
    Batch-evaluate support transcripts and correlate results with custom identifiers.
  • 4.6 Lab
    Use independent review and multi-pass analysis for prompts, Java tools, and integration behavior.

Domain 5

Context Management & Reliability

The support scenario makes context reliability visible because customer facts, order facts, prior offers, tool errors, and human escalation all affect the next action.

  • 5.1 Live Preserve a compact CASE FACTS block alongside the evolving conversation.
  • 5.2 Live Escalate immediately on explicit human requests and ask for clarification when key identifiers are missing.
  • 5.3 Live Propagate structured error category, retryability, attempted action, and customer-safe explanation.
  • 5.4 Lab Use subagents, summaries, and scratchpads to explore and evolve the multi-file project without losing key findings.
  • 5.5 Lab Build human review and confidence calibration around support evaluation cases.
  • 5.6 Lab Preserve claim, source, date, and test-case provenance in evaluation and architecture reports.

Build the scenario. Understand the exam.

From exam objective to working architecture.

Use the support agent, use the product it supports, inspect the decisions, and then build the same patterns with me using Claude, Java, Spring AI, MCP concepts, and AWS.