Apply Decomposition Techniques for Complex Problem Solving

CCAR-P Domain 1 — Solution Design & Architecture

Exam objective: Translate business problems into Claude-based AI solutions → Apply decomposition techniques for complex problem solving

---

1. What Is Decomposition?

Decomposition means breaking a large or complex problem into smaller, well-defined subproblems that can be solved, verified, and combined more effectively.

For CCAR-P, don’t reduce this to:

“Break a big task into smaller tasks.”

The professional-level version is:

Break a complex business objective into meaningful units of work, identify the dependencies between those units, assign the appropriate processing mechanism to each, define their interfaces, and combine their results into a validated business outcome.

That processing mechanism might be:

• normal deterministic application code,
• one Claude call,
• retrieval + Claude,
• a tool call,
• a fixed Claude workflow,
• an agent,
• a specialized subagent,
• parallel workers,
• or human review.

Decomposition does NOT automatically imply multi-agent architecture.

That distinction is extremely important for the exam.

Anthropic’s architectural guidance recommends starting with the simplest workable design and increasing complexity only when it provides a measurable benefit. Workflows are preferable for predictable tasks; agents become appropriate when model-driven flexibility is genuinely necessary.

---

2. The Core Exam Principle

Memorize this:

Decompose the problem first. Select the architecture second.

A common wrong approach is:

Business problem → “Let’s use multiple agents.”

The better reasoning is:

Business problem → decompose → understand dependencies → assign responsibilities → select workflow/agent/tool/code pattern → orchestrate → validate

Think:

Complex Business Problem
        ↓
Identify Desired Outcome
        ↓
Identify Subproblems
        ↓
Identify Dependencies
        ↓
Classify Each Subproblem
        ↓
Choose Best Mechanism per Subproblem
        ↓
Choose Sequencing / Parallelization
        ↓
Aggregate Results
        ↓
Validate Final Business Outcome

This reasoning also matches the two supplied practice exams. Across both practice sets, decomposition questions repeatedly test four ideas:

1. Complex multi-faceted problems should be separated into manageable components.
2. Components should be matched to appropriate expertise/tools.
3. Orchestration should follow the actual dependencies between subtasks.
4. If an entire case category is missed, the problem may be the original decomposition, not the model executing an individual step.

These patterns are more useful to memorize than any specific industry scenario.

---

3. Why Decomposition Helps Claude Systems

A single giant Claude prompt may appear attractive:

"Analyze the customer, review their contract,
check transactions, determine eligibility,
identify exceptions, calculate refund,
draft response and recommend next action."

But many different kinds of reasoning have been hidden inside one operation.

A better decomposition might be:

1. Understand request
2. Retrieve customer data
3. Retrieve applicable policy
4. Determine policy applicability
5. Identify exceptions
6. Calculate eligible amount
7. Verify calculation
8. Draft response
9. Human approval if required

Now the architect can ask useful questions.

• Which steps require Claude?
• Which should be deterministic code?
• Which require retrieval?
• Which can happen simultaneously?
• Which depend upon earlier results?
• Which require stronger models?
• Which require human approval?
• Which outputs can be independently verified?
• Where could an error propagate?

This is why decomposition is an architecture technique, not merely a prompting technique.

---

4. Six Useful Types of Decomposition

For exam scenarios, recognize that problems can be decomposed along several dimensions.

4.1 Functional / Task Decomposition

Split the overall task according to the work that must happen.

Example:

Generate an enterprise compliance report

Collect evidence
    ↓
Extract findings
    ↓
Map findings to controls
    ↓
Identify gaps
    ↓
Assess severity
    ↓
Generate report
    ↓
Validate

Use this when the business process naturally contains distinct stages.

Exam signal

Look for:

• “multi-faceted”
• “several distinct activities”
• “different processing stages”
• “different expertise”
• “different tools”

---

5. Dependency Decomposition

This may be the most exam-important decomposition concept.

After finding the subtasks, determine which ones depend on others.

Consider:

A → B → C

B needs A’s result; C needs B.

These must normally be sequential.

But:

       → B →
A              → E
       → C →
       → D →

B, C and D depend on A but not on one another.

They can potentially execute in parallel.

Anthropic describes parallelization as useful where independent subtasks can run simultaneously, while orchestrator-worker patterns are helpful when a task must be dynamically divided into subtasks.

Important exam rule

Dependencies determine orchestration.

Do not choose sequential, parallel, workflow, or multi-agent execution simply because one sounds architecturally sophisticated.

---

6. Information / Context Decomposition

Sometimes the problem isn’t that reasoning is difficult.

The problem is that too much irrelevant context is being mixed together.

Suppose a due-diligence task involves:

• financial statements,
• contracts,
• security reports,
• HR policies,
• litigation documents,
• technical architecture,
• regulatory filings.

Passing everything to a single worker creates:

• context bloat,
• distraction,
• higher token cost,
• harder evaluation,
• potentially poorer retrieval,
• information leakage between roles.

You could instead isolate:

Financial Analysis Worker
        |
Contract Analysis Worker
        |
Security Review Worker
        |
Regulatory Review Worker
        ↓
Synthesis

Current Claude Code documentation describes this as an important subagent benefit: a subagent can work in an isolated context and return only the needed result, preventing verbose exploration from flooding the main context.

Exam takeaway

Context isolation is a valid reason for decomposition.

But:

More workers merely sharing the same information is not automatically better decomposition.

---

7. Expertise / Capability Decomposition

Different portions of the problem may require different capabilities.

Example: insurance claim processing.

Subtask	Best mechanism
Extract claim number	Claude structured extraction
Retrieve policy	Search/RAG
Calculate deductible	Deterministic code
Detect unusual circumstances	Claude reasoning
Retrieve previous claims	API/tool
Approve large payout	Human
Draft explanation	Claude

This is a major architectural lesson:

Not every decomposed task should be assigned to Claude.

Sometimes deterministic code is the correct component.

Anthropic’s tool-use architecture explicitly separates Claude’s decision to invoke capabilities from the application-side execution of client tools.

---

8. Risk-Based Decomposition

Separate operations based on their consequences.

Suppose Claude processes a refund request.

Don’t design:

Analyze request → issue refund

Instead:

Understand request
        ↓
Retrieve order
        ↓
Evaluate policy
        ↓
Calculate proposed refund
        ↓
Validate eligibility
        ↓
Risk / threshold check
        ↓
Approval if required
        ↓
Execute refund

Why?

Because reasoning and irreversible action have different risk characteristics.

This aligns with the workbook’s broader architecture principle: hard constraints such as compliance and authorization should be enforced by the architecture rather than left solely to model behavior.

Exam signal

Whenever a subtask involves:

• financial transfer,
• deletion,
• publishing,
• regulated decision,
• security change,
• user account change,

consider whether it deserves an explicit boundary and validation/approval step.

---

9. Verification Decomposition

One useful pattern is separating generation from evaluation.

Instead of:

Claude creates final answer

use:

Generator
    ↓
Verifier / Evaluator
    ↓
Accept / Revise / Escalate

Anthropic describes an evaluator-optimizer workflow where one model generates a response and another evaluates it against defined criteria, providing feedback for improvement.

This is especially useful when:

• quality criteria are explicit,
• mistakes are costly,
• outputs can be independently checked,
• iteration materially improves results.

Do not add evaluator loops everywhere; they add latency and cost.

---

10. The Most Important Decomposition Framework for the Exam

For a scenario question, use this seven-step method.

Step 1 — Define the final business outcome

Ask:

What must ultimately be achieved?

Bad objective:

“Use Claude to process claims.”

Better:

“Reduce claim review time while maintaining policy compliance and requiring human approval for high-value exceptions.”

The output of decomposition must ultimately recombine into this outcome.

---

Step 2 — Identify logically distinct subtasks

Ask:

What pieces of work have different inputs, logic, expertise, tools, risks, or success criteria?

Example:

Customer support request

1. Intent classification
2. Customer lookup
3. Policy retrieval
4. Eligibility analysis
5. Action determination
6. Response drafting
7. Action execution

---

Step 3 — Draw the dependencies

Ask:

Does task B actually require task A’s result?

For example:

          ┌→ Customer History ───┐
Request ──┼→ Policy Retrieval ───┼→ Eligibility → Response
          └→ Product Lookup ─────┘

The three retrieval tasks are independent.

Run them in parallel if latency and infrastructure permit.

Eligibility depends on all three, so it follows them.

---

11. Step 4 — Classify Each Subtask

For every component ask:

Question	Architectural implication
Is the operation deterministic?	Code/rules may be better
Is it primarily language understanding?	Claude
Does it need current/external information?	Retrieval/tool
Is the path known beforehand?	Workflow
Does next action depend on discoveries?	Agent
Is specialist context needed?	Separate worker/subagent may help
Can subtasks run independently?	Parallelize
Is the action consequential?	Gate/approval
Can output be objectively checked?	Add validator

This step prevents a common error:

Assuming that decomposition means “create one agent for each task.”

It doesn’t.

---

12. Step 5 — Choose the Execution Relationship

You should recognize five important patterns.

A. Sequential decomposition

A → B → C → D

Use when every stage depends on previous output.

Example:

Extract → Validate → Transform → Generate

Anthropic calls the corresponding LLM workflow prompt chaining: a task is divided into ordered steps where subsequent calls process previous results.

---

B. Parallel decomposition

      → B →
A     → C →    Merge
      → D →

Use when B, C and D are independent.

Example:

Research competitors
Research customers
Research regulation
         ↓
     Synthesize

Benefit

Reduced wall-clock time and independent perspectives.

Cost

More calls and aggregation complexity.

---

C. Routing decomposition

             → Billing handler
Request → Router → Technical handler
             → Account handler

The problem isn’t necessarily executed by all specialists.

First classify it and send it to the appropriate specialist.

Anthropic describes routing as separating different input categories so each can be handled by the most suitable downstream process.

---

D. Orchestrator–worker decomposition

            ┌→ Worker A
Orchestrator ├→ Worker B
            ├→ Worker C
            └→ Worker N
                   ↓
                Synthesis

The important difference:

The required subtasks cannot be completely known in advance.

The orchestrator analyzes the problem and dynamically creates/delegates work.

Anthropic specifically distinguishes this from ordinary parallelization: in orchestrator-workers, the subtasks are not pre-defined; the orchestrator determines them from the input.

---

E. Evaluator–optimizer decomposition

Generate → Evaluate
    ↑          |
    └─ Feedback┘

Useful when evaluation criteria are clear and iterative refinement is valuable.

---

13. Step 6 — Define the Contract Between Components

Good decomposition requires good interfaces.

For every subtask define:

INPUT
↓
RESPONSIBILITY
↓
OUTPUT
↓
SUCCESS CRITERIA
↓
FAILURE / ESCALATION

Example:

Policy Retrieval

Input: Product type + jurisdiction + effective date Responsibility: Retrieve applicable policy Output: Relevant policy sections + source metadata Success: At least one authorized current source found Failure: Return NOT_FOUND; do not fabricate policy

This makes decomposition:

• testable,
• maintainable,
• observable,
• replaceable,
• debuggable.

---

14. Step 7 — Recombine and Validate

Decomposition isn’t complete merely because subtasks finished.

Ask:

How do their results become one correct business result?

Example:

Legal Analysis ──┐
Financial Analysis ─┤
Security Analysis ──┼→ Synthesis → Consistency Check → Final Report
Risk Analysis ──────┘

You need to consider:

• contradictions,
• missing worker output,
• duplicate findings,
• inconsistent formats,
• stale data,
• confidence/evidence,
• aggregation logic.

---

15. Critical Concept: Completeness of Decomposition

This receives direct emphasis in the supplied mock exams.

Imagine a healthcare assistant was decomposed into:

Symptoms
Medications
Medical History
Recommendation

Production testing discovers that allergies were never considered.

What failed?

Probably not the individual Claude call.

The original decomposition was incomplete.

Bad decomposition
       ↓
Missing subproblem
       ↓
Correct execution of incomplete architecture
       ↓
Wrong overall outcome

Exam trap

The question may offer:

• improve the prompt,
• upgrade the model,
• increase context,
• retrain the worker,

when the actual problem is:

A required problem category was omitted during decomposition.

---

16. Good vs Bad Decomposition

Good	Bad
Components represent meaningful responsibilities	Arbitrarily splitting into many tasks
Clear inputs/outputs	Workers exchange vague prose
Dependencies explicitly modeled	Everything runs sequentially
Independent work parallelized when useful	Parallelizing dependent tasks
Deterministic logic remains deterministic	Claude handles every calculation/rule
Different tools/expertise assigned appropriately	Same generic agent does everything
High-risk actions separated	Reasoning and irreversible action mixed
Validation included	“Final worker is assumed correct”
Final aggregation explicitly designed	Outputs simply concatenated
Complexity justified	“More agents = better”

---

17. Decomposition Does NOT Mean Multi-Agent

This is likely one of the most important exam traps.

Consider:

An application must classify a support request, retrieve a policy, calculate an SLA deadline and draft a response.

You can decompose it perfectly without multiple agents:

Classifier → Retrieval → Deterministic SLA Function → Claude Draft

That’s decomposition.

No multi-agent architecture is necessary.

Anthropic explicitly recommends starting with the simplest solution and notes that many applications can be handled with a well-designed single LLM call augmented by retrieval and examples before agentic complexity is justified.

Remember

Decomposition = problem-structuring technique.

Multi-agent = one possible implementation choice.

---

18. Decomposition and Parallelization

Another high-value distinction:

Independent

Research market
Research competitors
Research regulation

→ Parallel execution can make sense.

Dependent

Extract contract terms
        ↓
Identify obligations
        ↓
Assess compliance

→ Sequential execution.

Exam rule

Parallelize based on independence—not because parallel architectures are faster in theory.

The mock exams specifically frame orchestration as being driven by:

• dependencies,
• required sequencing,
• aggregation requirements.

---

19. Decomposition and Context Engineering

Large complex tasks commonly accumulate enormous context.

Rather than forcing one worker to retain:

all documents
+ all searches
+ all intermediate reasoning
+ all tool results
+ all drafts

decompose context ownership.

Main Coordinator
   |
   ├─ Contract specialist → contract findings only
   ├─ Security specialist → security findings only
   └─ Finance specialist → finance findings only
                   ↓
             compact outputs
                   ↓
                synthesis

Current Anthropic documentation explicitly recommends subagents where side work would flood the main conversation with logs, files, or search results, because only the useful summary needs to return to the parent context.

This can improve:

• focus,
• context utilization,
• specialization,
• isolation,
• tool permissions.

But subagents introduce startup/context-transfer overhead, so they are not automatically preferable for small or tightly shared tasks.

---

20. A Complete Worked Example

Business Problem

A company wants Claude to produce an enterprise vendor-risk assessment from:

• contracts,
• security questionnaires,
• financial reports,
• privacy documentation,
• compliance certificates.

A novice solution:

Put everything into Claude
        ↓
"Generate vendor risk report"

Better decomposition

                     Vendor Documents
                           ↓
                   Intake / Classification
                           ↓
        ┌──────────────────┼─────────────────┐
        ↓                  ↓                 ↓
 Security Review     Privacy Review    Financial Review
        ↓                  ↓                 ↓
        └─────────────┬────┴─────────────────┘
                      ↓
                Risk Synthesis
                      ↓
                Contradiction /
                Evidence Check
                      ↓
                 Risk Scoring
                      ↓
              Human Approval
                      ↓
                Final Report

Architecture choices

Intake: Claude classification/extraction.

Security/privacy/financial review: potentially independent → parallel workers.

Risk scoring: if company has fixed scoring rules → deterministic code.

Risk synthesis: Claude.

Verification: Claude or deterministic checks depending on requirement.

Final acceptance: Human, where organizational risk policy requires it.

That is professional decomposition because we’re decomposing according to:

• expertise,
• dependency,
• execution type,
• context,
• risk,
• validation.

---

21. Binding Constraints Can Change the Decomposition

Suppose the architecture above works functionally.

Then business says:

“The entire assessment must complete within 3 seconds.”

Now four sequential agent round trips may violate the requirement.

You might:

• parallelize independent analysis,
• collapse unnecessary steps,
• reduce retrieval round trips,
• use deterministic processing where possible,
• pre-compute data,
• remove an unnecessary evaluator loop.

The workbook repeatedly emphasizes that NFRs such as latency can invalidate an otherwise reasonable architecture.

The practice exams similarly contain a Domain 1 scenario where sequential multi-agent coordinator round trips conflict with a strict p95 latency target; the intended architectural response is simplification or parallelization, not simply prompt tuning.

---

22. Common CCAR-P Exam Traps

Trap 1 — “Complex problem = multi-agent”

Wrong.

First decompose. Multi-agent is justified only where specialization, context isolation, parallelism, independent verification, or dynamic delegation produces meaningful benefit.

---

Trap 2 — Split every step into a separate agent

Usually over-engineering.

Agent 1 → Agent 2 → Agent 3 → Agent 4 → Agent 5

can dramatically increase:

• latency,
• token usage,
• failure points,
• debugging complexity,
• orchestration overhead.

---

Trap 3 — Parallelize everything

Wrong if dependencies exist.

If B requires A’s output, B cannot independently run alongside A.

---

Trap 4 — Give Claude deterministic business logic

If the organization’s policy says:

refund = min(purchase_amount, $500)

implement that as deterministic code.

Claude can:

• interpret the request,
• identify relevant context,
• explain the result.

It need not “reason” about arithmetic/business enforcement that can be expressed exactly.

---

Trap 5 — Fix decomposition failures with a better model

If an entire category of work is absent from the architecture, changing models won’t add the missing architectural responsibility reliably.

Architecture problem → architecture fix.

---

Trap 6 — Ignore aggregation

Having five good worker responses does not guarantee one good answer.

Someone—or something—must:

• reconcile results,
• resolve conflicts,
• detect missing outputs,
• validate consistency,
• produce final output.

---

Trap 7 — Decompose based on organization chart

Don’t automatically create:

Finance Agent
HR Agent
Legal Agent
IT Agent

because the company has those departments.

Decomposition should represent the problem’s actual structure and dependencies.

---

23. Fast Exam Decision Framework

When you see a decomposition question, ask these in order:

1. Is the problem actually complex?

If one Claude call solves it reliably, don’t decompose unnecessarily.

2. What are the distinct responsibilities?

Look for different:

• information,
• expertise,
• tools,
• rules,
• risks,
• outputs.

3. What depends on what?

This determines sequence versus parallelism.

4. Is each step deterministic or adaptive?

Use code where deterministic; use Claude where language/reasoning is valuable.

5. Is the sequence known beforehand?

Known → workflow is usually favored.

Unknown/data-dependent → agent/orchestrator may be warranted.

6. Can components be independently verified?

If yes, decomposition can improve observability and evaluation.

7. How are results recombined?

Never forget aggregation.

---

24. High-Yield Memory Formula

Remember:

Break → Map → Assign → Orchestrate → Validate

BREAK

Identify meaningful subtasks.

MAP

Map dependencies between them.

ASSIGN

Choose Claude, code, retrieval, tool, agent, or human for each.

ORCHESTRATE

Sequence, parallelize, route, or dynamically delegate.

VALIDATE

Check component outputs and the final business outcome.

That five-step formula will handle most exam decomposition scenarios.

---

25. Architecture Pattern Cheat Sheet

Problem structure	Likely pattern
One well-defined transformation	Single Claude call
Single answer requiring current/domain knowledge	Augmented LLM / RAG
Known sequence of dependent subtasks	Prompt chain / workflow
Different known request categories	Routing
Known independent subtasks	Parallelization
Subtasks discovered dynamically	Orchestrator-workers
Path changes based on discoveries	Agent
Quality improves through critique/revision	Evaluator-optimizer
Rules/calculations must be exact	Deterministic code
Consequential approval	Human gate
Huge distinct information domains	Context-isolated workers/subagents

Anthropic’s published architecture guidance uses essentially these progressive patterns and advises adding complexity only when needed.

---

26. Two Recommended Exercises

Instead of the “Build Exercise” from the referenced CCAR-F lesson, I recommend exercises that focus more directly on architectural decomposition judgment, which is closer to this CCAR-P objective. The referenced lesson itself focuses mainly on implementing an agentic loop and stop_reason, making it useful for CCAR-F mechanics but less directly targeted at the professional decomposition objective.

Exercise 1 — Customer Complaint Resolution Architecture

Scenario

Design a Claude solution that handles:

“My order arrived damaged, the replacement is late, and I was charged twice. I want everything fixed.”

Available capabilities:

• order API,
• shipment API,
• payment API,
• refund API,
• return policy knowledge base,
• customer communication system.

Your task

Create:

1. Subproblem list.
2. Dependency diagram.
3. Claude/code/tool assignment.
4. Parallel vs sequential decisions.
5. Any human approval point.
6. Final aggregation step.

One good decomposition

                         Customer Request
                               ↓
                         Intent Analysis
                               ↓
             ┌─────────────────┼───────────────────┐
             ↓                 ↓                   ↓
       Order Check       Shipment Check       Payment Check
             │                 │                   │
             └──────────────┬──┴───────────────────┘
                            ↓
                     Policy Retrieval
                            ↓
                      Resolution Plan
                            ↓
               ┌────────────┴─────────────┐
               ↓                          ↓
        Safe Automated Action       Approval-required Action
               └────────────┬─────────────┘
                            ↓
                      Customer Response

What you’re practicing

• independent versus dependent tasks,
• tool assignment,
• parallelization,
• deterministic boundaries,
• action risk,
• aggregation.

---

27. Exercise 2 — Architecture Repair Challenge

Existing architecture

A company generates executive reports using:

Research Agent
      ↓
Financial Agent
      ↓
Competitor Agent
      ↓
Customer Agent
      ↓
Risk Agent
      ↓
Writer Agent
      ↓
Reviewer Agent

Average response: 45 seconds.

Business SLA: 15 seconds.

Questions

1. Which tasks genuinely depend on one another?
2. Which can run concurrently?
3. Are all seven agents necessary?
4. Could any step use deterministic code/RAG instead?
5. Does review need another full agent?
6. What information should each worker receive?
7. How should failures be aggregated?

Better conceptual architecture

                         Request
                            ↓
                        Planner
                            ↓
           ┌────────────────┼─────────────────┐
           ↓                ↓                 ↓
       Financial        Competitor        Customer
       Analysis         Research          Analysis
           └────────────────┬─────────────────┘
                            ↓
                         Synthesis
                            ↓
                     Risk / Quality Check
                            ↓
                          Report

The lesson:

The right answer is often not “faster agents.” It is better decomposition and orchestration.

---

28. Five CCAR-P-Style Practice Questions

Question 1 — Basic Decomposition

A financial-services company wants Claude to perform a vendor assessment involving contract analysis, financial analysis, cybersecurity assessment, and regulatory checks. Each area uses different data sources and requires different capabilities. What is the BEST initial architectural approach?

A. Put all available data into one prompt and ask Claude to perform the full assessment. B. Immediately create four autonomous agents and allow them to communicate freely. C. Decompose the assessment into distinct subproblems, identify their dependencies and required capabilities, then select the appropriate execution mechanism for each. D. Use the most capable Claude model so decomposition is unnecessary.

Answer: C

Why: Decomposition precedes architecture selection. The scenario explicitly contains distinct subproblems requiring different information and capabilities.

Why B is tempting: Multiple agents could eventually be appropriate, but selecting them before dependency/capability analysis reverses the architectural reasoning.

Exam lesson: Decompose first; choose agents second.

---

29. Question 2 — Parallelization

A report-generation system requires three analyses:

1. customer sentiment from survey data,
2. competitor research,
3. quarterly financial analysis.

None requires the output of another. All three feed a final executive summary, and response latency is important.

What is the BEST orchestration strategy?

A. Execute the analyses sequentially to maintain predictable ordering. B. Execute the three independent analyses in parallel, then aggregate their outputs before generating the executive summary. C. Ask a single agent to decide which analysis to perform first. D. Remove decomposition and perform everything in one very large prompt.

Answer: B

The analyses are independent, so their dependency graph supports parallel execution.

Anthropic identifies parallelization as a suitable workflow where multiple independent subtasks can execute concurrently and their results can later be aggregated.

Exam lesson: Dependencies—not preference—determine parallelism.

---

30. Question 3 — Missing Category

A healthcare team decomposes a clinical documentation process into medication review, symptom analysis, historical-condition analysis, and final summarization. During testing, clinicians discover the design completely ignores drug allergies.

What should the architect investigate FIRST?

A. Whether the summarization prompt requires additional few-shot examples. B. Whether a larger Claude model would identify allergies implicitly. C. Whether the original problem decomposition omitted a required category of clinical information. D. Whether the context window is sufficiently large.

Answer: C

The architecture is executing the tasks it was given; one essential responsibility was never included.

This mirrors a recurring pattern in both supplied practice exams: when an entire class of cases is missing, the root cause is likely incomplete initial decomposition, rather than execution failure.

Exam lesson: A model cannot reliably compensate for a missing architectural responsibility.

---

31. Question 4 — Deterministic vs Claude Processing

A returns system has been decomposed into:

1. understand the customer’s request,
2. retrieve the order,
3. determine refund amount according to a fixed published formula,
4. generate a customer explanation.

The team proposes using a separate Claude agent for every step.

What is the BEST architectural response?

A. Accept the proposal because decomposed systems should assign every subtask to an agent. B. Combine all steps into one autonomous agent. C. Use Claude where language understanding/generation is needed, APIs for retrieval, and deterministic code for the fixed refund calculation. D. Use multiple agents but select a smaller model for the calculation agent.

Answer: C

Decomposition identifies responsibilities; it does not require every responsibility to become an LLM call.

A fixed calculation should generally remain deterministic.

Exam lesson: Assign each decomposed problem to the mechanism best suited to solve it.

---

32. Question 5 — Dynamic Decomposition

A cybersecurity investigation assistant receives incidents of unpredictable complexity. For one incident it may need to inspect authentication logs and stop. For another, it may discover suspicious hosts and need separate malware, network, IAM, and vulnerability investigations. The necessary subtasks cannot be enumerated reliably beforehand.

Which architecture BEST fits?

A. A fixed sequential prompt chain containing every potential investigation. B. An orchestrator that analyzes the incident, dynamically delegates required subtasks to suitable workers, and synthesizes their findings. C. Parallel execution of every possible investigation for every incident. D. One classification prompt followed immediately by a final report.

Answer: B

This is the key signal for orchestrator-worker decomposition:

The subtasks themselves depend on what is discovered.

Anthropic distinguishes orchestrator-worker workflows from ordinary parallelization precisely because the orchestrator dynamically determines which subtasks are needed.

Why C is wrong: It wastes resources on work that may be unnecessary.

Exam lesson: Unknown decomposition at design time can justify model-driven orchestration.

---

33. What I Would Memorize for the Exam

You do not need to memorize dozens of decomposition patterns. Memorize these eight principles:

1. Decomposition comes before architecture selection.
2. Break complex problems into meaningful responsibilities, not arbitrary fragments.
3. Dependencies determine sequencing and parallelization.
4. Independent subtasks are candidates for parallel execution.
5. Unknown/dynamically discovered subtasks can justify orchestrator-worker or agentic designs.
6. Assign each subtask to the right mechanism: Claude, code, retrieval, tool, agent, or human.
7. A missing problem category is a decomposition failure—not automatically a prompt/model failure.
8. Design aggregation and validation as carefully as the individual workers.

And remember the one-line formula:

Break → Map dependencies → Assign capability → Orchestrate → Validate

---

34. Final Exam-Focused Summary

The official guide tells us the objective, but doesn’t prescribe one named decomposition methodology; candidates are expected to apply architectural judgment to complex problems. The supplied workbook provides the surrounding principle—select architectures based on the actual constraint and favor simpler patterns where they satisfy the requirement.

The two supplied practice exams sharpen what this objective is likely trying to measure: recognizing when a complex problem requires decomposition, identifying bad/incomplete decomposition, and choosing orchestration based on dependencies rather than sophistication.

Current Anthropic guidance strengthens exactly that interpretation: start simple, compose workflows when the problem structure is predictable, parallelize genuinely independent work, use orchestrator-workers when the decomposition must be discovered dynamically, and use isolated subagents when specialization or context isolation provides a real benefit.

Highest-yield exam rule

Do not ask “How many agents should I use?” first. Ask “What are the actual subproblems, what depends on what, and what is the simplest reliable mechanism for each?”

That is the architect-level reasoning this CCAR-P objective is testing.