CCDV-F Glossary - Agents & Workflows

Quick-lookup definitions for every domain, with exam context and links back to the lesson that covers each term.

Agentic Loop: The deterministic control flow you write in your own code that turns the stateless Messages API into an autonomous agent: send a request with the full conversation so far, inspect stop_reason, execute any requested tools and append their results, and repeat until the model signals genuine completion. It is not a prompting technique or a retry wrapper - it is a loop with an explicit exit condition your code enforces.; Exam context: The exam tests that you know the loop is application-level logic, not something the API does for you, and that its exit condition must come from stop_reason rather than from content shape or a fixed step count.; See also: 3.1 - Building an Agentic Loop
stop_reason: The response field that tells your loop what to do next, with distinct values requiring distinct handling: end_turn (genuinely done), tool_use (execute tools and continue), max_tokens and model_context_window_exceeded (truncated, not finished), stop_sequence (intentional controlled stop), pause_turn (resend the conversation unchanged to continue a long server-tool turn), and refusal (the model declined - surface it distinctly).; Exam context: The classic distractor is checking response.content[0].type or scanning for phrases like "task complete" instead of stop_reason - Claude can emit explanatory text in the same response as a tool_use block, so content-based checks terminate loops mid-task. A second distractor is lumping every non-tool_use value in with end_turn, which ships truncated output as if it were finished.; See also: 3.1 - Building an Agentic Loop
Parallel Tool Calls: A single response with stop_reason: "tool_use" can contain more than one tool_use block in the same turn. The loop must execute every one of them and return exactly one tool_result block per tool_use_id in the follow-up user message - order doesn't need to match, but every id must be accounted for.; Exam context: The exam trap is appending only one tool_result when a response contained several tool_use blocks; the next API call then errors, or the model is left with no way to know what one of its own tool calls returned.; See also: 3.1 - Building an Agentic Loop
Coordinator-Subagent Pattern: An orchestration shape where one coordinator agent plans and delegates to specialised subagents that each have different tools, context, and jobs (one searches, one analyses, one synthesises), then integrates their results. Fits heterogeneous subtasks - different kinds of work, not just different data.; Exam context: Distinguish from hub-and-spoke: reach for coordinator-subagent when subtasks genuinely differ in kind, not just in which slice of data they touch.; See also: 3.2 - Single-Agent vs. Multi-Agent Orchestration
Hub-and-Spoke Pattern: An orchestration shape where several similar subagents run in parallel against different slices of the same uniform problem (e.g. each reviewing a different file for the same style rule) and a coordinator merges their output at the end. The win is throughput, not specialisation.; Exam context: A frequent scenario is "N independent, uniform subtasks with no dependency between them" - the correct answer is hub-and-spoke run in parallel, not a coordinator-subagent setup (wrong because subtasks aren't heterogeneous) and not sequential single-agent processing (wrong because it wastes the parallelism opportunity).; See also: 3.2 - Single-Agent vs. Multi-Agent Orchestration
Subagent Isolation Principle: A subagent inherits nothing automatically from the coordinator or from other subagents - not the system prompt, not conversation history, not another subagent's results. It starts with only what the coordinator explicitly writes into its prompt or task description, and separate invocations share no memory unless the coordinator deliberately carries something forward.; Exam context: The exam trap is tracing a multi-agent failure to the wrong place: if a coordinator's decomposition only names two of six subtopics, or strips source metadata before passing findings along, the subagents executed correctly on what they received - the fault is upstream in decomposition or context passing, not the subagent itself.; See also: 3.2 - Single-Agent vs. Multi-Agent Orchestration
Fixed Sequential Pipeline: A decomposition strategy with a known step order set in advance, where each step's output feeds the next as a separate, focused call (summarise, then extract, then translate). Simpler to build, test, and debug than dynamic decomposition because each step's prompt and expected output are stable and checkable in isolation.; Exam context: Contrast with dynamic adaptive decomposition, which an agentic loop already provides (Lesson 3.1) - use a fixed pipeline when the step order is knowable upfront, and dynamic decomposition when the task's shape genuinely depends on intermediate findings.; See also: 3.3 - Task Decomposition Strategies
Attention Dilution: The quality degradation that results from handing a single agent several simultaneous objectives in one turn (summarise, also extract fields, also translate, also flag compliance issues). A single generation pass has to satisfy criteria that can actively conflict, allocating attention across all of them at once instead of giving each a full, focused pass - the same fragmentation happens to an extended thinking budget on a bundled prompt.; Exam context: The exam distractor is trying to fix a bundled-objective quality problem purely by rewording the prompt more carefully - that treats a structural problem as a wording problem. The correct fix is decomposing into sequential, single-objective steps.; See also: 3.3 - Task Decomposition Strategies
Pipeline Verification Checkpoint: A lightweight check placed between fixed-pipeline steps - a schema check on extracted fields, a sanity check on item counts, a quick completeness pass - that catches an error or hallucination from one step before it propagates silently into the next, which would otherwise just trust bad input and act on it.; Exam context: Ties to Lesson 3.5: verification that must never be skipped belongs in code as a deterministic gate, not left to the next step's judgment. Feeding a step's output straight into the next with no check is a named exam trap.; See also: 3.3 - Task Decomposition Strategies
Tool Result Pruning: Deliberately replacing an old, superseded tool_result block's content with a short placeholder (e.g. "[full file contents omitted after use]") once it's been read and acted on, while leaving the rest of the conversation intact - a targeted alternative to blindly truncating the oldest N messages.; Exam context: The exam distinguishes deliberate pruning (a judgment call about what's still relevant) from blind truncation (a judgment-free cut by position that risks cutting something still load-bearing, like an early instruction).; See also: 3.4 - Session State and Memory Across Turns
Compact Summary Handoff: A deliberately-written few-sentence summary of outcomes and open items, injected into a fresh session as the middle option between full carry-forward and starting with nothing. Used when some continuity genuinely matters (the agent needs to remember what it tried and what's still open) but the full raw transcript doesn't need to survive.; Exam context: The exam wants recognition of three legitimate options - full carry-forward, a genuinely fresh session, or a compact summary into a fresh session - not a binary keep-everything-vs-lose-everything choice, and not truncation dressed up as a summary.; See also: 3.4 - Session State and Memory Across Turns
Context Editing / Memory Tool: Claude Developer Platform built-in features for session management: context editing can automatically clear aging tool interactions from history, and a memory tool persists durable facts to storage outside the conversation so they survive even when the message history itself is trimmed.; Exam context: These are the platform equivalents of hand-rolled pruning and summarisation - the exam expects the same underlying principle either way: decide deliberately what's still relevant rather than letting everything accumulate by default.; See also: 3.4 - Session State and Memory Across Turns
Deterministic (Pre-Execution) Gate: A code-level check that intercepts a requested tool call before it executes, checks it against a hard-coded rule, and blocks or redirects it if it fails. Used where a single failure would cost real money, create legal or regulatory exposure, or do something irreversible - the Agent SDK's PreToolUse hook is the named example of this checkpoint.; Exam context: The exam frames this as a decision about consequence, not model reliability: a prompt instruction might work 95%+ of the time, but for a compliance rule the remaining failure rate is exactly the exposure a gate exists to close. Adding a gate around a low-stakes formatting preference is the opposite-direction trap.; See also: 3.5 - Reliability Gates in Agentic Workflows
Post-Execution Check: A check that runs after a tool has already executed. It can only detect and flag a violation that already occurred (audit, logging) or normalise inconsistent tool output into one consistent shape before the model reads it - it cannot prevent the action from having happened, since the refund or transfer has already gone through by the time it fires.; Exam context: The core exam trap in this lesson: proposing a post-execution flag/log/review-queue as the fix for a hard compliance requirement is treating detection as if it were prevention. Normalisation and audit are its legitimate jobs; enforcement is not one of them.; See also: 3.5 - Reliability Gates in Agentic Workflows
Rejected tool_result: When a gate blocks a tool call, the rejection must still come back as a proper tool_result for that tool_use_id, with a clear explanation of why it was blocked, rather than the loop silently dropping the call or breaking.; Exam context: Two reasons the exam cares: structurally, every tool_use_id from the prior assistant turn needs a matching tool_result or the next API call is invalid; practically, a model given a clear rejection reason ("exceeds $500 threshold, requires approval") can react sensibly instead of having no way to recover.; See also: 3.5 - Reliability Gates in Agentic Workflows