Agents and Workflows

Agents and Workflows is 14.7% of CCDV-F, roughly eight of 53 items. That makes it the third-largest domain and worth real study time, but nowhere near the third of the exam that Applications and Integration takes. Budget accordingly: deep on mechanics here, deeper still there.

Items are pitched at the implementer. Expect to be asked what your code does when a response comes back with a tool-use stop reason, where tool results belong in the message list, which pattern fits a described task, why a loop never terminates, and what a growing conversation costs you. Expect very few items asking you to justify agents to a stakeholder; that is the architect's exam, not this one.

The idea that unlocks the domain: an agent is a loop, not a product category. The model proposes an action, your code executes it, you append the result to the conversation and call the model again, until a stopping condition fires. Prompt chaining, routing, parallelization, orchestrator-worker, evaluator-optimizer and subagents are all named arrangements of that same loop. Choose the simplest arrangement that solves the task, and never ship a loop whose ending you cannot name.

• Workflow vs agent: if you can enumerate the steps ahead of time, hard-code them. Reach for an autonomous agent only when the path depends on what the model discovers at runtime, and you accept variable turn count, latency and cost.
• The loop, precisely: send messages plus tools; if stop_reason is tool_use, append the assistant message verbatim (including its tool_use blocks), execute the tools, then send a user message whose content is tool_result blocks. Repeat until stop_reason is end_turn.
• Every tool_result carries the tool_use_id of the block it answers. Match by id, not by order or name.
• Parallel tool calls: one assistant turn can contain several tool_use blocks. Execute them concurrently, then return all results in a single following user message.
• Steer the loop with tool_choice: auto lets the model decide, any forces some tool, naming a specific tool forces that one. Use forcing for the first hop, then release to auto.
• Prompt chaining: fixed sequence, each step's output is the next step's input. Add a programmatic gate between steps so a bad intermediate stops the chain instead of poisoning it.
• Routing: classify the input once, then dispatch to one specialized prompt, tool set or model tier. This is where cheap-tier classification in front of expensive-tier work pays off.
• Parallelization comes in two shapes: sectioning splits independent subtasks and merges them, voting runs the same task several times and aggregates. Both require the subtasks to be genuinely independent.
• Orchestrator-worker: a lead model decides the subtasks at runtime and dispatches workers. Use it when the decomposition is not known until you look; use plain parallelization when it is.
• Evaluator-optimizer: a generator produces, a critic scores against explicit criteria, the generator revises. Only worth it when the criteria are measurable and revision demonstrably helps.
• Subagents: delegation gives the subtask a fresh context window and its own tools; only a summary comes back. Delegate work that would otherwise flood the main thread, such as broad search or exploration.
• Always define termination: a natural end_turn, a turn cap, a token or cost budget, an explicit completion tool the model must call, or a no-progress detector. A loop with none of these is a bug, not an agent.

• Orphaned tool calls: a tool_use block with no matching tool_result in the immediately following user message is rejected. If you skip, batch across turns, or reorder messages, the request fails.
• Tool exceptions: catch them and return the error text as the tool_result content with is_error set true. The model can then retry or route around it. Throwing kills the loop; returning nothing makes the model invent an outcome.
• Truncated tool input: if the turn hits max_tokens mid-block, the tool input JSON is incomplete. Branch on stop_reason before parsing, and treat max_tokens as a failure, never as completion.
• Runaway loops: the classic signature is the same tool called with the same arguments over and over. Detect argument repetition, cap turns, and surface the cap as an error rather than a silent partial answer.
• Quadratic context growth: every turn resends the whole history plus every tool result. Cost and latency climb turn over turn. Cache the stable prefix, summarize or compact older turns, and keep the system prompt and tool definitions fixed so the cache holds.
• Oversized tool results: paginate, filter and truncate at the tool boundary. Write bulk output to a file or store and hand the model a reference, not the payload.
• False parallelism: sectioning subtasks that actually depend on each other produces confidently wrong merges. Voting on a task with one correct answer wastes tokens without raising accuracy.
• Worker isolation: orchestrator workers do not see each other's context. The orchestrator must pass everything a worker needs, and must reconcile overlapping or conflicting results itself.
• Non-terminating critics: an evaluator-optimizer with no iteration cap and no improvement threshold will polish forever. Stop when the score plateaus or the cap is hit, and return the best candidate so far.
• Over-delegation: each subagent costs a round trip and loses everything not in its summary. If the parent needs the details, do the work inline.
• Non-idempotent actions on retry: a retried send, charge or write duplicates the effect. Make write tools idempotent with a caller-supplied key, or gate them behind confirmation.
• Failing to hand back: when an action is irreversible, credentials are missing, or the request is out of scope, stop and return control with the state so far and a concrete next step. Guessing is the worse failure.

PILOT — the order in which you actually build an agentic loop.

• P — Pattern: choose the shape first. Fixed steps if you can enumerate them; chaining, routing, parallelization, orchestrator-worker or evaluator-optimizer if the structure is known; an autonomous loop only if the path is discovered at runtime.
• I — Instructions and interface: write the system prompt and define the tool surface. The tools and their descriptions are the agent's entire action space, so an ambiguous tool description is a behavior bug.
• L — Loop: implement the turn. Branch on stop_reason, append the assistant message verbatim, execute every tool_use block, return every tool_result keyed by tool_use_id in one user message, call again.
• O — Off switch: name the stopping conditions before you run it. Turn cap, token or cost budget, explicit completion tool, no-progress detector, error threshold.
• T — Transfer: decide what handing back looks like. What the caller receives on success, on cap, and on an action the agent must not take alone.

Under exam pressure, PILOT also tells you where a described system is broken: a missing P means the wrong pattern, a missing O means a loop that never ends, a missing T means an agent that acts when it should have asked.