Claude Application Design

Claude Application Design is the heaviest single sub-skill on the CCDV-F blueprint at 8.6%, four or five of the 53 scored questions. It covers the decisions above the API call: which surface to build on, how the prompt is layered, where the validation boundary sits, and what the product does when the model is unavailable or wrong.

Written by Kiran Manne

8.6% of the CCDV-F blueprint, which is roughly 5 questions of 53. It sits inside Applications and Integration, worth 33.1% in total.

At 8.6 percent, Claude Application Design is the heaviest single sub-skill on the CCDV-F blueprint, worth four or five of the 53 scored questions. Nothing else on the paper carries more, and the material is design judgement rather than recall, so it is also the part that most rewards having built something real.

The unifying question is where each responsibility lives. An application built around a model is a set of components, and the design work is deciding which of them may exercise judgement and which must be predictable. The prompt layer decides what the model sees and in what order. The validation layer decides what is allowed out. The orchestration layer decides how many calls happen and in what sequence. The fallback layer decides what a user gets when any of it fails.

Two design pressures are specific to this platform and recur across questions. Prompt content has a natural ordering imposed by how reuse works, so the layout of your prompt is an architectural choice rather than a stylistic one. And model output is input to whatever consumes it next, which makes the boundary between the model and the rest of your system a place where validation belongs, not a place where trust is inherited.

What the exam tests here

  • Choosing between a single call, an orchestrated workflow, a self-directed agent and a hosted agent platform for a described product
  • Layering a prompt so stable content precedes volatile content, and keeping per-request data out of the shared prefix
  • Placing validation at the boundary where model output becomes another component's input
  • Designing the degraded path for an outage, a decline, and an answer that fails validation
  • Deciding where a person sits in the loop, and on which actions specifically
  • Keeping per-tenant and per-user data separated in a design that shares prompts and caches

Pick the smallest surface that meets the requirement

Four surfaces are available and they escalate in what you hand over.

A single call answers a bounded question and is the right answer far more often than its reputation suggests. An orchestrated workflow keeps the sequence in your code and calls the model at defined points, buying predictability and testability. A self-directed agent hands the sequence to the model, buying adaptability at the price of both. A hosted agent platform additionally takes over running the loop and the environment tools execute in, which is the practical answer when you want durable sessions and a workspace without operating one.

Design questions describe a product and expect a justified tier. The defensible instinct is to start at the bottom and climb only when a requirement forces it.

Prompt layout is an architectural decision

Everything you send is billed on every turn, and the reusable portion is only reusable while it stays byte-identical from the front of the request. That imposes an ordering on the design: definitions and instructions that never change first, per-conversation context next, volatile material last.

The consequences reach into component design. A helper stamping the current time into a system prompt destroys reuse for every call downstream of it. A tool list assembled per user in a non-deterministic order does the same. When an operator instruction has to arrive mid-conversation, some current models accept it as a system-role entry inside the message list, which changes behaviour from that point forward without disturbing the prefix that came before it.

The model boundary is a validation boundary

Treat the output of a model call the way you treat the body of an inbound request from an unknown client. It may be well formed and it may not be, and the difference should be established by code rather than assumed.

Give each component a contract: this call returns an object carrying these fields, and anything else is a handled failure rather than an exception thrown deep in the stack. The rule holds with more force when the output is going somewhere consequential, such as a query, a shell command, a template or a request to another service, because the model may have been reading content that somebody else wrote. Design the boundary so the untrusted-input handling you would apply to a stranger is applied here too.

Design the degraded path deliberately

Three failure modes need product decisions, and a design that has not made them will make them badly by default.

The dependency can be unavailable, which needs a queue, a cached answer, a simpler deterministic path or an honest error. The model can decline a request, which arrives as a completed response rather than a failure and needs a route that does not simply resend the same thing. And the answer can be well formed but wrong, which is the hardest case because nothing is raised anywhere.

The mitigation for the third is structural rather than technical: show the source, keep a human in the decision, or restrict the feature to work where being wrong is cheap. Choose per feature rather than globally.

Where candidates go wrong

Trap: designing for the agentic case when a single call would do

Autonomy is the most attractive option on paper and the most expensive in practice. A design handing the model a toolset and a goal, where the requirement was to extract five fields from an uploaded document, has bought variance, latency and a debugging problem in exchange for nothing.

The reverse mistake exists and is rarer: forcing a genuinely open-ended task through a fixed pipeline produces a system that fails on every input its author did not anticipate. The question to answer honestly is whether the steps can be written down in advance.

Trap: putting per-request data at the front of the prompt

It reads naturally to lead with the specifics (the user's name, the current timestamp, the record under discussion) and follow with the general instructions. That ordering makes every request unique from its first byte, so nothing before the change can be reused and a long conversation grows costly with no relief.

The fix is a layout rule enforced in the code that assembles the prompt rather than a note in a document: stable layers composed first, variable layers appended last, and anything interpolating a clock or an identifier into a stable layer treated as a defect.

Trap: treating a decline as an outage

A safety decline is a successful response that happens to carry no useful answer, so it never reaches error-handling code and never triggers a retry policy. Designs routing it through the generic failure path show a service error for a request that was in fact answered, and designs retrying it unchanged spend money to receive the same outcome again.

The design that holds recognises the case explicitly and routes it: explain to the user, offer a different route, or hand the request to a person. Products working in security or life-sciences adjacent areas should expect legitimate work to meet this path occasionally.

Common questions

How many CCDV-F questions come from Claude Application Design?

8.6 percent of the blueprint, which is four or five of the 53 scored questions. That makes it the single heaviest sub-skill on the exam, ahead of Software Engineering Foundations at 7.4 percent and Claude API Mechanics at 6.8 percent.

How do I choose between a workflow and an agent for a product?

Ask whether you could write the steps down before the request arrives. If you could, keep the sequence in code and call the model at the points where judgement is genuinely needed, because that design is testable and its cost is predictable. Hand the sequence over only when the input space is open enough that no fixed sequence would cover it.

Why does prompt ordering belong in a design discussion?

Because the reusable portion of a request is the portion that stays identical from the beginning, so where content goes determines what can be reused. Once that is understood, prompt layout stops being a formatting preference and becomes a constraint on every component that assembles a prompt, including any helper tempted to interpolate a timestamp into a shared instruction block.

What should an application do when validation of the model's output fails?

Something defined. Depending on the feature that might be one retry with the failure described back to the model, a fall back to a simpler deterministic path, or an honest message that the request could not be completed. What it should not be is an unhandled exception from a parser deep in the call stack, which is the default outcome when the boundary was never designed.

The rest of Applications and Integration

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