Embedding the Right Feature at Each AI-Appropriate Step | CCAO-F Exam

From classified to built

Delegation mapping produces a labelled workflow: each step marked AI-appropriate, human-retained, or collaborative. This knowledge point is the build phase that follows: given the map, how do you actually construct each step? The Claude Certified Associate - Foundations (CCAO-F) exam sets it at apply level, because the answer is not "use Claude" but "use the right feature for this step's nature", and matching feature to step is a real judgement.

Two feature choices dominate the AI-appropriate steps, and one construction rule governs the human-retained ones. For AI-appropriate work you choose between a Skill and code execution based on what the step is; for human-retained work you build an explicit gate rather than an assumption. This depends on having first classified the steps correctly using reversibility and stakes and accountability, the hard prerequisites, because you cannot embed the right feature in a step you have mislabelled.

Skill for procedure, code execution for calculation

The first distinction is about what kind of AI-appropriate step you are looking at. If the step is a repeatable procedure, applying a defined set of rules the same way each time, a Skill is the right feature. A Skill encodes that procedure so the rules run consistently on every execution, which is exactly what a procedural step needs: the playbook applied the same way whether it is the first invoice or the thousandth. If the step instead turns on a number that must be computed, code execution is the right feature, because the figure has to be calculated from data rather than estimated, the same discipline as code execution for verified planning figures.

Getting this match wrong is the exam's first trap here: applying a Skill to a step that actually needs a computed figure, or reaching for code execution on a step that is really a procedural rules-application. The two features solve different problems. A Skill gives consistency of procedure; code execution gives correctness of calculation. Ask what the step's difficulty actually is, following rules the same way every time, or producing a right number, and the feature follows from the answer.

Why a Skill beats heroic prompting

There is a deeper reason to encode a repeatable step as a Skill rather than an ad-hoc prompt: consistency. An unstructured prompt depends on the operator remembering and re-typing the right wording every time, and that dependency is fragile. Phrasings drift, details get dropped, and the step behaves slightly differently run to run. A configured Skill removes that variability by holding the procedure in one place, so the same rules apply every time regardless of who runs it or what they remember.

This is why "we have a good prompt for it" is not equivalent to "we built a Skill for it". The prompt is only as reliable as the memory of the person invoking it; the Skill is reliable by construction. For a step that recurs and must be consistent, the Skill is the robust choice and the repeated prompt is the heroic-but-fragile one. This mirrors the persistence logic behind Projects for recurring extraction: capability that lives in configuration beats capability that lives in someone's memory.

Human-retained steps must be explicit gates

The construction rule for human-retained steps is that they become explicit review gates in the redesigned workflow, not implicit assumptions. A step that is supposed to have a person review the output only actually does so if the review is built in, defined, and staffed. Left implicit, "someone will check it", the human step tends to quietly evaporate under time pressure, and the workflow drifts toward automation no one decided on.

This is the exam's second trap here: leaving a human-retained step as an informal check rather than an explicit, staffed gate. The mapping may correctly say a step is human-retained, but if the redesign does not construct a real gate for it, the classification is fiction. Building the gate explicitly, a named reviewer, a defined checkpoint, is what makes the human-retained label true in practice, and its absence is exactly the drift diagnosed in a collapsed collaborative step.

What the CCAO-F exam trips candidates on

The exam tests two traps. The first is applying a Skill to a step that actually needs a computed figure, and vice versa. A scenario may show a calculation step being handled by a procedural Skill, or a rules-application step being pushed through code execution; the credited reading matches the feature to the step's real nature. The second trap is leaving a human-retained step as an informal check rather than an explicit, staffed gate. The exam wants the human step built into the redesign as a real gate, because an implicit one does not reliably happen.

Both traps reward the same build discipline: read what each step actually requires, consistency of procedure, correctness of calculation, or human judgement, and construct it accordingly, with Skills, code execution, and explicit gates placed where the step's nature calls for them.

Common misreadings to avoid

How this shows up on the exam

Domain 4 questions on this knowledge point present a mapped workflow and ask which feature to embed at each step, or how to construct the human-retained ones. The reliable reading is to match a Skill to a repeatable procedure, code execution to a calculation, and to build every human-retained step as an explicit, staffed review gate, with a configured Skill preferred over an ad-hoc prompt for consistency.

This knowledge point builds directly on the delegation criteria, reversibility and stakes and accountability, since the classification must be right before the feature can be. It applies the calculation discipline of code execution for verified planning figures, and the explicit-gate rule it enforces is what diagnosing a collapsed collaborative step checks for.