Agent Construction with Claude
Agent Construction with Claude is 5.3% of the CCDV-F blueprint, the heaviest sub-skill in its domain at just under three of the 53 scored questions. It covers driving a tool-use loop correctly: message assembly, result pairing, failure signalling and the bounds that stop a run.
Written by Kiran Manne
5.3% of the CCDV-F blueprint, which is roughly 3 questions of 53. It sits inside Agents and Workflows, worth 14.7% in total.
Agent Construction with Claude is worth 5.3 percent of the blueprint, a shade under three questions out of 53, and it is the heaviest of the three sub-skills under Agents and Workflows. It is also the most mechanical, which is good news: the material is small, precise, and it rewards having built the thing once by hand.
Everything turns on one repeating cycle. You send a message array plus tool definitions, the model answers with content that may include requests to run tools, your code runs them, you append what they returned, and you send the array again. All the subtlety is in the bookkeeping: what exactly gets appended, in what order, across how many messages, with which identifiers attached, and what happens when a tool throws.
Get that bookkeeping wrong and the failures are quiet rather than loud. A subtly malformed conversation does not always raise; it degrades. The model stops issuing concurrent calls, or repeats work it already did, or loops on a step it believes never completed. That is why this sub-skill is examined through scenarios rather than definitions: you are shown a loop that mostly works and asked which detail explains the behaviour described.
What the exam tests here
- Appending the assistant's returned content blocks verbatim rather than extracting text out of them
- Returning one result block per requested call, all inside the single message that follows
- Carrying the identifier issued with each call onto the result that answers it
- Signalling a failed tool as an error-flagged result instead of dropping it or throwing
- Termination conditions: iteration caps, spend ceilings, and the stop reasons that end or continue a run
- Where an approval gate or an audit record attaches when the SDK drives the loop for you
Append the response, do not rebuild it
The most common construction bug is reconstructing the assistant turn from the pieces you cared about. One assistant message can carry several kinds of block at once, and the ones you ignore still matter.
Reasoning blocks must be echoed back unchanged when the conversation continues on the same model. Compaction blocks, where server-side compaction is enabled, stand in for history you no longer send. The tool requests themselves have to be present for the results you are about to send to make any sense. Appending the whole returned content array costs one line and preserves all of it. Pulling out the text and pushing that string back discards the rest silently, with nothing raised to tell you.
Result blocks: one per call, one message, matching identifiers
When the model asks for several tools in one turn, the reply is a single message holding a result block for each of them. Two rules follow and both get examined.
First, splitting those results across separate messages is accepted by the API but teaches the model that concurrent requests are unwelcome, so throughput quietly collapses over a session. Second, every result carries the identifier issued with the call it answers, and pairing by array position instead breaks the moment anything is reordered.
Run the calls concurrently by all means. The concurrency belongs in your executor; the wire format stays one batch in, one batch out.
A failing tool is a result, not an exception
When a tool raises, the instinct is to abort the turn or omit the result. Both leave the model stranded: it asked for something and heard nothing back, so it cannot adapt.
The correct construction returns a result block for that call, marked as an error, carrying a message the model can act on. "Connection refused to inventory-service" lets it try another route or report the problem; a stack trace or a bare failure string does not.
Two supporting habits matter. Validate arguments before executing, because a schema is a contract the model usually but not always honours. And keep the failure inside the loop rather than converting it into an application exception that kills a run mid-task.
Termination is your job
Nothing in the protocol stops an agent. The loop ends when a turn arrives with no tool requests in it, and a model that keeps finding results unsatisfying can keep asking indefinitely.
Construction therefore always includes a bound: a maximum iteration count, a ceiling on accumulated tokens, or a wall-clock deadline, each with a defined behaviour when it is reached. Alongside the bound, branch on how each turn ended. A normal finish exits. A request for tools continues. A truncated turn means the output cap cut the answer short, so the fix is a larger cap or streaming. A paused turn means a server-side tool run needs resuming by sending the assistant turn back.
Where candidates go wrong
Trap: catching a tool error and breaking out of the loop
Wrapping the executor in a try block that logs and returns feels defensive, and it destroys the agent's ability to recover. Half-finished multi-step work is abandoned, the user sees a generic failure, and the model never learns the call went wrong.
The construction the exam rewards keeps the loop alive: convert the exception into an error-flagged result with an actionable message, send it, and let the model decide whether to retry, route around it, or stop and explain. Reserve hard aborts for conditions the model genuinely cannot act on, such as an exhausted budget.
Trap: driving the loop with no ceiling at all
Textbook examples omit the bound because it distracts from the illustration, and the omission gets copied into production. An unbounded loop is a cost incident waiting for the right input: a flaky tool returning something the model keeps trying to fix will spin, billing every iteration, until a human notices.
An option presenting a loop with no iteration cap, no token ceiling and no deadline is incomplete however correct the rest of it looks. Options that add such a bound, with a defined outcome on hitting it, are the ones to prefer.
Trap: assuming the SDK loop takes control away from you
The choice is often framed as full control versus convenience, which is a false pair. A tool runner drives the request-and-execute cycle while still exposing per-turn interception, and that is exactly where an approval prompt, an audit entry, a retry policy or a modified result belongs.
Declining it in order to hand-write the same loop buys nothing but maintenance. The genuine reasons to own the loop are a control flow those hooks cannot express, or an unwillingness to depend on a helper still in beta, and a well-written question will say which applies.
Common questions
How much of the CCDV-F exam is Agent Construction with Claude?
5.3 percent, a shade under three of the 53 scored questions, and the single largest sub-skill inside Agents and Workflows. Its siblings are Agent Patterns and Frameworks at 4.9 percent and Agent Architecture at 4.5 percent.
Why must the assistant's content be appended unchanged?
Because blocks you did not read are still load-bearing. Reasoning blocks have to come back unchanged to continue on the same model, compaction blocks stand in for history that is no longer sent, and the tool requests anchor the results you are about to supply. Extracting the text and appending that string throws the rest away without raising anything.
What happens if I return tool results in separate messages?
The request is accepted, so nothing looks broken, but the model reads the pattern as evidence that concurrent requests are not wanted and starts issuing them one at a time. Latency and cost then rise across the session for a reason that never appears in a log. All results for one assistant turn belong in the one message that follows it.
How should an agent handle a tool that is temporarily down?
Return the result marked as an error with a message describing what failed, and let the loop carry on. Retry the underlying call inside your executor if the failure is transient, but do not swallow the outcome. The model can pick a different tool, ask the user, or summarise what it managed to do, and it can only do any of that if the failure reaches it.
The rest of Agents and Workflows
- Agent Patterns and Frameworks (4.9%)
- Agent Architecture (4.5%)
Practise this
The CCDV-F bank covers every sub-skill in the blueprint, weighted the way the real paper is. Free sample questions need no account.
Free CCDV-F questions