Agents and Workflows

Knowledge of

• The core distinction: a workflow orchestrates LLMs and tools through predefined code paths, while an agent lets the LLM dynamically direct its own steps and tool use
• The augmented LLM (a model enhanced with retrieval, tools, and memory) as the foundational building block that both workflows and agents compose
• The five named workflow patterns -- prompt chaining, routing, parallelization (sectioning and voting), orchestrator-workers, and evaluator-optimizer -- and the task shape each fits
• The agent loop proper: plan, call tools, observe real environment results, repeat until done or stopped
• The tradeoff an agent makes: better task performance on open-ended work in exchange for higher and more variable latency and cost

Skills in

• Recognizing when a task has fixed, known steps (favoring a workflow) versus open-ended steps that can't be predicted in advance (favoring an agent)
• Selecting the specific workflow pattern -- chaining, routing, parallelization, orchestrator-workers, or evaluator-optimizer -- that matches a described task
• Distinguishing orchestrator-workers (subtasks decided dynamically at runtime) from parallelization sectioning (subtasks known in advance)
• Applying Anthropic's guidance to find the simplest solution first and add agentic autonomy only when the task demonstrably benefits from it

Knowledge of

• A manager/supervisor agent coordinates specialized subagents, each running in its own context window and returning only a condensed result
• Context isolation as the defining benefit of subagents: a subagent can absorb large amounts of raw, noisy exploration and return only a short summary to the manager
• Specialization: each subagent can have a focused system prompt, tool set, and optionally its own model tier
• Parallelism: independent subtasks delegated to subagents can run concurrently
• The tradeoff of multi-agent hierarchies -- coordination overhead and multiplied token usage -- against the benefit of separable, heavy subtasks

Skills in

• Deciding when a task is genuinely separable and heavy enough to justify a manager/subagent hierarchy versus a single agent or workflow
• Designing subagents with focused system prompts, tool sets, and model tiers matched to their subtask
• Recognizing subagent delegation as a first-class context-management technique, not just a way to add more prompts
• Weighing coordination overhead and multiplied token/cost usage against the isolation and parallelism benefits of a hierarchy

Knowledge of

• The Claude Agent SDK as a managed programmable agent loop with built-in tools, session management, subagents, and hooks
• The custom agent loop: send messages, receive tool_use blocks, execute tools, feed back tool_result blocks, repeat until stop_reason is end_turn
• The choice between Anthropic-hosted/managed deployment (less operational burden, less environment control) and self-hosted deployment (more control over data flow, networking, and least privilege, at the cost of operating it yourself)
• Hooks (e.g., PreToolUse, PostToolUse) as ordinary code callbacks that fire at fixed points in the loop and therefore behave deterministically
• Why hooks -- not system-prompt sentences -- are the correct place for guardrails against destructive or high-stakes tool calls

Skills in

• Choosing the Claude Agent SDK when managed loop mechanics and Anthropic-maintained tooling are sufficient, versus a custom harness when full control over dispatch, logging, and stopping conditions is required
• Implementing or reasoning about the tool_use / execute / tool_result / repeat cycle underlying any agent loop
• Selecting a deployment model (hosted vs. self-hosted) based on operational burden versus control over data residency and least privilege
• Placing deterministic guardrails for destructive or high-stakes actions in a PreToolUse or PostToolUse hook rather than in prompt text alone

Knowledge of

• The tool-use loop as the core agent cycle: model emits tool_use, harness executes, returns tool_result, model continues, grounded in real environment feedback at every step
• Memory as persisted state across turns or sessions (a scratchpad file, an external store the agent reads/writes) so the agent isn't limited to what fits in one context window
• Context-window management (pruning stale tool output, compacting history, isolating via subagents) as a recurring agent pattern, not a one-off fix
• The distinct flavors of major abstraction frameworks: Claude Agent SDK (Anthropic's own loop/tools/hooks/subagents), LangGraph (graph/state-machine orchestration), PydanticAI (type-safe, Pydantic-validated structured I/O), and Strands (model-driven agent framework)
• Anthropic's advice to understand the underlying API calls before adopting a framework, since hidden abstraction layers make debugging harder

Skills in

• Identifying the tool-use loop, subagent delegation, memory, and context-management patterns inside a described agent system
• Matching a stated requirement (e.g., type-validated structured I/O, graph-based orchestration) to the abstraction framework built for it
• Choosing a framework for the leverage it provides while still understanding the underlying tool-use loop and context management it wraps
• Recognizing that memory (persisted state across turns/sessions) is a distinct pattern from context-window management within a single session