CCA Exam Prep D1 Part 2: Multi-Step Workflows, Agent SDK Hooks, and Task Decomposition

Furthermore, your agent executes refund processing without retrieving customer information 12% of the time. Would adding “always retrieve first” to the prompt solve this? The answer is No. If you properly understand CCA exam workflows, Agent SDK, and task decomposition, the root cause and solution become immediately apparent.
This article is the sequel to Part 1 (D1 First Half: T1.1–1.3) and provides a thorough explanation of the latter half tasks (T1.4–1.7) of CCA Foundations exam Domain 1. After mastering agent loop fundamentals and multi-agent orchestration in Part 1, the next challenge readers face is the design decision of “how to guarantee workflow reliability.”
- Why Programmatic Enforcement Is Necessary (T1.4)
- Agent SDK Hooks: Deterministic Intervention Mechanisms (T1.5)
- Task Decomposition: Fixed Pipeline vs Dynamic Decomposition (T1.6)
- Session Management: Resume, Fork, and Structured Summaries (T1.7)
- CCA Exam Question Pattern Summary
- CCA Frequently Tested Patterns: D1 Part 2 Question Trend Analysis
- Summary: D1 Part 2 Design Decision Checklist
Why Programmatic Enforcement Is Necessary (T1.4)

The Limits of Prompt Instructions: Non-Zero Failure Rate
One of the most important concepts in the CCA exam is distinguishing between prompt-based guidance vs. programmatic enforcement.
There are two approaches to agent workflow control:
| Approach | Certainty | Use Case |
|---|---|---|
| Programmatic (hooks / prerequisite gates) | 100% deterministic | Compliance-required processing order |
| Prompt-based (instruction-guided) | High but non-zero failure rate | Situations requiring flexible judgment |
Similarly, even if you write “always execute in this order” in the prompt, LLMs operate probabilistically, leaving a non-zero failure rate. In scenarios requiring deterministic compliance, prompts alone are insufficient.
Implementing Prerequisite Gates
In particular, a prerequisite gate is a mechanism that programmatically guarantees another tool has completed before a specific tool call is made.
class WorkflowEnforcer:
def __init__(self):
self.completed_steps = set()
def pre_tool_check(self, tool_name, tool_input):
"""Pre-tool call prerequisite check"""
# process_refund is blocked unless get_customer has completed
if tool_name == "process_refund":
if "get_customer" not in self.completed_steps:
return {
"error": "To execute process_refund, "
"you must first retrieve customer info via get_customer."
}
return None # Check OK, execution permitted
def post_tool_record(self, tool_name):
"""Record completion after tool execution"""
self.completed_steps.add(tool_name)In this code, when process_refund is called, if get_customer is not in completed_steps, an error is returned. Instead of relying on prompts, ordering is enforced at the code level.
Key Point
Structured Handoff Protocol
In conclusion, structuring information handoffs between stages in multi-step workflows is also an important topic in CCA exam workflows, Agent SDK, and task decomposition.
handoff_payload = {
"stage": "customer_verified",
"customer_id": "C-12345",
"verification_method": "email_confirmed",
"timestamp": "2026-03-25T10:30:00Z",
"next_allowed_actions": ["process_refund", "escalate_to_human"],
"restrictions": {
"max_refund_amount": 500,
"requires_manager_approval_above": 200
}
}Furthermore, handoff payloads should include customer ID, root cause analysis, recommended actions, and constraints. This ensures the next-stage agent receives all necessary information in a structured format.
Key Point
Exam Question Pattern: “What’s the Problem?” Type
Q: A customer support agent skips get_customer and executes process_refund 12% of the time. What is the optimal solution?
| Option | Verdict |
|---|---|
| A: Block process_refund with programmatic prerequisites | Correct — 100% deterministic control |
| B: Add “always retrieve customer info first” to the prompt | Incorrect — Non-zero failure rate remains |
| C: Increase iteration limit | Incorrect — Unrelated to the root cause |
| D: Convert entire workflow to prompt chain | Incorrect — Still prompt-based control |
The question designer’s intent: In scenarios requiring “reliability guarantees,” programmatic means—not prompts—are the correct answer.
Agent SDK Hooks: Deterministic Intervention Mechanisms (T1.5)

PreToolUse and PostToolUse
Agent SDK hooks are mechanisms for making deterministic interventions in agent behavior.
| Hook | Timing | Use |
|---|---|---|
| PreToolUse | Before tool execution | Detecting and blocking policy violations |
| PostToolUse | After tool execution | Result transformation and normalization |
PostToolUse Hook: Data Normalization Implementation
Additionally, this hook processes tool output before passing it to the model. When different tools return dates in Unix timestamps, ISO 8601, MM/DD/YYYY, and other formats, PostToolUse hooks unify them.
def post_tool_use_hook(tool_name, tool_input, tool_result):
"""Convert Unix timestamps in tool results to ISO 8601"""
if tool_name == "get_order_details":
import json
from datetime import datetime, timezone
data = json.loads(tool_result)
if "created_at" in data:
ts = data["created_at"] # e.g.: 1711036200
data["created_at"] = datetime.fromtimestamp(
ts, tz=timezone.utc
).isoformat() # "2026-03-21T18:30:00+00:00"
return json.dumps(data)
return tool_result # Return other tools as-isIn other words, the model no longer needs to calculate “what date is 1711036200?”, improving both inference accuracy and efficiency.
Key Point
PreToolUse Hook: Blocking Policy Violations
def pre_tool_use_hook(tool_name, tool_input):
"""Block refunds exceeding $500"""
if tool_name == "process_refund":
amount = tool_input.get("amount", 0)
if amount > 500:
return {
"blocked": True,
"reason": (
f"Refund amount ${amount} exceeds policy limit of $500. "
"Manager escalation is required."
)
}
return None # Don't blockSpecifically, this intercepts refund requests exceeding $500 before tool execution and redirects to human escalation. While writing “avoid high-value refunds” in a prompt only achieves probabilistic compliance, hooks can block 100% of violations.
Key Point
Hook vs Prompt: Decision Criteria
| Requirement | Hook | Prompt |
|---|---|---|
| 100% certainty needed (compliance) | Appropriate | Insufficient |
| Flexible judgment needed | Not suitable | Appropriate |
| Data format conversion | Appropriate | Not suitable |
| User experience adjustment (tone, etc.) | Not suitable | Appropriate |
Specifically, the CCA exam key: when “deterministic guarantee” is asked, choose hooks; when “flexible response” is asked, choose prompts. Remembering this criterion alone lets you handle multiple exam questions.
Exam Question Pattern: “Hook vs Prompt” Type
Q: Different tools return dates in inconsistent formats, confusing the model. What is the optimal solution?
Correct answer: Normalize all tool date outputs to ISO 8601 with a PostToolUse hook. This is more reliable than instructing the prompt to “interpret dates” and reduces the model’s reasoning burden.
Task Decomposition: Fixed Pipeline vs Dynamic Decomposition (T1.6)

Two Major Patterns
Additionally, among CCA exam workflows, Agent SDK, and task decomposition, decomposition strategy selection is a frequently tested design decision.
| Strategy | Alias | Structure | Use Case |
|---|---|---|---|
| Fixed Sequential Pipeline | Prompt Chaining | Stage 1→Stage 2→Stage 3 (linear) | Predictable multi-step processing |
| Dynamic Adaptive Decomposition | Dynamic Decomposition | Coordinator dynamically generates subtasks based on context | Exploratory, uncertain tasks |
Fixed Sequential Pipeline (Prompt Chaining)
For example, this is a linear pipeline where each stage’s output becomes the next stage’s input.
[Input] → Stage 1: Summarize → Stage 2: Analyze → Stage 3: Generate Report → [Output]Therefore, stage count and order are predetermined, with clear input/output formats for each stage. It’s predictable, easy to test and debug, and allows validation gates between stages.
On the other hand, practical applications include document review (grammar check → fact verification → improvement suggestions) and data processing pipelines (extraction → validation → transformation → storage).
Dynamic Adaptive Decomposition
Similarly, this is a flexible approach where the Coordinator determines subtasks at runtime.
[Input] → Coordinator analyzes → Dynamically determines needed subtasks
├── SubAgent A (generated based on findings)
├── SubAgent B (additionally generated based on A's results)
└── Result integration → Gap detection → Launch SubAgent CIn particular, the task scope cannot be fully defined in advance, and next steps are determined based on intermediate results. Suitable for exploratory investigations, but carries the overhead of Coordinator decision costs.
Decision Matrix
| Criterion | Fixed Pipeline | Dynamic Decomposition |
|---|---|---|
| Task structure definable in advance | Appropriate | Overkill |
| Direction changes based on intermediate results | Not suitable | Appropriate |
| Reproducibility and test ease important | Appropriate | Difficult |
| Open-ended exploration | Not suitable | Appropriate |
| Fixed number of processing steps | Appropriate | Overkill |
| Minimize cost/latency | Appropriate | High cost |
Application to Large-Scale Code Review
In conclusion, large-scale code reviews combine both strategies:
Large codebase review
├── Phase 1: File-level local analysis (parallelizable)
│ ├── SubAgent: auth/ directory
│ ├── SubAgent: api/ directory
│ └── SubAgent: db/ directory
└── Phase 2: Cross-file integration pass (sequential)
└── Coordinator: Evaluate dependency consistencyFurthermore, file-by-file analysis runs as a fixed pipeline (Phase 1), followed by sequential cross-file integration (Phase 2).
Exam Question Pattern: “Best Approach?” Type
Q: What is the optimal decomposition strategy for reviewing legal documents from three perspectives (legal accuracy, readability, compliance)?
Correct: Fixed Sequential Pipeline (Prompt Chaining). Review perspectives are predefined, and each stage’s input/output is predictable.
Q: What is the optimal decomposition strategy for investigating a user’s bug report, identifying the cause, and proposing a fix?
Correct: Dynamic Adaptive Decomposition. The bug’s cause is unknown in advance, requiring a cycle of log analysis → hypothesis generation → verification → additional investigation.
Session Management: Resume, Fork, and Structured Summaries (T1.7)
_-├-182121-1024x572.jpg)
Three Session Management Techniques
| Technique | Command/API | Use |
|---|---|---|
| Resume with named session | –resume | Continuing interrupted work |
| Session fork | fork_session | Creating independent branches from shared baseline |
| Fresh start with structured summary | Manual | Reset when context becomes bloated |
–resume with Named Sessions
# Start a named session
claude -- "auth-refactor"
# Later, resume the same session
claude --resume "auth-refactor"Additionally, key points about resuming: conversation history is restored, but tool state (external state like filesystem changes) is not preserved. When files have been modified externally during session resumption, it’s crucial to notify the agent of those changes.
fork_session for Branching Exploration
fork_session creates independent branches from a shared analysis baseline.
Shared baseline (code analysis complete)
├── Fork A: --resume "perf-optimization"
│ → Explore performance optimization
├── Fork B: --resume "security-hardening"
│ → Explore security hardening
└── Fork C: --resume "refactor-approach"
→ Explore refactoring approachIn other words, you can analyze the same codebase from different perspectives in parallel, A/B testing different approaches for comparison. Each fork is independent and unaffected by changes in others.
Resume vs Fresh Start Decision Criteria
| Situation | Recommended Approach |
|---|---|
| Short interruption (within hours) | Resume with –resume |
| Bloated context (long session) | Create structured summary and start fresh |
| Files significantly changed | Notify agent of changes and resume |
| Switching to entirely different task | Start new session |
In CCA exams, the key judgment is that starting a new session with a structured summary is more reliable than resuming a session with stale tool results.
Designing Structured Summaries
A handover template for when context becomes bloated:
# Session Handover Summary
## Completed Tasks
- Refactoring of auth/middleware.py complete
- JWT verification logic migrated to RS256
## Incomplete Tasks
- [ ] Improve error handling (auth/errors.py)
- [ ] Achieve 80% test coverage (currently 65%)
## Important Design Decisions
- Token refresh will be implemented client-side
- Redis session store deferred to Phase 2
## Known Issues
- Rate limiter may malfunction under high loadSpecifically, structuring completed tasks, incomplete tasks, design decisions, and known issues allows a new session to immediately grasp the necessary context.
CCA Exam Question Pattern Summary
_│-├──-SubAgent-aut-182121-1024x572.jpg)
Specifically, we classify exam question patterns related to Domain 1 second half (T1.4–1.7) into five categories. Questions testing understanding of CCA exam workflows, Agent SDK, and task decomposition fall into one of these:
Pattern 1: “What’s the Problem?” Type
Presents a scenario and asks you to identify the design flaw.
Example: “Agent skips a step 15% of the time” → Absence of programmatic enforcement
Pattern 2: “Best Approach?” Type
Asks you to select the optimal design pattern from multiple options.
Example: “Predictable 3-stage review” → Fixed pipeline (not dynamic decomposition)
Pattern 3: “Hook vs Prompt” Type
Additionally, distinguishes between scenarios requiring deterministic guarantees and those needing flexible judgment.
Example: Compliance requirement → hook, User experience adjustment → prompt
Pattern 4: “Decomposition Strategy Selection” Type
Asks you to choose a decomposition strategy based on task characteristics.
Example: Pre-structured review → fixed pipeline, Unknown bug investigation → dynamic decomposition
Pattern 5: “Session Management Decision” Type
Asks you to choose a session management technique based on the situation.
Example: 80% context consumed → Start fresh with structured summary
Correct Answer Pattern Rules
| Pattern | Correct Answer Tendency | Incorrect Answer Tendency |
|---|---|---|
| Reliability guarantee needed | Programmatic (hooks/gates) | Prompt instructions, few-shot |
| Predictable tasks | Fixed pipeline | Dynamic decomposition (overkill) |
| Exploratory tasks | Dynamic decomposition | Fixed pipeline (unsuitable) |
| Bloated context | Structured summary and fresh start | Forced session continuation |
| Data normalization | PostToolUse hook | Prompt instruction to “interpret” |
CCA Frequently Tested Patterns: D1 Part 2 Question Trend Analysis

For example, Domain 1 second half (T1.4–1.7) has a higher proportion of “design decision” selection questions compared to the first half (T1.1–1.3). Here, we analyze question trends and answer strategies by task.
T1.4: Enforcement Question Trends
Therefore, questions from T1.4 almost invariably ask you to judge between “prompt vs. programmatic” as a binary choice. Question patterns can be classified into three types.
Pattern A: Failure Rate Presentation Type
On the other hand, a scenario is presented stating “the agent skips a step X% of the time.” The specific failure rate X implies the prompt’s non-zero failure rate. The correct answer is always programmatic enforcement (prerequisite gate).
Pattern B: Compliance Requirement Type
Similarly, in scenarios where “processing order is mandated as a regulatory requirement,” 100% certainty is required. The “improve the prompt” option is definitely incorrect.
Pattern C: Compound Options Type
In particular, when four options include “prompt improvement,” “hook implementation,” “increase iteration limit,” and “prompt chain,” note that prompt chains are also prompt-based control and therefore not deterministic. Increasing iteration limits is unrelated to the problem’s essence.
T1.5: Hook Question Trends
In conclusion, Agent SDK hook questions center on timing judgments between “PreToolUse vs. PostToolUse.”
| Scenario Keyword | Correct Hook |
|---|---|
| “Want to block” “prevent” “restrict” | PreToolUse |
| “Want to convert” “normalize” “unify format” | PostToolUse |
| “Date formats are inconsistent” | PostToolUse |
| “Operation exceeding policy limit” | PreToolUse |
The criterion is simple: intervene “before” tool execution or process results “after” tool execution. When reading a scenario, first determine “do I want to stop the tool execution itself, or change the result?”
T1.6: Task Decomposition Question Trends
Furthermore, decomposition strategy selection questions require quickly classifying the scenario’s nature.
Additionally, a common wrong answer pattern is choosing dynamic decomposition based on the preconception that “more flexibility is better.” Selecting dynamic decomposition when a fixed pipeline is appropriate results in “overkill” as an incorrect answer. Considering test ease and cost efficiency, fixed pipelines are the superior design when task structure is clear.
T1.7: Session Management Question Trends
In other words, session management questions test choosing the right approach for the situation. The three frequently tested scenarios are:
Scenario 1: Bloated Context
Specifically, when “80% of context is consumed in a long session,” the correct answer is creating a structured summary and starting a new session. Resuming with --resume tends to be incorrect. Resuming a session with accumulated stale tool results risks quality degradation.
Scenario 2: External File Changes
Specifically, when files have been modified externally during session resumption, the important thing is notifying the agent of those changes. --resume restores conversation history but doesn’t automatically reflect external state changes.
Scenario 3: Comparing Multiple Approaches
When you want to try different approaches from the same analysis baseline, fork_session is the correct answer.
Cross-Cutting Correct Answer Patterns
For example, in exams you must choose the “most appropriate” option, and multiple options may appear partially correct. In such cases, applying the above principles to select the “most direct and deterministic solution” is the golden rule.
Summary: D1 Part 2 Design Decision Checklist
_├──-Fork-A-resume-perf-optimization-_│-→-パフォーマ-182121-1024x572.jpg)
Therefore, we organize a checklist of design decisions spanning Domain 1 second half tasks (T1.4–1.7).
For more information, visit Anthropic Documentation.
- Prerequisite Gates: Are compliance-required processing orders enforced programmatically rather than via prompts?
- PreToolUse / PostToolUse: Are hooks utilized for policy violation blocking and data normalization?
- Fixed vs Dynamic: Can you select decomposition strategies appropriate to the task’s nature?
- Session Management: Can you choose to start fresh with a structured summary when context becomes bloated?
- Structured Handoffs: Are inter-stage information handoffs in a structured format including customer ID, root cause, and constraints?
Part 1 covered agent loops, multi-agent orchestration, and sub-agent spawning. Next, we advance to Domain 2: Tool Design and MCP Integration, diving deep into tool description design, structured error responses, and the three modes of tool_choice.
Key Point: This article outlines CCA exam design decision patterns. For practical preparation toward passing, combine hands-on learning through the Anthropic Academy official course with practice on mock exam sites. Also refer to the “three-pillar” study strategy recommended in our Complete Guide (Day 1) in this series.





