CCAR-P solution design: patterns, decomposition, value

17% of the exam — about 11 of the 63 questions — across 6 sub-objectives.

Domain 1 decides whether you design systems or assemble components. The questions rarely ask what something is. They hand you a partner who has already named the solution they want, a discovery finding that contradicts it, and four architectures. The credited one is usually smaller than the one you were asked for.

One habit carries most of this domain: work out which part of the problem needs a model before choosing a shape for the whole thing. Most wrong answers here are competent designs applied one level too broadly.

This domain did not feel heavy to me on the day, and the score report explains why in a way I had not expected: all six sub-objectives appeared, and I scored 100% on every one. Fully sampled and none of it hard. That is the opposite of integration, where fewer sub-objectives showed up and the ones that did were the toughest questions on the paper.

Translate business problems into Claude-based AI solutions

Every scenario here opens the same way. Someone with budget names an artifact. We need a chatbot. We want an agent that handles claims. The named artifact is rarely the credited answer, and it appears because that is what happens on real discovery calls.

The exam wants the move from stated request to measured bottleneck, and it hands you the evidence in a sentence that is easy to skim. Adjusters spend seventy per cent of their time reading files before deciding anything. The backlog is six weeks. Nobody is waiting on a screen while the job runs. That figure is the question. The credited architecture attacks the number, and the distractors attack something adjacent that a reasonable person would also want.

The second half of translation is deciding what the model is trusted to own. Split the request into parts and put each part somewhere: work the model should do, work an existing system already does correctly, and work a human keeps. Three questions settle most of it. Can a wrong call be undone? What does a wrong call cost? Who answers for it?

The expensive mistake is handing the model a rule that already exists in code. Priority tiers, coverage tables, eligibility thresholds: the partner defines these, maintains them, and changes them without telling you. Moving one inside the model costs more per call, fails in ways nobody can trace, and goes stale silently, because the model cannot know the table changed and will not flag it. A deterministic rule fails predictably, which is worth keeping on purpose rather than giving up by accident.

Design end-to-end architectures (input → processing → output → feedback loops)

The trap here is answering a question about one layer with a decision from another. Three separate choices sit behind every deployment, and different people make them for different reasons.

The entry point is what a person or system touches: the desktop app, Claude Code, your own application. You choose it for the user and the work. The build-time interface is what your engineers write against, meaning the API, an SDK, or MCP. You choose it for the team and the integration. The delivery route is whose infrastructure the request terminates on, whether Anthropic directly or a cloud provider. You choose it for compliance posture and existing cloud commitments.

A scenario that says the customer is on AWS with a signed commit and a data residency requirement is telling you about the delivery route. It says nothing about which SDK to use, and options answering with an SDK are answering a different question. Read what the constraint actually constrains.

The other half of this sub-objective is feedback loops, which the title names and most study plans drop. An architecture that ends at output is incomplete. Where does a wrong answer get noticed, who notices it, and what happens next? A design with no path from a bad output back to the thing that produced it cannot improve, and questions asking what is missing from a proposed architecture often want exactly that.

Keep the parts as an inventory rather than a vocabulary: tools to act, MCP to expose them, subagents to isolate, hooks to guarantee, skills to package a procedure. When someone says we will use an agent, five people picture five different assemblies. The exam exploits that ambiguity, so name the assembly rather than the label.

Select appropriate architectural patterns (workflow, agentic, augmented LLM)

A workflow is a path you wrote down. An agent is a path the model chooses at run time. Almost every question in this sub-objective turns on that difference.

The exam asks it in one direction far more often than the other. It hands you something already described as an agent and asks whether it should be. The scenarios that look agentic usually contain a phrase like the steps are the same every time, or the sequence is defined by regulation, or a count: twelve thousand invoices, every night. Fixed steps and predictable volume are a workflow. Reaching for an agent there buys non-determinism you then spend the rest of the design constraining.

Agents earn their cost when the path cannot be written in advance. Open-ended research, triage where the next step depends on what the last one found, work where the number of iterations is unknown. The tell is that you cannot draw the flowchart, which is different from the problem being hard.

The augmented LLM sits between them and is the most under-picked answer on the exam. One model call with retrieval, tools, and memory attached is a legitimate architecture, and for a great many problems it is the correct one. Candidates skip it because it does not feel like an architecture.

Two habits are worth building. When a scenario mixes both kinds of work, the answer is usually a fixed workflow with a model call at the one genuinely fuzzy step, such as extraction from a document or a judgement on tone, rather than an agent wrapped around everything. And when an option offers to make an agent safer with retries, validation, or a confirmation step, ask whether the scenario ever needed the agent. Adding controls to an unnecessary agent is the most attractive wrong answer in this domain.

One habit worth naming, because it cost me marks elsewhere on the paper: given a failure, I reached for the mitigation that reduces how often it happens rather than the change that stops it being generated. Retries instead of a durable queue. A summarizer instead of not feeding the coordinator raw data. Both are things I would genuinely ship, and both leave the failure in place. The question that catches it is whether your answer still lets the failure keep occurring.

Design multi-agent systems and orchestration strategies

Multi-agent questions hinge on one asymmetry. A subagent failing is recoverable. An orchestrator failing usually is not. Once you have that, most of these questions resolve quickly.

The orchestrator owns the goal. It decomposes the work, delegates it, and synthesizes what comes back, and it does not do the sub-task work itself. Each subagent owns one scoped piece in its own context and returns a result. Three things have to be designed rather than assumed: how the work splits, what shape each result comes back in so it can be combined, and what happens when two results disagree.

That last one gets missed most often. Conflict resolution is a design decision. If nothing in the architecture says what happens when two subagents return contradictory findings, the orchestrator will quietly pick one.

The asymmetry drives the design. Subagent work should be idempotent and retryable, because you will retry it. Orchestrator state should be checkpointed and protected, because losing it strands every piece of completed work underneath. When an option offers to make a fan-out more reliable by validating subagent output, ask whether the run survives the orchestrator dying halfway. That is the failure that costs everything.

Two more the exam rewards. Traces fragment across agents unless a shared identifier is propagated, so a run you cannot reconstruct end to end is an observability gap worth naming. And cost multiplies, since every subagent carries its own context and the orchestrator pays again to synthesize. Reach for this pattern when the work will not fit in one context, such as a corpus, a codebase, or a regulatory filing, not because the problem feels important. The discipline is the fewest agents that meet the requirement, with one unambiguous owner of the goal.

Apply decomposition techniques for complex problem solving

Decomposition here means breaking the problem into steps and assigning each step an owner. What you are working toward is a delegation map rather than an outline.

Take a request phrased as one capability: read the claim, decide priority, look up coverage, email the adjuster. Four verbs belonging in four different places. Reading and interpreting the claim is language work with a constrained output, which is what the model is for. Deciding priority looks like judgement but is a rule the partner already owns. Looking up coverage is the same with higher stakes, because the table changes and the model will not know. The last one is two steps wearing one verb: drafting the message is language work, sending it belongs to the mail system, and somebody should approve it in between.

Noticing a step that has to be split before it can be assigned is the move the exam tests most and candidates miss most. When a step contains both a judgement and an action, they rarely belong to the same owner.

At each part, ask whether the model beats the system that already does this correctly. The looser version of the question, where Claude could help, always has an answer, and answering it leaves you designing something larger than the problem. Asked the stricter way, most steps stay where they are and the design gets smaller, which is usually the direction the credited answer sits in.

Align solutions to business value pillars (efficiency, transformation, productivity, cost, performance SLAs)

This sub-objective sounds like business fluff and carries real marks. The published pillars are efficiency, transformation, productivity, cost, and performance SLAs, and the exam expects you to connect a design to the one it serves.

Efficiency and transformation carry the most weight. Efficiency is doing the existing process faster or cheaper, the same work with less of something. Transformation is doing something the organization could not previously do at all. A summary saving adjusters two hours a day is efficiency. Reviewing every claim instead of a ten percent sample, because review is now cheap enough to do exhaustively, is transformation. Same technology, different case, and they justify very different budgets.

Two failure modes show up in the options. One is a design serving a pillar nobody in the scenario asked for, which is impressive and unfunded. The other is a claimed benefit with nothing in the architecture that would produce it, such as a solution said to reduce cost while adding a model call to a path a database query already handled.

Performance SLAs get skipped in study and are concrete on the exam, because an SLA is a number you either designed for or did not. If a scenario names a latency ceiling or a completion deadline, that number constrains the architecture, and options ignoring it are wrong however good they look otherwise.

I was unsure whether this was tested directly, since the course material covers it more lightly than the rest of the domain. The score report settles it: value pillars appeared on my form as their own sub-objective. Treat it as examinable rather than as framing.