Building Effective Agents with Claude: A Production Guide
A practical guide to building effective agents with claude: architecture patterns, tool design, guardrails, and what the CCAR-F exam rewards in every scenario.
By Solomon Udoh · AI Architect & Certification Lead

Building effective agents with claude is less about raw model capability than about the decisions made before the first API call: which architecture fits the task, how tools are described, and where the agent must pause rather than proceed. The CCAR-F exam, a 60-item proctored assessment launched on 12 March 2026, tests precisely those judgement calls. Domain 1, Agentic Architecture and Orchestration, carries 27% of the exam weight, more than any other domain, which reflects how central these decisions are in production systems.
This guide covers the patterns that separate reliable agents from brittle ones, and maps each practice to the exam domain where it is assessed.
What is the simplest agent architecture that actually works?
Start with a single agent plus well-designed tools. Single-agent designs are easier to debug, cheaper to run, and sufficient for the majority of production tasks. Escalate to multi-agent coordination only when a task genuinely exceeds one context window, requires work that would block serially but runs faster in parallel, or needs independent verification of critical outputs.
Anthropik groups agentic patterns into three broad shapes. The table below maps each to its canonical context and the key risk to manage.
| Pattern | When to use it | Key risk |
|---|---|---|
| Single agent + tools | Task fits one context window; steps are linear | Tool overload dilutes routing accuracy |
| Sequential pipeline | Stages are well-defined; output feeds cleanly into input | Errors compound; no mid-pipeline branching |
| Hub-and-spoke multi-agent | Long-horizon tasks; parallel workstreams; specialised roles | Coordination overhead; attribution loss in synthesis |
For sequential work, fixed sequential pipelines (prompt chaining) excel when every step is known at design time. When the task structure is unknown until partway through execution, dynamic adaptive decomposition lets the coordinator revise the plan based on intermediate results.
The CCAR-F exam consistently rewards proportionate solutions. Choosing a multi-agent system when a single agent with three well-scoped tools would suffice is treated as an architectural anti-pattern, not sophistication. Each sitting draws four scenarios at random from a bank of six, and the scenario bank is weighted toward this exact judgement call in Domain 1.
How should you design tools so Claude routes calls correctly?
Tool descriptions are the primary routing signal: Claude selects among available tools based on their descriptions, not their names. A vague description such as "fetch data" is not a tool description; it is an ambiguity bug that will manifest as a wrong API call under real traffic.
Three rules tighten tool routing:
- State what the tool does AND what it does not do in the same description.
- Give each tool a distinct semantic surface. Shared vocabulary between tools causes calls to be distributed unpredictably.
- Prefer narrow, specific tools over broad, generic ones.
# Vague -- high misrouting risk{'name': 'search','description': 'Search for information.'}# Specific -- lower misrouting risk{'name': 'search_orders_by_customer_id','description': ('Returns all orders placed by a single customer, identified by customer_id. ''Do NOT use for date-range queries or product-level searches; ''use search_orders_by_date_range or search_products instead.')}
Writing effective tool descriptions covers the full decision framework. When an agent routes calls to the wrong tool, the fix is almost always a description edit rather than a system-prompt rewrite. Domain 2 (Tool Design and MCP Integration, 18% of the exam) labels this the low-effort, high-leverage principle, and the exam tests it through scenarios where the obvious fix is the cheapest one.
Schema design follows the same discipline. A JSON schema that permits nullable fields everywhere makes every field optional in practice. Tighten required arrays, constrain enum values to valid options, and structured output errors fall sharply without any model change.
How do you make Claude agents production-safe?
Production safety for Claude agents rests on three layers: minimising blast radius, preserving human oversight, and preferring reversible actions. These are not abstract principles; they map directly to architectural choices.
In agentic contexts, Claude should request only necessary permissions, avoid storing sensitive information beyond immediate needs, prefer reversible over irreversible actions, and err on the side of doing less and confirming with users when uncertain about intended scope in order to preserve human oversight and avoid making hard-to-fix mistakes.
Concretely, this means building explicit confirmation steps before irreversible actions such as database writes, external API calls that trigger billing, or file deletions. Do not rely on the system prompt alone to prevent these.
The high-stakes enforcement decision rule is directly testable on the CCAR-F: when the consequence of a wrong action is irreversible, enforcement must be programmatic, a hard gate in code, rather than prompt-based. Prompt-based enforcement degrades under adversarial inputs and model updates; code-based gates do not. The exam rewards this distinction consistently across Domain 1 scenarios.
For teams working with Claude Code, the three-level configuration hierarchy at user, project, and local scope provides a structured place to declare which operations the agent may and may not perform. This is tested in Domain 3, which carries 20% of the exam weight.
How do you handle observability in long-running agent tasks?
Reliable agents must be observable. An agent that fails silently is more dangerous than one that fails loudly. Three practices underpin good observability in production.
Structured tool results. Return machine-readable error metadata rather than bare strings. A JSON error payload with a code, message, and retryable field gives the orchestrator the information it needs to route, retry, or escalate intelligently. Bare strings force the model to parse natural language, which reintroduces the ambiguity that good tool design removes.
{"is_error": true,"content": [{"type": "text","text": "{\"code\": \"RATE_LIMITED\", \"message\": \"Upstream API returned 429\", \"retryable\": true, \"retry_after_ms\": 5000}"}]}
The MCP isError flag pattern distinguishes tool-level failures from empty-but-valid results, a distinction that matters when a database query legitimately returns zero rows.
Stop-reason inspection. Every response from the Messages API includes a stop_reason field. An orchestrator that does not inspect this field and branch accordingly is missing the primary signal for whether the agent has finished, hit a tool call, exceeded the token limit, or been stopped. Ignoring stop_reason is one of the most common agentic loop anti-patterns the exam tests, because the failure mode is subtle: the loop appears to run but exits too early or loops indefinitely.
Context freshness. In extended sessions, early context degrades in influence as the context window fills. Structured handoffs and fresh sessions with injected summaries are the production-grade solution. The full range of context management strategies, from resuming sessions to forking or starting fresh, carries 15% of the exam weight in Domain 5.
How do you reduce cost and latency from tool loops?
Every tool call adds latency, tokens, and a failure point. Four practices reduce unnecessary calls without reducing capability.
First, design tools that return complete, actionable results in a single call rather than requiring follow-up queries. A tool that returns an order with its line items and current status in one response eliminates two additional calls that a bare order-lookup tool would require.
Second, batch where the API permits. Anthropic's Message Batches API processes requests asynchronously at half the price of synchronous calls, making it the primary cost lever for high-volume, non-latency-sensitive workloads such as classification or extraction pipelines.
Third, choose the right model for the task. The CCAR-F's five-domain structure rewards architects who match model capability to task complexity. A heavyweight model on a simple formatting task is both slower and more expensive without being more accurate.
Fourth, tighten tool descriptions to reduce misrouted calls. When descriptions are precise, the model calls the right tool on the first attempt. Each misrouted call that triggers a correction costs additional tokens and latency. The investment in description quality pays off on every subsequent request across the entire production workload.
How do you manage agent state across sessions?
State management is where production agents accumulate hidden debt. Two strategies cover most cases.
For tasks that complete within a single context window, pass all relevant state as structured context in the initial prompt. This is the cleanest approach: no external storage and no synchronisation bugs.
For long-horizon tasks that span multiple sessions, externalise state explicitly. Write completed-step manifests to durable storage, and inject a structured summary at the start of each new session. Summary injection for fresh sessions describes this pattern in detail. The injected summary should be structured data rather than prose; a prose summary reintroduces the same ambiguity that ambiguous tool descriptions cause.
Avoid the progressive summarisation trap: repeatedly summarising prior summaries degrades detail at each pass. After two or three passes, the injected context can omit the specifics the model needs to continue the task correctly.
When should an agent stop and ask for help instead of continuing?
Stop and escalate when the task is under-specified, when a required permission is absent, or when the next action is irreversible and confidence in its correctness is low. These are the three valid escalation triggers. Acting on ambiguity by guessing is a fourth option, and it is the one the CCAR-F exam consistently penalises across Domain 1 scenarios.
Structured handoff to human agents covers the mechanics: what data to surface in the escalation, how to preserve partial state so a human can resume the task, and how to avoid the common failure of dumping raw context at the reviewer without structure.
The corollary matters equally: an agent that escalates on every ambiguity is not cautious; it is broken. The exam rewards calibrated judgement, not maximum conservatism. The goal is knowing precisely when human oversight adds value and when it is friction that slows the system without reducing risk.
What does the CCAR-F exam test about building agents?
The Claude Certified Architect Foundations exam covers agentic system design across all five of its domains. At 720 out of 1000, the passing threshold rewards consistent practical judgement rather than isolated recall. The exam costs $125 per attempt, and the credential is valid for 12 months from the date it is awarded.
| Domain | Weight | Core agentic topics |
|---|---|---|
| 1: Agentic Architecture and Orchestration | 27% | Patterns, session management, decomposition, enforcement |
| 2: Tool Design and MCP Integration | 18% | Tool descriptions, error responses, MCP scoping |
| 3: Claude Code Configuration and Workflows | 20% | Configuration hierarchy, hooks, slash commands |
| 4: Prompt Engineering and Structured Output | 20% | Schema design, few-shot examples, output reliability |
| 5: Context Management and Reliability | 15% | Context windows, summarisation, stale-context mitigation |
Our concept library at /concepts maps 174 atomic concepts to the 30 task statements across these five domains. Each practice in this guide traces to a specific exam objective, and the adaptive engine uses Bayesian Knowledge Tracing with a 0.90 mastery threshold to direct your prep toward the concepts where you have the most ground to cover. As of 3 June 2026, more than 10,000 individuals have earned Claude Partner Network certifications; the architecture track is where production judgement is most heavily tested.
AI Skill Certs is an independent prep platform and is not affiliated with, endorsed by, or approved by Anthropic.
Frequently asked questions
How many items does the CCAR-F exam have and how long is the time limit?
What are the most common reasons Claude agents fail in production?
What is the difference between prompt-based and programmatic enforcement in Claude agents?
How does the CCAR-F exam assess structured output and schema design?
Can I use AI Skill Certs to prepare for the CCAR-F architect exam?
People also ask
How do you build an AI agent with the Claude API?
What is the best architecture for a Claude multi-agent system?
How does Claude decide when to call a tool?
What is the Claude Certified Architect exam?
How do Claude agents handle errors returned by tools?
About the author
AI Architect & Certification Lead
Solomon Udoh is an AI Architect who designs and ships production agent systems on the Claude API and Claude Code. He built AI Skill Certs' adaptive engine and authored its 174-concept knowledge graph, mapping every Claude Certified Architect - Foundations objective to hands-on, exam-aligned practice.
- Designs production multi-agent systems on the Claude API and Agent SDK
- Author of the AI Skill Certs knowledge graph (174 mapped exam concepts)
- Builds with MCP, Claude Code, structured outputs, and agentic loops daily
- Reviews every concept page against the official Anthropic exam guide
You might also like
Ready to put it into practice?
Study every exam concept with an adaptive tutor.