CCAR-P Domain 1: Solution Design & Architecture

The first architectural fork is how much control you hand to the model. Three shapes sit on a spectrum of increasing autonomy and decreasing predictability: a single call (one request, one response — classification, extraction, summarization, a bounded Q&A), a deterministic workflow (your code owns the control flow and calls Claude at fixed steps, optionally with tools), and an agent (the model decides which tools to call and when, looping until it judges the task done).

A useful heuristic: if you can draw the control flow as a fixed flowchart in advance, you want a workflow, not an agent. If the path genuinely depends on what the model discovers mid-task — unknown number of steps, branching that can't be enumerated — that is where an agent earns its cost.

Because an agent is the most expensive and least predictable shape, an architect must be able to defend the choice. Run the decision through four gates — an agent is warranted only when all four point the same way:

• Complexity — is the task genuinely multi-step and hard to fully specify up front? 'Turn this design doc into a merged PR' qualifies; 'extract the invoice total from this PDF' does not.
• Value — does the outcome justify higher latency and token cost? Agents are worth it for high-value work, not for shaving seconds off a cheap lookup.
• Viability — is Claude actually capable at this task type today? If the model can't reliably do the sub-tasks, an agent just fails more elaborately.
• Cost of error — can mistakes be caught and recovered? Agents suit domains with tests, review gates, or rollback (code, research drafts). They are dangerous where an action is irreversible and unmonitored.

Cost of error deserves special weight at enterprise scale. An agent that can send customer emails, move money, or delete records without a gate is a liability regardless of how capable it is. The architect's job is to make the reversibility of each action an explicit design input, not an afterthought.

Once an agent is justified, the next decision is topology. A single agent holds all tools and context in one loop — simplest to build, reason about, and cache, and the right default. A coordinator / hub-and-spoke design has an orchestrator agent that delegates sub-tasks to specialized sub-agents, each with its own context window, tools, and often its own model tier.

Multi-agent shines when work fans out across independent items (review ten files in parallel, research five vendors) or when sub-tasks need genuinely different tool sets or personas. It costs you context isolation (sub-agents don't share conversation history — the coordinator must pass what they need explicitly), more moving parts, and harder end-to-end tracing.

• Single agent — one loop, shared context, one model tier. Default choice; easiest to cache and audit.
• Coordinator / hub-and-spoke — orchestrator delegates to sub-agents with isolated context. Use for parallel fan-out, heterogeneous tool sets, or per-sub-task model-tier optimization.
• Keep delegation shallow — deep nesting of agents spawning agents multiplies cost and makes failures nearly impossible to trace. Most enterprise designs stay one level deep.

A subtle win of hub-and-spoke: it lets you run each spoke on the cheapest model tier that clears the sub-task's bar while the coordinator reasons on a stronger tier — a lever a single-agent design can't pull without invalidating its prompt cache mid-run.

An enterprise agent must never simply stop in an undefined state. Design every autonomous flow so that each unit of work reaches a terminal guarantee: it either resolves the task or escalates it — never silently abandons it. This 'resolve-or-escalate' invariant is what makes an agent safe to run unattended.

Human-in-the-loop (HITL) placement is an architectural decision, not a UI detail. Put the checkpoint immediately before any high-cost, hard-to-reverse action — sending external communications, financial transactions, destructive data operations. Gate those behind approval; let cheap, reversible, read-only actions run automatically. Placing the gate too early throttles throughput; placing it too late defeats its purpose.

Design for idempotency. At scale, retries are inevitable — network blips, timeouts, at-least-once delivery, and the model's own re-attempts all mean the same action can fire twice. Every side-effecting operation should carry an idempotency key so a duplicate invocation is a no-op, not a double charge or a duplicate email.

• Assign a stable idempotency key per logical operation; dedupe on it server-side.
• Make tool results safe to replay — a retried create_order with the same key returns the existing order, it does not create a second.
• Return structured errors (is_error: true) rather than throwing away a failed step, so the agent can recover or escalate instead of looping blindly.
• Bound autonomous loops with an explicit iteration/step ceiling so a stuck agent escalates rather than burning budget.

A professional architect does not pick one model for the whole system — they pick a tier per component, matching capability to the sub-task's difficulty and the cost/latency budget. The current Claude tiers trade capability against price and speed roughly as follows (verify current model IDs and pricing at docs.claude.com):

In a hub-and-spoke design this becomes concrete: run the coordinator on Opus for planning and judgment, run a high-throughput classification spoke on Haiku, and run coding or analysis spokes on Sonnet. Validate the choice empirically — promote a component to a higher tier only when measured quality on its sub-task falls short, and demote when it clears the bar with headroom.

Never justify the choice on model name alone in an exam answer. Justify it on the sub-task's reasoning depth, its volume, its latency budget, and its cost of error.

At enterprise volume the three levers — cost, latency, and reliability — pull against each other, and the architect's design makes the trade explicit. Prompt caching amortizes a large stable prefix (system prompt, tool definitions, shared context) across many requests, cutting both cost and time-to-first-token; but it only pays off when the prefix is genuinely stable, so architect the prompt so volatile content sits after the cache breakpoint.

• Cache the stable prefix. Keep the system prompt, tool set, and shared context byte-stable and front-loaded; put per-request variability at the end. A single changed byte in the prefix invalidates everything after it.
• Stream long or high-`max_tokens` responses. Streaming avoids request timeouts on long outputs and improves perceived latency — a design consideration, not just an SDK flag.
• Bound spend with effort and budgets. Lower reasoning effort on routine sub-tasks and reserve high effort for the components that need it; cap long agentic loops so a runaway agent degrades gracefully instead of billing indefinitely.
• Isolate failure domains. A degraded downstream tool should fail one step and escalate, not cascade into a whole-session failure.

Not every workload is interactive. When a use case tolerates delayed results — nightly document classification, bulk enrichment, offline evaluation, large-scale content generation — the Message Batches API processes requests asynchronously at roughly half the per-token cost of synchronous calls, with results typically available within an hour (and a hard ceiling measured in hours). Choosing batch over sync for the right workloads is a pure architectural win: lower cost, higher throughput, no user waiting.

Because batch results arrive in arbitrary order, design the consumer to key each result by the custom_id you assigned, never by position. That is the same discipline as idempotency: build the system so ordering and retries can't corrupt the outcome.