- In short
- Entry point and model tier are two decisions made for the same task, and they reinforce each other. A recurring, structured task with a stable format pairs a Project with a mid-tier model; a nuanced, high-stakes, multi-source deliverable pairs a knowledge-base-backed Project or Artifact with the highest tier; a one-off drafting task with no reuse pairs plain Chat with a mid-tier model and no capability layer; and a current-information lookup pairs Research or Chat web search with a mid-tier model rather than the highest.
Two decisions, one task
Entry point and model tier have been treated separately so far, but in practice they are decided together for the same task. The CCAO-F exam tests this at the evaluate level because the two decisions reinforce each other: the same features of a task that point to a surface -- how it recurs, how stable its context is, how high its stakes -- also point to a tier. Reading the task well once tends to settle both at once, and getting one right while getting the other wrong is a specific failure the exam probes.
The skill is to hold both axes in view and produce a coherent pairing. A Project answers the "where does the work live" question; the tier logic answers the "how much capability" question. This knowledge point combines them into recognisable scenario-to-configuration matches.
- Combined entry-point and model matching
- The practice of choosing an entry point and a model tier together for the same task, since both follow from the task profile and reinforce each other. Recurring structured work pairs a Project with a mid-tier model; nuanced high-stakes multi-source deliverables pair a knowledge-base Project or Artifact with the highest tier; one-off drafting pairs plain Chat with a mid-tier model; current-information lookups pair Research or Chat web search with a mid-tier model.
Four canonical pairings
Four recurring patterns cover most scenarios. A recurring, structured task with a stable format pairs a Project with a mid-tier model: the Project holds the stable context and format so each run starts primed, and the mid-tier suits professional-but-not-extreme work. A nuanced, high-stakes, multi-source deliverable pairs a knowledge-base-backed Project or an Artifact with the highest tier: the knowledge base and Artifact organise and present the sources and output, while the highest tier supplies the depth the stakes demand.
A one-off drafting task with no reuse potential pairs plain Chat with a mid-tier model and no capability layer: nothing recurs, so a Project would be wasted setup, and the work is ordinary, so the mid-tier fits. A current-information lookup pairs Research or Chat web search with a mid-tier model rather than the highest: the value is in reaching current sources, which Research or web search provide, and the reasoning involved rarely needs the top tier. These four pairings are worth recognising on sight.
One pairing cuts across the others: when a task's output includes numbers that must be right -- projections, reconciliations, figures that will be reported -- the capability layer enters the decision alongside the surface and the tier. Such a task calls for Code Execution, which runs the calculation and returns a verified result rather than a plausible-looking one, and it usually takes an efficient or mid tier rather than the top one, because the correctness comes from executing the code, not from a more capable model. A recurring verified-numeric workflow therefore lands on a Project plus Code Execution plus a mid tier; a one-off calculation on a defined dataset lands on Code Execution plus an efficient or mid tier with no Project. The tell that Code Execution belongs in the pairing is a stated need for accurate computed output, not merely fluent prose.
Why the two axes align
The pairings are not arbitrary; they align because both decisions read the same task features. Recurrence and stable context are exactly what make a Project worth building, and they usually coincide with ordinary professional work that the mid-tier handles -- hence Project plus mid-tier. High stakes and nuance are what raise the tier to the top, and they usually coincide with multi-source deliverables that benefit from a knowledge base or Artifact -- hence Project-or-Artifact plus top tier.
This alignment is why reading the task profile once is efficient: the same read informs both axes. But alignment is a tendency, not a guarantee, which is why the exam sets the trap of getting one axis right and the other wrong. A recurring task might correctly get a Project but wrongly get the top tier; a high-stakes deliverable might correctly get the top tier but wrongly be left in plain Chat with no knowledge base. The discipline is to check both axes explicitly against the profile rather than assuming that fixing one fixes the other.
What the CCAO-F exam trips candidates on
Two errors are tested. The first is picking the correct model tier but the wrong entry point for the same scenario, or vice versa. A partial answer that nails one axis and misses the other is still wrong; the credited answer is coherent on both. This is why scanning both axes against the profile matters.
The second is defaulting every scenario to the same entry-point-plus-model combination regardless of the stated task characteristics. The tell is a one-size-fits-all pairing applied across scenarios that clearly differ in recurrence, stakes, or information needs. The credited reading matches each scenario to its own pairing, letting the task's stated characteristics drive both choices.
Worked example
A consultant faces three tasks in a day: a weekly client status report in a fixed format that she produces every week; a one-off, high-stakes board analysis synthesising four uploaded reports with ambiguous signals; and a quick check of a competitor's product launch announced this morning. She is tempted to run all three in Chat on the top tier 'to be consistent.' Evaluate the right configuration for each.
Running all three the same way is the one-size-fits-all trap; the three tasks differ on exactly the axes that should drive both decisions. Take them in turn, checking entry point and tier against each profile.
The weekly status report in a fixed format recurs with stable context, which is the signature of a Project -- setting the format and background once so each week starts primed. The work is professional but not extreme, so a mid-tier model fits. Project plus mid-tier. Running it in Chat would re-load context every week, and the top tier would over-provision capability the report never needs.
The one-off board analysis synthesising four ambiguous reports is nuanced, high-stakes, and multi-source. The four reports belong in a knowledge base, and the deliverable belongs in an Artifact, while the ambiguity and stakes genuinely earn the top tier. Project-or-Artifact plus top tier. Leaving it in plain Chat on a mid-tier would under-resource both the organisation of sources and the depth of reasoning.
The quick competitor-launch check is a single current fact from essentially one source, so Chat web search (or Research if it needs synthesis, which it does not) suits it, paired with a mid-tier model -- the top tier is unwarranted for a lookup. Three tasks, three distinct pairings, each read from its own characteristics. "To be consistent" is precisely the reasoning to reject.
Common misreadings to avoid
Misconception
Getting the model tier right is enough, even if the entry point is off.
What's actually true
Misconception
A single entry-point-plus-model combination can be applied to every task for consistency.
What's actually true
How this shows up on the exam
Questions present a professional scenario and ask for the configuration, with distractors that fix one axis and break the other, or apply a uniform pairing. Read the profile and set both axes from it: recurrence and stability point to a Project, stakes and nuance point to the tier, information needs point to Research or web search. The reliable answer is coherent across both surface and tier.
This knowledge point combines the project worth-building test, Research vs web search vs Artifacts, and matching tier to stakes, and it leads into avoiding over-engineering and under-resourcing.
A consultant produces a fixed-format weekly client report, tackles a one-off high-stakes board analysis from four ambiguous uploaded reports, and needs a quick check of a competitor launch announced this morning. Which set of configurations fits?
People also ask
Do I choose the entry point and model separately?
What configuration fits a recurring structured task?
What fits a high-stakes multi-source deliverable?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.