Domain 1: Agents and Workflows
14.7% of examDecide between a workflow and an agent architecture
Key Points
- Workflow = LLMs/tools orchestrated through predefined code paths (deterministic, testable); agent = the LLM dynamically directs its own steps and tool use.
- The augmented LLM (model + retrieval + tools + memory) is the base building block both workflows and agents compose.
- Five workflow patterns: prompt chaining, routing, parallelization (sectioning/voting), orchestrator-workers, evaluator-optimizer.
- An agent proper runs an open-ended loop: plan -> call tools -> observe real environment results -> repeat until done or stopped.
- Anthropic's guidance: find the simplest solution first -- agentic autonomy must earn its added cost, latency, and unpredictability.
Decision Rules
When: A task has fixed, known steps that always run in the same order
→Use a workflow (prompt chaining), not an autonomous agent.
When: Input falls into distinguishable categories needing different handling
→Use routing.
When: Independent subtasks are known in advance vs. must be decided by a central LLM at runtime
→Use parallelization sectioning for the former, orchestrator-workers for the latter.
When: Output quality benefits from a critique-and-refine cycle
→Use evaluator-optimizer.
✗ Anti-Patterns to Reject
- Assuming agents always outperform workflows -- Anthropic recommends the simplest solution that works.
- Confusing orchestrator-workers (subtasks decided dynamically at runtime) with parallelization sectioning (subtasks known in advance).
- Treating any multi-step LLM pipeline as "an agent" merely because it has several stages.
Design manager/supervisor and subagent hierarchies
Key Points
- A manager/supervisor agent coordinates specialized subagents; each runs in its own context window and returns only a condensed result.
- Context isolation -- not delegation alone -- is the defining benefit of the subagent pattern.
- Specialization: each subagent can get a focused system prompt, tool set, and optionally its own model tier.
- Parallelism: independent subtasks delegated to subagents can run concurrently.
- Multi-agent hierarchies multiply token usage and add coordination overhead -- reserve them for genuinely separable, heavy tasks.
Decision Rules
When: A subtask requires reading far more material than the final answer needs
→Delegate it to a subagent for context isolation.
When: Subtasks are independent
→Run subagents in parallel for the parallelism benefit.
When: Considering a multi-agent design
→First check whether a single agent or a simpler workflow satisfies the requirement at lower cost and latency.
✗ Anti-Patterns to Reject
- Treating subagents as "just more prompts" instead of valuing their separate context window.
- Reaching for a manager/subagent hierarchy by default rather than only for genuinely separable, heavy tasks.
Construct Claude agents with the Agent SDK, custom loops, and hooks
Key Points
- The Claude Agent SDK provides a managed programmable agent loop, built-in tools, session management, subagents, and hooks.
- A custom loop cycles: send messages -> receive tool_use -> execute tools -> feed back tool_result -> repeat until stop_reason is end_turn.
- Anthropic-hosted/managed deployment lowers operational burden but gives less control; self-hosted maximizes control over data flow, networking, and least privilege at the cost of operating it yourself.
- Hooks (PreToolUse, PostToolUse) are ordinary code callbacks that fire at fixed points -- deterministic, unlike prompt instructions.
- Destructive or high-stakes tool calls belong in a hook, not a system-prompt sentence.
Decision Rules
When: Managed loop mechanics and Anthropic-maintained tooling are sufficient
→Use the Claude Agent SDK rather than hand-rolling the loop.
When: Full control over dispatch, logging, or stopping conditions is required
→Write a custom loop over the Messages API.
When: Data residency and least-privilege requirements are hard constraints
→Choose self-hosted deployment even though it carries more operational burden.
When: A rule must block a destructive or high-stakes tool call
→Enforce it in a PreToolUse or PostToolUse hook, not the system prompt.
✗ Anti-Patterns to Reject
- Putting a safety rule only in the system prompt and calling it a guardrail.
- Assuming "managed/hosted" always wins -- self-hosting is the correct call when data residency or least privilege demand it.
Recognize agent patterns and abstraction frameworks
Key Points
- The tool-use loop is the core agent cycle: model emits tool_use, harness executes, returns tool_result, model continues -- grounded in real environment feedback.
- Memory persists state across turns or sessions (a scratchpad file, an external store), distinct from in-session context-window management.
- Context-window management (pruning, compacting, isolating via subagents) is a continuously applied pattern, not a one-off fix.
- Claude Agent SDK, LangGraph, PydanticAI, and Strands each package these patterns with a different flavor.
- Understand the underlying API calls before adopting a framework -- hidden abstraction layers make debugging harder.
Decision Rules
When: A team wants type-validated, Pydantic-validated structured I/O in Python
→PydanticAI is the natural fit.
When: A task needs graph/state-machine orchestration of nodes and edges
→LangGraph fits.
When: State must survive across sessions, not just turns within one
→Implement memory (a scratchpad/external store), which is distinct from in-session context management.
When: Choosing an abstraction framework
→Pick it for the leverage it provides, not as a substitute for understanding the tool-use loop it wraps.
✗ Anti-Patterns to Reject
- Assuming a framework removes the need to understand the tool-use loop and context management.
- Confusing memory (persisted across sessions) with in-session context-window management.
- Picking a framework by name recognition instead of matching its actual flavor to the requirement.