Solution Design & Architecture·Task 1.2·Bloom: analyse·Difficulty 3/5·8 min read·Updated 2026-07-14

Composing Two Reference Architectures Deliberately (CCAR-P)

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

SUBy Solomon UdohReviewed by Solomon UdohAI-assisted · human-reviewed
In short
Composing two reference architectures is justified when two parts of a problem fail in genuinely different ways worth managing separately. Reaching for a second pattern because the problem is still undefined is a deferred design decision, not a valid composition. Composition roughly doubles the surface area to maintain and requires a separate evaluation set per component, because a system that looks healthy in aggregate can hide a failing component.

When one shape is not enough

Real partner problems frequently sit at the boundary between two reference architectures. A routing workflow might hand certain intents to an agentic investigation loop; a document pipeline might use RAG over policy text when it hits an exception. The Claude Certified Architect - Professional (CCAR-P) exam treats composition as an analyse-level skill because drawing on more than one pattern is sometimes exactly right, and sometimes a way of avoiding a decision. What separates the two is not whether the patterns fit together technically, but why you are reaching for the second one.

Composition is justified when two parts of the problem break in genuinely different ways that are worth managing separately. If one part fails through stale retrieval and another fails through an unbounded reasoning loop, those are distinct failure modes that distinct patterns handle, and managing them separately is sound engineering. The key phrase is genuinely different failure modes: the second pattern earns its place by addressing a failure the first cannot.

Composing reference architectures
Deliberately combining two reference architectures because two parts of a problem fail in genuinely different ways worth managing separately. It is valid only when each pattern addresses a distinct failure mode; reaching for a second pattern because the problem is undefined is a deferred design decision. Composition roughly doubles the maintenance surface and requires a separate eval set per component.

The deferred decision in disguise

The failure mode is reaching for a second pattern because you have not decided what the problem actually is. When a problem is still undefined, adding a second architecture feels like covering more ground, but it is really deferring the decision about what the system needs to do. That is not a composition, it is an undecided design wearing the costume of one. The tell is that you cannot state the distinct failure mode the second pattern addresses; you added it to hedge, not to solve something specific. In that case, the right move is to adapt a single pattern and finish deciding the problem, not to bolt on a second.

Composition is not free

Every added pattern has a price. Composing two reference architectures roughly doubles the surface area you must build, monitor, and keep correct: two sets of components, two sets of failure modes, two things that can drift as the workload changes. This is why the default, when in doubt, is to pick one. The cost is not just implementation; it is the ongoing maintenance of a larger system whose parts can degrade independently. A second pattern that does not earn its place through a distinct failure mode is pure added liability.

Per-component evals or you are flying blind

The subtler cost is evaluation. Each reference architecture carries its own eval contract, so a composed system needs a separate eval set per component, not a single end-to-end score for the whole. The reason is that aggregate health can mask a failing component: if the retrieval half degrades but the reasoning half compensates, an end-to-end metric may still look acceptable while one half is quietly broken. Only a per-component eval reveals which part is failing, and it reveals it before a user does. A composed system evaluated with one overall score is a system whose failures you will discover from complaints rather than metrics.

2 failure modes
the test for justified composition
2x surface
composition roughly doubles what you maintain
per-component evals
a single aggregate score hides a failing part

What the CCAR-P exam trips candidates on

The exam tests two traps. The first is composing retrieval and an agent pattern to avoid deciding what the system actually needs to do. A scenario will present a hedge, "we'll use RAG and an agent to be safe", and the credited answer identifies it as a deferred decision, since no distinct failure mode is named for the second pattern, and prefers adapting a single pattern once the problem is defined.

The second is evaluating a composed system with a single end-to-end score instead of per-architecture eval sets, masking a failing component. A scenario will show a composed system reported as healthy on one aggregate metric, and the reliable reading notices that a per-component failure could be hidden and calls for a separate eval set per architecture.

Worked example

A team proposes a system that both retrieves from a policy corpus and runs an open-ended agent loop, describing it as 'RAG plus an agent for flexibility.' They plan to measure it with one end-to-end accuracy score. Asked to justify the composition, they cannot name what the agent handles that retrieval does not. What do you conclude?

Test the justification first. Valid composition requires two parts of the problem that fail in genuinely different ways, and the team cannot name the distinct failure mode the agent addresses. "For flexibility" is not a failure mode; it is a hedge. That is the signature of a deferred design decision, reaching for a second pattern because the problem itself is still undefined, rather than a deliberate composition solving something specific.

The recommendation is to finish defining the problem before adding patterns. If the work is answering questions from a stable policy corpus, RAG alone fits and the agent is added liability, roughly doubling the maintenance surface for no named benefit. If discovery later reveals a genuinely open-ended part with its own failure mode, the agent can be added then, justified by that specific need.

Their evaluation plan compounds the problem. A single end-to-end accuracy score would let the retrieval half degrade while the agent half compensates, or vice versa, with the aggregate still looking acceptable, so a failing component stays hidden until users notice. Even a justified composition needs a separate eval set per architecture. Here, the fix is to collapse to one pattern; if composition were warranted, per-component evals would be mandatory, not optional.

Common misreadings to avoid

Misconception

Combining two patterns is safer because it covers more scenarios.

What's actually true

A second pattern added without a named distinct failure mode is a deferred decision, not a safety margin. It roughly doubles the maintenance surface for no benefit. Composition is justified only when two parts of the problem genuinely fail in different ways worth managing separately.

Misconception

A composed system is healthy if its end-to-end score is good.

What's actually true

An aggregate score can look healthy while one component fails, because other components compensate. Each reference architecture carries its own eval contract, so a composed system needs a separate eval set per component to reveal which part is degrading.

How this shows up on the exam

Domain 1 questions on this knowledge point present a multi-pattern proposal and ask whether the composition is justified and how it should be evaluated. The reliable reading checks that each pattern addresses a genuinely distinct failure mode, rejects composition used to defer an undecided problem, and requires a separate eval set per component rather than a single end-to-end score.

Composition builds on the five reference architectures and feeds end-to-end trade-off analysis, which walks a full pipeline naming the trade-off at each stage. The per-component eval discipline ties directly to gating value claims with evaluation, and the granularity judgement echoes decomposition granularity.

Check your understanding

A partner's system composes a routing workflow with an agentic investigation loop: routine tickets follow fixed paths, while a small class of complex fraud cases is handed to an agent that explores across systems. Each part has a clearly distinct failure mode. How should this composition be evaluated?

People also ask

When should you combine two reference architectures?
When two parts of the problem fail in genuinely different ways worth managing separately. If each part has a distinct failure mode a single pattern cannot handle well, composition is justified.
Why does composing patterns double the maintenance surface?
Each reference architecture carries its own components, failure modes, and eval contract. Combining two roughly doubles what you build, monitor, and keep correct, which is why the default is to pick one when in doubt.
Why do composed systems need per-component eval sets?
A single end-to-end score can look healthy while one component fails, because others compensate. Only a separate eval set per architecture reveals which component is degrading before it surfaces as a user-visible failure.

Watch and learn

Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.

No videos curated for this concept yet

We are still curating the best official and community videos for this topic.

Official prep for this domain

Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.

References & primary sources

Adaptive study

Master this concept with Archie

Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.

Start studying