Design Multi-Agent Systems and Orchestration Strategies

CCAR-P Domain 1 — Solution Design & Architecture Exam Guide

Target objective: Design multi-agent systems and orchestration strategies Domain: Domain 1 — Solution Design & Architecture (17%) Exam: Claude Certified Architect – Professional (CCAR-P)

---

1. What You Need to Know for the Exam

For this objective, don’t study multi-agent systems as simply:

“Many Claude agents working together.”

That definition is too shallow for CCAR-P.

Think like an architect:

A multi-agent architecture deliberately decomposes a problem across multiple independently operating agents because separation of context, capability, responsibility, verification, or parallel work provides enough value to justify the additional coordination, cost, latency, security, and operational complexity.

Anthropic describes its production Research architecture as an orchestrator-worker pattern: a lead agent analyzes the request, develops a strategy, creates specialized subagents, receives their findings, synthesizes results, and may launch additional work if gaps remain.

The important exam question is therefore rarely:

“Can we use multiple agents?”

It is usually:

“Why do we need multiple agents, and how should they coordinate?”

---

2. The First Rule: Don’t Use Multi-Agent by Default

This may be the single most important exam principle.

Anthropic recommends beginning with the simplest solution possible and increasing complexity only when needed. Workflows offer predictability for well-defined tasks, while agents become useful when flexibility and model-driven decisions are genuinely needed.

Your supplied practice exams follow exactly this reasoning:

• Fixed three-step process → workflow
• Simple retrieval + answer → augmented LLM
• Dynamic next step → agent
• Multiple genuinely independent/specialized subtasks → potentially multi-agent

Exam decision ladder

Can one Claude call solve it reliably?
        │
        ├── YES → Single / Augmented LLM
        │
        ▼
Are the steps known beforehand?
        │
        ├── YES → Workflow
        │
        ▼
Must the next action depend on intermediate findings?
        │
        ├── YES → Agent
        │
        ▼
Does splitting work provide meaningful:
   • parallelism?
   • context isolation?
   • specialization?
   • independent verification?
        │
        ├── YES → Multi-Agent
        │
        └── NO → Single Agent

Memorize

Multi-agent is an architectural optimization for particular problem shapes—not the “advanced version” of every Claude solution.

---

3. When Multi-Agent Architecture Is Actually Appropriate

Four signals should make you consider it.

3.1 Independent work can run in parallel

Example:

A market-intelligence request asks:

“Assess a company from financial, competitive, technical, and regulatory perspectives.”

Those research tracks are mostly independent.

Instead of:

Financial → Competitors → Technology → Regulation → Synthesis

you can use:

                 ┌─ Financial Agent ─────┐
                 ├─ Competitor Agent ────┤
Request → Lead ──┼─ Technology Agent ────┼→ Synthesis
                 └─ Regulation Agent ────┘

This is fan-out / fan-in orchestration.

Anthropic reports that its Research architecture particularly benefits breadth-first problems containing multiple independent directions that can be investigated simultaneously.

Exam signal

Look for words such as:

• independently
• simultaneously
• different domains
• multiple sources
• several distinct areas
• broad investigation

These often suggest parallelization.

---

4. Context Isolation: A Major Reason for Subagents

Multi-agent systems aren’t useful only because several things happen simultaneously.

They can also solve a context-management problem.

The Claude Agent SDK documentation explains that subagents have their own isolated context windows and can return only the information relevant to the orchestrator instead of sending their entire working context back.

Example:

Main Agent
Context:
  User request
  Business constraints
  Current synthesis
        │
        ├── Legal Agent
        │     └── 40K tokens of regulations
        │          returns 1K-token findings
        │
        ├── Financial Agent
        │     └── 30K tokens of filings
        │          returns 1K-token findings
        │
        └── Technical Agent
              └── 50K tokens of documentation
                   returns 1K-token findings

The coordinator does not need all 120K tokens of exploration.

It needs distilled results.

Exam takeaway

If the question says:

“The main agent’s context is becoming overloaded with large intermediate research results.”

A strong answer may be:

Delegate large investigations to context-isolated subagents and return concise structured findings.

Simply increasing the number of agents without context isolation does not solve the problem.

---

5. Specialization: Different Agents, Different Responsibilities

Another valid reason to decompose is specialization.

For example:

                 ┌─────────────────┐
                 │ Coordinator     │
                 └───────┬─────────┘
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
 Research Agent     Analysis Agent    Policy Agent
 Search tools       Data tools        RAG corpus
        │                │                │
        └────────────────┼────────────────┘
                         ▼
                  Synthesis Agent
                         │
                         ▼
                 Verification Agent

Each agent can have different:

• system instructions
• context
• tools
• permissions
• success criteria
• model requirements
• evaluation criteria

That is meaningful specialization.

Bad architecture

Agent A → all tools
Agent B → all tools
Agent C → all tools
Agent D → all tools

with nearly identical prompts.

You have multiplied cost and attack surface without gaining meaningful separation.

---

6. The Coordinator / Orchestrator Pattern

This is the architecture I would know cold for the exam.

                    USER
                      │
                      ▼
             ┌──────────────────┐
             │  ORCHESTRATOR    │
             │ / LEAD AGENT     │
             └────────┬─────────┘
                      │
          Analyze + Decompose
                      │
       ┌──────────────┼──────────────┐
       ▼              ▼              ▼
 ┌──────────┐   ┌──────────┐   ┌──────────┐
 │ Agent A  │   │ Agent B  │   │ Agent C  │
 │ Research │   │ Analysis │   │ Policy   │
 └────┬─────┘   └────┬─────┘   └────┬─────┘
      │              │              │
      └──────────────┼──────────────┘
                     ▼
             ┌────────────────┐
             │ Aggregation /  │
             │ Synthesis      │
             └───────┬────────┘
                     │
                Quality check
                     │
             ┌───────┴─────────┐
             │                 │
          Sufficient?         Gap?
             │                 │
            YES               NO
             │                 │
             ▼                 └──→ Re-delegate
          OUTPUT

Anthropic’s Research implementation follows this broad orchestrator-worker structure and allows the lead agent to launch additional research when existing results are insufficient.

---

7. What Exactly Does the Orchestrator Own?

This distinction is highly exam-relevant.

The orchestrator should typically own:

1. Understanding the request

Determine:

• intent
• complexity
• constraints
• success criteria
• which capabilities are actually required

---

2. Decomposition

Convert:

"Analyze whether we should acquire Company X"

into something like:

1. Financial health
2. Market position
3. Product/technology
4. Legal/regulatory risk
5. Strategic fit

---

3. Delegation

Decide which agent receives which task.

Not:

Always invoke all 8 agents.

Better:

Request requires finance + legal?
→ invoke Finance and Legal only.

Dynamic selection avoids unnecessary calls.

---

4. Dependency management

The orchestrator determines whether Agent B:

• can start immediately,
• needs Agent A’s output first,
• or doesn’t need to run at all.

This is exactly what the supplied practice exams emphasize: dependencies, sequencing, and aggregation requirements should drive orchestration.

---

5. Result aggregation

The orchestrator must know:

What did each agent discover?
Do findings conflict?
Is anything missing?
What belongs in the final response?

---

6. Error handling

For example:

Regulatory Agent → timeout
Financial Agent → success
Competitor Agent → success

Possible orchestration decisions:

Retry Regulatory Agent
       │
       ├─ success → continue
       │
       └─ failure
            │
            ├─ use alternative source/agent
            ├─ proceed with partial result
            └─ state coverage gap

Do not silently pretend every subtask succeeded.

---

7. Stopping

The coordinator needs a meaningful completion condition:

Required coverage achieved?
Evidence sufficient?
Verification passed?
Business task completed?

not merely:

We have already executed five agents.

---

8. Core Orchestration Strategies

You should recognize at least these patterns.

Pattern 1 — Sequential orchestration

Agent A
   ↓
Agent B
   ↓
Agent C
   ↓
Final

Use when later work genuinely depends on earlier work.

Example

Document Extraction
       ↓
Risk Analysis
       ↓
Compliance Review
       ↓
Executive Summary

Risk analysis requires extracted facts.

Therefore parallel execution would be inappropriate.

Exam rule

Dependency → sequencing.

---

9. Pattern 2 — Parallel Fan-Out / Fan-In

              ┌→ Agent A ─┐
Coordinator ──┼→ Agent B ─┼→ Aggregator
              └→ Agent C ─┘

Use when subtasks are independent.

Benefits

• reduced elapsed time
• diverse investigation paths
• context isolation
• broader coverage

Anthropic uses parallel subagents in Research because different aspects of a problem can be investigated independently.

Exam rule

Independence → parallelize.

---

10. Pattern 3 — Router + Specialists

                    Request
                       │
                       ▼
                    Router
                       │
       ┌───────────────┼───────────────┐
       ▼               ▼               ▼
 Billing Agent   Technical Agent   Sales Agent

Not every request activates every agent.

Example:

“My card was charged twice.”

→ Billing Agent

“API returns HTTP 401.”

→ Technical Agent

This avoids unnecessary orchestration overhead.

Exam trap

“Send every request through every specialist”

is usually wrong unless every specialist is genuinely required.

---

11. Pattern 4 — Orchestrator-Worker

The orchestrator dynamically generates subtasks rather than routing into a completely predetermined set.

Complex Request
      │
      ▼
Orchestrator
      │
  creates tasks
      │
 ┌────┼─────┐
 ▼    ▼     ▼
W1   W2    W3
 └────┼─────┘
      ▼
Synthesis

This fits problems where the exact decomposition depends upon the request.

Anthropic describes this as useful when tasks cannot be cleanly predefined and their required subtasks vary based on the input.

---

12. Pattern 5 — Evaluator / Optimizer

Generator
    │
    ▼
Evaluator
    │
 ┌──┴──────────┐
 │ Pass        │ Fail
 ▼             ▼
Output      Feedback
               │
               └──→ Generator

Example:

Writer Agent drafts a customer report.

Evaluator checks:

• required sections
• unsupported claims
• policy compliance
• citation coverage

If it fails, return targeted feedback.

This is useful where outputs have measurable quality criteria.

Important distinction

This doesn’t automatically require two agents.

If deterministic validation can perform the evaluation:

Claude output
     ↓
JSON Schema Validator

use code instead.

Don’t replace deterministic validation with another LLM merely to create a multi-agent architecture.

---

13. Hybrid Orchestration Is Often the Best Production Design

Real solutions can combine patterns.

Example:

                          User
                            │
                            ▼
                       Coordinator
                            │
                ┌───────────┴──────────┐
                │                      │
           Is simple?              Is complex?
                │                      │
                ▼                      ▼
           Single Agent          Decompose
                                       │
                           ┌───────────┼───────────┐
                           ▼           ▼           ▼
                       Search A    Search B    Search C
                           └───────────┼───────────┘
                                       ▼
                                   Synthesis
                                       │
                                       ▼
                              Deterministic checks
                                       │
                              ┌────────┴────────┐
                              ▼                 ▼
                            Pass              Fail
                              │                 │
                           Output           Rework

This is architecturally stronger than declaring:

“Everything is multi-agent.”

---

14. The Critical Orchestration Question: Dependencies

The practice exams directly target this.

Imagine three subtasks:

A = Retrieve customer record
B = Determine refund eligibility
C = Draft explanation

Dependencies:

A → B → C

Running all three simultaneously is wrong.

Now imagine:

A = analyze financial risks
B = analyze regulatory risks
C = analyze technology risks

Dependencies:

A ─┐
B ─┼→ Synthesis
C ─┘

Parallel execution makes sense.

Exam shortcut

Before choosing orchestration, draw dependencies mentally.

If:

B needs A

→ sequential.

If:

A ⟂ B ⟂ C

→ parallel.

If:

We don't know which specialists are needed yet

→ routing/orchestrator.

---

15. Decomposition Quality Determines Multi-Agent Quality

A complex architecture can fail before any agent executes.

Consider:

“Assess whether our organization should migrate a critical platform to a new cloud provider.”

Bad decomposition:

Agent 1 → Cloud pricing
Agent 2 → Cloud features
Agent 3 → Cloud documentation

Missing:

• migration effort
• security
• regulatory requirements
• architecture compatibility
• organizational capability
• operational risk

No amount of clever orchestration fixes a decomposition that never assigned those questions.

Your practice exams explicitly test this reasoning: when an entire category of cases is missing, the initial decomposition may have been too narrow, producing a design-time coverage gap.

Exam principle

Incomplete output may be a decomposition failure, not a model failure.

---

16. Good Task Boundaries for Subagents

Each delegated task should have:

Goal
+
Scope
+
Input
+
Allowed capabilities
+
Expected output
+
Completion criteria

Example:

ROLE
Regulatory Research Agent

GOAL
Identify regulations affecting the proposed transaction.

SCOPE
US federal financial regulations only.

INPUT
Company, transaction type, jurisdiction.

TOOLS
Approved regulatory search tools.

OUTPUT
Structured findings:
- regulation
- applicability
- evidence
- source
- confidence

STOP WHEN
All identified regulatory categories have either
supporting evidence or an explicit "not found" result.

This is substantially better than:

Research regulations.

---

17. Context Passing Between Agents

This is another important distinction.

Do not assume that creating Agent B means it automatically knows everything Agent A or the coordinator knows.

Anthropic’s current Agent SDK guidance highlights isolated subagent context as a deliberate feature: subagents work separately and return relevant information to the orchestrator.

Architecturally:

Coordinator context
      │
      │ explicit task package
      ▼
Subagent context
      │
      │ structured result
      ▼
Coordinator context

Good approach

Pass only:

• goal
• relevant facts
• constraints
• required evidence
• expected output structure

Bad approach

Copy the complete coordinator conversation into every subagent.

That destroys much of the context-isolation advantage.

---

18. Use Structured Agent-to-Agent Contracts

Instead of returning:

“I looked into this and things generally seem okay, although there are a few concerns…”

prefer:

{
  "status": "completed",
  "findings": [
    {
      "claim": "...",
      "evidence": "...",
      "source": "...",
      "confidence": "high"
    }
  ],
  "gaps": [],
  "recommended_followup": null
}

Why?

The orchestrator can reliably reason about:

• completion
• evidence
• missing information
• errors
• conflicts

instead of interpreting vague prose.

For CCAR-P, focus on the architectural value of explicit contracts, not memorizing a particular JSON schema.

---

19. Agent-to-Agent Security: Don’t Forget Least Privilege

This is where Domain 1 overlaps strongly with Domain 3.

Your practice exams include a scenario where one agent can invoke another without any defined boundary on what it is permitted to request. The identified risk is that unrestricted agent-to-agent invocation creates unclear, overly broad effective authorization.

Consider:

Research Agent
      │
      ▼
Finance Agent
      │
      ▼
Payment Tool

Suppose Research Agent shouldn’t be able to initiate payments.

If it can indirectly manipulate Finance Agent into doing so, your apparent privilege separation is meaningless.

Correct architecture

Agent A
   │
   │ allowed: research_request
   ▼
Agent B
   │
   │ allowed: read_financial_data
   ▼
Financial System

Not:

Agent A → "Ask Agent B to do anything"

Anthropic has also highlighted multi-agent trust escalation as an emerging security concern: output from a subagent should not automatically become trusted merely because another internal agent produced it.

Memorize

Agent boundaries must be capability boundaries, not merely prompt/persona boundaries.

---

20. Orchestration Should Include Failure Handling

A multi-agent architecture multiplies failure points.

Suppose:

Coordinator
 ├─ Market Agent       ✓
 ├─ Financial Agent    ✓
 ├─ Legal Agent        ✕ timeout
 └─ Technology Agent   ✓

The coordinator needs an explicit policy.

Possible response:

Legal failed
   │
   ├─ retry safely
   │
   ├─ use fallback source
   │
   ├─ re-delegate
   │
   └─ proceed with partial coverage
          +
      disclose missing legal analysis

Never:

Ignore failure → synthesize as though analysis were complete.

Exam signals

Look for:

• partial results
• timeout
• failed subagent
• unavailable tool
• conflicting findings

Correct answers normally preserve:

visibility + recoverability + explicit limitations.

---

21. Aggregation Is Part of the Architecture

Multi-agent design doesn’t end when agents finish.

You must decide:

How do separate outputs become one result?

Common approaches:

Direct synthesis

A ─┐
B ─┼→ Synthesis Agent → answer
C ─┘

Deterministic aggregation

Best for structured outputs.

Agent outputs
     ↓
Programmatic merge
     ↓
Validation

Rank/select

Multiple agents propose alternatives:

Proposal A ─┐
Proposal B ─┼→ Evaluator → best proposal
Proposal C ─┘

Consensus

Useful only when genuine independent judgment adds value.

Don’t assume:

3 agents agreeing = truth.

Three agents can repeat the same bad assumption.

Evidence matters more than voting.

---

22. Sequential Multi-Agent Systems Can Destroy Latency

This appears directly in both supplied practice exams.

A design containing:

Coordinator
    ↓
Agent A
    ↓
Coordinator
    ↓
Agent B
    ↓
Coordinator
    ↓
Agent C
    ↓
Coordinator

creates several serial model round trips.

Your practice exams specifically flag this as an architectural problem when a tight p95 SLA exists; the architecture may need simplification or parallelization rather than merely prompt tuning.

Anthropic similarly cautions that agentic systems typically trade increased latency and cost for better task performance.

Exam formula

Strict latency SLA
        +
Many sequential agent hops
        =
Architecture mismatch

Don’t reflexively answer:

• faster model
• shorter prompt
• more caching

when the fundamental issue is excessive serialized orchestration.

---

23. Multi-Agent Systems Also Increase Cost

This is important because CCAR-P tests business alignment.

Anthropic’s published experience with Research notes that multi-agent architectures consume substantially more tokens than normal interactions and are therefore most defensible for sufficiently valuable tasks.

Your practice exams reinforce the architectural implication: if the business driver is cost reduction and the task is simple and well-defined, sending every request through a multi-agent system using the most capable model is over-engineered and misaligned.

So:

Higher architectural sophistication
≠
Higher business value

---

24. Choose Models Per Agent, Not Necessarily Per System

Suppose you have:

Coordinator
├── Routing
├── Document search
├── Deep legal analysis
└── Final synthesis

These workloads may not require the same reasoning capability.

Architecturally, think:

Routine / predictable task
      ↓
Cost-efficient model

Hard reasoning task
      ↓
More capable model

The exam guide separately expects architects to understand model selection as a trade-off, and multi-agent architecture creates an opportunity to apply that choice at the component level rather than blindly selecting one tier everywhere.

---

25. Observability Must Follow the Orchestration Graph

For a single Claude call, you might monitor:

Request → Response

A multi-agent system requires more:

Request ID
   │
   ├─ coordinator decision
   ├─ decomposition
   ├─ agents invoked
   ├─ agent latency
   ├─ tool calls
   ├─ agent failures
   ├─ retries
   ├─ token/cost usage
   ├─ aggregation
   └─ final outcome

The official blueprint explicitly expects candidates to handle orchestration while also evaluating observability challenges, latency trade-offs, and tool/agent configuration.

Important operational metric

Do not optimize merely:

cost per agent call.

Think:

cost per successfully completed business task.

A “cheap” orchestration architecture needing repeated delegation may be expensive overall.

---

26. A Useful CCAR-P Multi-Agent Decision Matrix

Situation	Best starting pattern
One simple transformation	Single Claude call
Retrieve knowledge + answer	Augmented LLM / RAG
Fixed sequence	Workflow
Dynamic unknown sequence	Agent
Several independent investigations	Parallel subagents
Large isolated contexts	Subagents
Different tool/permission domains	Specialized agents
Multiple results must combine	Fan-out / fan-in
B depends on A	Sequential orchestration
Agent selection depends on request	Router / coordinator
Output needs iterative qualitative improvement	Evaluator/optimizer
Simple task + strong latency/cost constraint	Avoid multi-agent

---

27. A Production-Oriented Reference Architecture

For exam purposes, this is a useful mental model:

┌────────────────────────────────────────────────────┐
│                     USER / APP                     │
└───────────────────────┬────────────────────────────┘
                        ▼
┌────────────────────────────────────────────────────┐
│ INPUT / POLICY / AUTHORIZATION                     │
│ identity • validation • safety • request context   │
└───────────────────────┬────────────────────────────┘
                        ▼
┌────────────────────────────────────────────────────┐
│                 ORCHESTRATOR                       │
│                                                    │
│ classify → plan → decompose → delegate             │
│ budgets → dependencies → retries → stop criteria   │
└───────────────┬──────────────────┬─────────────────┘
                │                  │
      ┌─────────▼────────┐ ┌───────▼──────────┐
      │ Research Agent   │ │ Analysis Agent   │
      │ scoped tools     │ │ scoped tools     │
      │ isolated context │ │ isolated context │
      └─────────┬────────┘ └───────┬──────────┘
                │                  │
                └────────┬─────────┘
                         ▼
             ┌──────────────────────┐
             │ Synthesis / Merge    │
             └──────────┬───────────┘
                        ▼
             ┌──────────────────────┐
             │ Verification         │
             │ deterministic + AI   │
             └──────────┬───────────┘
                        │
               ┌────────┴────────┐
               ▼                 ▼
             PASS              FAIL
               │                 │
               ▼                 └──→ targeted rework
          FINAL OUTPUT
               │
               ▼
┌────────────────────────────────────────────────────┐
│ FEEDBACK / OBSERVABILITY                           │
│ quality • latency • cost • agent trace • failures  │
└────────────────────────────────────────────────────┘

You don’t need to memorize a vendor-specific framework.

Understand responsibility boundaries.

---

28. Worked Example — Enterprise Due-Diligence Assistant

Business problem

A corporate strategy team spends several days producing preliminary acquisition assessments.

They need:

• financial analysis
• market research
• regulatory research
• technology assessment
• sourced recommendations

The areas are largely independent.

---

Poor solution

One huge prompt:

"Research everything and recommend whether we should acquire Company X."

Potential problems:

• overloaded context
• sequential search
• difficult provenance
• poor coverage
• weak specialization

---

Better architecture

                         User
                           │
                           ▼
                   Due-Diligence Lead
                           │
              Define analysis requirements
                           │
          ┌────────────────┼─────────────────┐
          ▼                ▼                 ▼
   Financial Agent   Market Agent      Regulatory Agent
          │                │                 │
          └────────────────┼─────────────────┘
                           ▼
                    Technology Agent
                           │
                           ▼
                     Synthesis Agent
                           │
                           ▼
                    Evidence Validator
                           │
                           ▼
                      Human Review

But should Technology necessarily wait for the others?

Probably not.

A better dependency design is:

                 ┌→ Financial ────┐
                 ├→ Market ───────┤
Lead Agent ──────┼→ Regulatory ───┼→ Synthesis → Verification
                 └→ Technology ───┘

This illustrates an exam principle:

Architecture should follow actual dependencies, not the visual neatness of a pipeline.

---

29. What If Agents Disagree?

Suppose:

Market Agent:
"Demand is growing strongly."

Financial Agent:
"Revenue growth is slowing."

Industry Agent:
"Market growth estimates vary considerably."

Wrong:

Coordinator selects whichever answer seems most confident.

Better:

Preserve:
- claim
- evidence
- source
- confidence
- disagreement

Then synthesize:
"Market-level growth appears strong, but Company X is
currently underperforming that market."

The orchestrator’s role is reasoned aggregation, not flattening disagreement.

---

30. Multi-Agent Security Architecture

For each agent ask:

What data can it see?

What tools can it invoke?

Which other agents can it invoke?

Under whose identity does it act?

Can it perform irreversible actions?

Does its output cross a trust boundary?

A good system might look like:

Research Agent
Tools:
✓ search
✓ read approved documents
✗ write database
✗ send payment
✗ delete records

Finance Agent
Tools:
✓ read financial data
✓ calculate metrics
✗ issue payment

Transaction Agent
Tools:
✓ prepare transaction
Human approval required → execute

Exam rule

Different persona ≠ security boundary.

Authorization and capability restrictions must be enforced outside the model when they must reliably hold.

---

31. Common Exam Traps

Trap 1 — “More agents means better quality”

Wrong.

Use more agents only when decomposition gives real benefit.

---

Trap 2 — Multi-agent for a fixed workflow

Extract → Validate → Save

Usually a workflow, not three autonomous agents.

---

Trap 3 — Always invoke every specialist

Wasteful.

Use dynamic routing when only some capabilities are needed.

---

Trap 4 — Parallelize dependent work

If B requires A’s output, B cannot meaningfully execute first.

---

Trap 5 — Serialize independent work

Adds unnecessary latency.

Parallelize where independence permits.

---

Trap 6 — Solve decomposition failures by adding agents

If an entire problem category was never identified, adding capacity does not repair the missing decomposition.

---

Trap 7 — Give every agent every tool

Violates least privilege.

---

Trap 8 — Trust subagent output automatically

A subagent can still contain incorrect or maliciously influenced information. Anthropic specifically warns about trust escalation across agent boundaries.

---

Trap 9 — Use multi-agent despite tight latency requirements

Multiple serial round trips may make the architecture fundamentally incompatible with the SLA.

---

Trap 10 — Optimize technical sophistication instead of business value

If the business priority is:

reduce cost

then a very expensive multi-agent solution to a simple task is probably the wrong architecture.

---

32. The 8-Step Exam Method

When you see a multi-agent scenario, use this sequence.

Step 1 — Identify the business outcome

What exactly must improve?

cost?
speed?
accuracy?
coverage?
manual effort?
risk?

Step 2 — Ask whether multi-agent is even necessary

Could:

• one call,
• augmented LLM,
• workflow,
• or single agent

satisfy the requirement?

Step 3 — Decompose the task

Identify meaningful subtasks.

Step 4 — Map dependencies

A → B?
A || B?

Step 5 — Select orchestration

Dependencies determine:

• sequential
• parallel
• router
• orchestrator-worker
• evaluator/optimizer
• hybrid

Step 6 — Define boundaries

For every agent:

• context
• tools
• permissions
• responsibility
• output contract

Step 7 — Define aggregation and failure handling

How do results merge?

What if:

• an agent fails,
• agents disagree,
• evidence is missing?

Step 8 — Check NFRs

Does the architecture still satisfy:

• latency
• cost
• accuracy
• reliability
• security
• maintainability?

That last step frequently eliminates the attractive distractor.

---

33. Two Practical Exercises

You asked to skip the linked site’s Build Exercise. These exercises are more directly aligned to the CCAR-P architecture objective.

Exercise 1 — Design a Multi-Agent RFP Analysis Assistant

Scenario

Your organization receives a 150-page RFP containing:

• functional requirements
• architecture requirements
• security requirements
• contractual terms
• pricing instructions

The goal is to prepare a compliant proposal.

Your task

Design the architecture.

Start with:

RFP Intake
    │
    ▼
Coordinator
    │
    ├─ Functional Requirements Agent
    ├─ Technical Architecture Agent
    ├─ Security/Compliance Agent
    ├─ Contractual Risk Agent
    └─ Pricing Requirement Agent

Then answer:

1. Which agents can run in parallel?
2. What information should each receive?
3. What structured output should each return?
4. Who identifies contradictions between sections?
5. How are mandatory requirements tracked?
6. What happens when one agent finds an unresolved question?
7. Which decisions require human review?
8. How would you prevent every agent from receiving unnecessary tools?
9. Where should deterministic compliance checks be used?
10. What latency/cost trade-off justifies multi-agent processing?

Learning objective

Practice:

decomposition → parallelization → aggregation → verification → governance.

---

34. Exercise 2 — Customer Support Orchestration Challenge

Business problem

An assistant handles:

• order status
• returns
• refunds
• technical troubleshooting
• account problems

Design two versions

Version A

One agent with every tool.

Version B

                  Support Coordinator
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
 Order Agent       Returns Agent     Tech Agent
        │                │
        │          Refund approval
        │                │
        └────────────────┴──→ Human if required

Then compare:

Dimension	Single Agent	Multi-Agent
Context complexity	?	?
Tool exposure	?	?
Latency	?	?
Cost	?	?
Observability	?	?
Specialization	?	?
Security	?	?
Maintenance	?	?

Finally answer:

Does the multi-agent version create enough value to justify itself?

That final question is exactly the architectural judgment CCAR-P is trying to assess.

---

35. Five CCAR-P-Style Practice Questions

These are new practice questions created for study, not live exam questions.

---

Question 1 — Parallel vs Sequential

A financial-services company uses three specialist agents to prepare an investment report. One evaluates financial statements, one analyzes market conditions, and one reviews regulatory developments. Each analysis can be performed independently from the original request. The current coordinator invokes them sequentially, causing unacceptable response time.

What is the BEST architectural change?

A. Replace all three specialists with a single larger model. B. Run the three agents in parallel and aggregate their results after all required analyses complete. C. Add additional coordinator agents between each specialist. D. Increase the context window of each specialist.

Correct answer: B

Why: The subtasks have no dependency on each other. The orchestration should therefore exploit their independence through fan-out/fan-in execution.

Why A is wrong: A might reduce orchestration overhead but sacrifices the stated specialization without first showing specialization is the problem.

Why C is wrong: More coordinator hops worsen latency.

Why D is wrong: Context size doesn’t address serial execution.

Exam lesson

Independent subtasks → consider parallel execution.

---

36. Question 2 — Do You Even Need Multi-Agent?

An insurance company must extract fields from claim forms, validate required fields against deterministic rules, and save valid records to its claims system. The sequence is fixed and identical for every claim. An architect proposes an autonomous coordinator plus extraction, validation, and persistence agents.

What is the primary concern?

A. Claude cannot perform extraction tasks. B. Multi-agent systems cannot access enterprise APIs. C. The design is unnecessarily complex; a deterministic workflow better matches the known sequence. D. Every agent must use a different Claude model.

Correct answer: C

The workflow is known:

Extract → Validate → Save

There is little architectural benefit from autonomous coordination.

This matches the repeated pattern found in both supplied practice exams: well-understood fixed processes are better served by workflows than by unnecessary agentic or multi-agent complexity.

Exam lesson

Do not confuse decomposition with the need for autonomous agents.

---

37. Question 3 — Decomposition Failure

A healthcare organization creates specialist agents for medication analysis, diagnostic-history analysis, and laboratory analysis. After deployment, clinicians discover that allergy-related risks are systematically absent from generated reviews.

Which action should the architect take FIRST?

A. Upgrade all agents to a more capable model. B. Increase the number of iterations available to the coordinator. C. Revisit the original problem decomposition and ensure allergy-related analysis is explicitly covered. D. Add another synthesis agent.

Correct answer: C

The missing category points to an architectural coverage problem.

This is consistent with the supplied practice exams, where an entire missing category indicates that initial decomposition was too narrow.

Exam lesson

Missing coverage → inspect decomposition before blaming execution.

---

38. Question 4 — Agent-to-Agent Least Privilege

A corporate assistant uses a Research Agent that can invoke a Finance Agent. The Finance Agent can access financial records and execute payment-related tools. The Research Agent may send unrestricted natural-language requests to the Finance Agent.

What is the MOST important architectural concern?

A. The Research Agent may use too many tokens. B. Agent-to-agent communication bypasses retrieval caching. C. Unrestricted delegation can expand the Research Agent’s effective privileges through the Finance Agent. D. Both agents should use the same system prompt.

Correct answer: C

If Agent A can request arbitrary actions from Agent B, Agent A can effectively inherit Agent B’s privileges.

The practice exams explicitly identify unrestricted agent-to-agent invocation as a least-privilege risk.

Correct architecture

Expose narrow delegated capabilities such as:

get_financial_summary

rather than:

ask_finance_agent_to_do_anything

Exam lesson

Agent-to-agent boundaries need explicit authorization contracts.

---

39. Question 5 — Orchestration Strategy

A B2B research assistant has four subagents. Some user requests need only document analysis, others require simultaneous web and competitor research, while complex requests require those findings before a risk-analysis agent can operate.

Which orchestration strategy is BEST?

A. Always invoke all four subagents sequentially. B. Always invoke all four subagents in parallel. C. Let the coordinator dynamically select required subagents, parallelize independent work, sequence dependent work, and aggregate results. D. Remove the coordinator and let every agent invoke every other agent freely.

Correct answer: C

This is the closest expression of the central orchestration rule:

Dependencies + sequencing + aggregation needs determine orchestration.

Both supplied practice exams explicitly reinforce that principle.

Exam lesson

Don’t memorize:

Multi-agent = parallel

Memorize:

Independent → parallel
Dependent → sequential
Conditional → route
Unknown decomposition → orchestrate dynamically
Mixed problem → hybrid

---

40. Final Exam Cheat Sheet

Know these almost word-for-word

If the scenario says…	Think…
Fixed known sequence	Workflow, not multi-agent
Dynamic next action	Agentic
Several independent subtasks	Parallel subagents
B requires output from A	Sequential orchestration
Different requests need different specialists	Router / dynamic coordinator
Exact subtasks aren’t known beforehand	Orchestrator-worker
Large independent context	Context-isolated subagent
Need independent review	Evaluator / verifier
Entire category missing	Bad decomposition
All agents share every tool	Capability bloat
Agent can freely command privileged agent	Least-privilege failure
Tight SLA + several serial agents	Architecture/latency mismatch
Simple task + cost reduction goal	Multi-agent probably over-engineered
Subagent fails	Propagate error / retry / degrade explicitly
Agents disagree	Preserve evidence and disagreement; don’t blindly vote

---

41. The One Mental Model to Remember

For CCAR-P, think:

BUSINESS PROBLEM
       │
       ▼
Can a simpler pattern solve it?
       │
       ├── YES ──→ USE IT
       │
       ▼
DECOMPOSE THE PROBLEM
       │
       ▼
MAP DEPENDENCIES
       │
       ├── Independent ──→ PARALLEL
       │
       ├── Dependent ────→ SEQUENTIAL
       │
       ├── Conditional ──→ ROUTE
       │
       └── Unknown ──────→ ORCHESTRATOR
       │
       ▼
DEFINE EACH AGENT'S
role • context • tools • permissions • output
       │
       ▼
AGGREGATE + VERIFY
       │
       ▼
HANDLE FAILURE / GAPS
       │
       ▼
CHECK
cost • latency • quality • security • business value

Maximum-marks takeaway

The exam is unlikely to reward “multi-agent because the problem is complex.”

The stronger architectural reasoning is:

Use multi-agent architecture only when decomposition creates meaningful benefits such as parallelism, context isolation, specialization, or independent verification. Then derive the orchestration strategy from actual subtask dependencies, required sequencing, routing conditions, and aggregation needs. Keep agent capabilities scoped, propagate failures explicitly, verify synthesized results, and ensure the additional cost and latency remain justified by the business outcome.

That aligns particularly well with the official Domain 1 objective, the supplied CCAR-P practice-question patterns, and Anthropic’s production guidance on orchestrator-worker and subagent architectures.