Claude Models, Prompting & Context Engineering

Koko: Here is the one instinct that governs this entire lesson: match the lever to the observed failure, and try the cheap lever first. That is it. Everything else in Domain Two is a specific application of that rule.

Sam: And the reason I wanted to nail this down before anything else is that in a design review, someone will always ask why you did not just upgrade the model. You need a principled answer, not a shrug.

Koko: Exactly. And the domain is thirteen percent of the Professional exam — smallest of the technical domains — but the questions are the sharpest, because at this level nobody is asking what a technique does. They are asking which lever you pull, and what pulling it costs.

Sam: That shift from Foundations to Professional trips people up. Foundations rewards knowing that few-shot prompting improves format consistency. Professional rewards knowing when a format problem does not warrant touching the model at all.

Koko: Right. So let us start with the fact, which is how model selection actually works according to the documentation. There are two defensible starting positions. The first is efficiency-first: you begin with a fast, economical model, test it thoroughly against your evaluation set, and upgrade only where you find a genuine capability gap. The second is capability-first: you begin with the strongest model for the task, tune the prompt against that ceiling, and then negotiate the model down as your requirements get clearer and your constraints get tighter.

Sam: And the criteria the docs name for making that call are capabilities, speed, cost, and effort — and effort is the one people underweight. The documentation is explicit that tuning the effort parameter is often a better lever than switching models.

Koko: That is the piece that catches people. They see a quality problem and they reach for a bigger model before they have tried the effort dial or added one well-chosen example. Now let us make that concrete.

Koko: The scenario: two features, same team, same week. First, a support-summarization feature. Volume is high, the task is bounded — extract issue type, customer sentiment, and resolution — and a missed sentence costs almost nothing. That feature starts efficiency-first. You run the economical model, measure against your evaluation set, and upgrade only if the numbers say you have to.

Sam: The second feature is a contract-risk reviewer. A missed indemnification clause could cost the business real money. That one starts capability-first — you want to know the ceiling before you start negotiating it down. You prompt against the strongest model, learn what the task actually requires, and then decide whether a lighter tier can hold it.

Koko: And both teams use the same evaluation set across the whole process, so the comparison from tier to tier is apples to apples. That evaluation set is, and I want to quote the framing here, the most important step. You build it first. Then you let the numbers tell you which tier you need.

Sam: The instinct I try to install on my teams is: if you cannot point to a metric that failed, you do not have a justification for a model swap. You have a feeling.

Koko: That is the instinct exactly. Now the analogy, because this mechanism needs to stick. Think of an escalation desk at a large support centre. You have first-line agents handling the volume — fast, trained for the common cases, and cheap to staff. You have a specialist in the back for the hard ones. Nobody staffs the entire desk with specialists just to be safe, and nobody routes every call to the specialist because they are technically the best. You match the call to the agent.

Sam: And the key detail in that analogy is that the specialist is not idle — they are handling the cases that actually require them. You are not paying specialist rates for calls that first line can close in two minutes.

Koko: Which maps directly to the documented multi-model patterns. You pair tiers so most tokens bill at the lower rate. The frontier model only touches the work that genuinely needs it.

Koko: So the takeaway is this: build your evaluation set first, let the numbers pick the tier, and reach for the effort parameter and for prompt work before you reach for a different model. When you do pair models, make it deliberate — not because the frontier model is available, but because the task difficulty at that step actually demands it.

Sam: And the pairing question is worth pressing on, because that is where the trap lives. What is the specific misconception the exam is going to put next to the right answer?

Koko: The misconception is that one model should serve the whole system. A single tier for the entire product. It feels clean, it feels consistent — one API key, one pricing tier, one thing to monitor. But model choice is per step, not per product.

Sam: The version I keep seeing on teams is the assumption that standardizing on the strongest available model is the safe, defensible choice. And the answer to that in a design review is: safe from what? Not from the cost overrun, not from the latency budget, not from the evaluation showing the lighter tier was already sufficient.

Koko: The documented patterns give you the architecture for this. One pattern is an executor that escalates hard decisions to a stronger advisor. Another is an orchestrator that delegates bulk work to cheaper workers. In both cases, the frontier model is positioned only where the difficulty actually is — not across the whole product because it is there.

Sam: So the exam answer that says 'use the most capable model throughout to maximize quality' is not a conservative choice. It is an unexamined one.

Koko: That is the distinction. Conservative means you have weighed the options. Unexamined means you reached for the biggest tool and called it safety. The one instinct in this domain is: match the lever to the observed failure, try cheap first, and let the evaluation set make the call. Everything else in this lesson builds on that.

Koko: So the first thing to get right here is what these three techniques actually are for, because the exam will test whether you can tell them apart under pressure. Zero-shot, few-shot, and chain-of-thought are not a quality ladder. They are not strength one, strength two, strength three. They are treatments for different symptoms.

Sam: That framing matters a lot in practice. The failure mode I see on teams is reaching for more structure the moment output quality dips, without stopping to ask what kind of quality problem it actually is.

Koko: Exactly. So let's ground the three. Zero-shot stays the default for tasks that are unambiguous. The instruction is clear, the model handles it. Done. Few-shot is the fix when you have format inconsistency or edge-case drift — when the shape of the output keeps wandering or a particular input class keeps going wrong. You show the model what the right output looks like across a few representative cases and the behavior settles.

Sam: And the third one is where it gets more interesting. For reasoning failures — not formatting, not edge cases, actual logic errors — the preferred move on a model that supports it is enabling adaptive thinking and sweeping effort level against your eval set.

Koko: Right. And manual chain-of-thought — where you explicitly write out step one, step two, step three in the prompt — that is a fallback. It's what you do when thinking is off and you cannot turn it on, not the normal control for a thinking-capable model.

Sam: So the decision tree is: classify the failure first. Is it a shape problem? Is it a logic problem? Then pick accordingly.

Koko: Let's make that concrete. Two steps in the same pipeline. First step is an extraction task — pulling structured fields out of unstructured text. The output shape keeps varying, some records have extra keys, some are missing a field, certain input formats break the pattern. That is a format and edge-case failure. The fix is few-shot. You write three examples that are deliberately diverse — easy case, weird case, the edge case that was breaking — and the output settles.

Sam: And the diversity of those examples is doing real work. Three identical-looking examples teach the format but they don't cover the edges that caused the drift in the first place.

Koko: Good point. Second step in the same pipeline: pricing eligibility. The model is checking conditions and returning a verdict, and the reasoning is wrong — it's reaching correct-looking verdicts through incorrect logic, or it's missing a condition entirely. That is a reasoning failure. So you enable adaptive thinking, you sweep effort level — low, medium, high — against your eval set, and you pick the level where it stops making errors. And in the output, you ask for the conditions checked and the final verdict, not a free-form explanation.

Sam: The effort sweep is worth emphasizing. Higher effort costs more tokens and more latency, so you're not just setting it to maximum and calling it done. You find the level where the reasoning holds and stop there.

Koko: That's the discipline the exam is looking for. Now, the analogy I want to leave in your head for this whole set of choices: a clinician picks the treatment from the symptom. Nobody prescribes the strongest thing on the shelf because the patient is important. The severity of the use case is not the variable. The nature of the failure is the variable.

Sam: Which means you have to observe the output before you touch the prompt. What's actually failing — the shape, the coverage of edge cases, or the reasoning chain?

Koko: That is the instinct to carry into the exam room. Classify the failing output before you touch the prompt. Format and edge-case failures want examples. Reasoning failures want thinking enabled plus an effort sweep. And when the application genuinely needs an auditable output — a compliance check, a pricing decision — you ask for the evidence, the conditions checked, the decision rationale. The structured information the reviewer actually needs.

Sam: On that last point — the version of this I keep seeing on teams is treating the thinking trace as the audit artifact. As if capturing the intermediate steps in the output is what auditability means.

Koko: And that is the trap worth saying slowly. There are two of them actually. First: treating visible intermediate steps as the default reasoning control. Manual chain-of-thought adds output tokens and latency and can over-prescribe a path the model would reason through better on its own. It is a deliberate fallback, not a general upgrade. Second, and sharper: do not ask for private thinking as an audit artifact. The model's internal reasoning process is not an audit log. If you need auditability, you request the evidence — the checks performed, the conditions that were evaluated, the rationale that a human reviewer actually needs to verify the decision. Those are different things, and the exam will put them next to each other.

Sam: So the exam question might describe a system that needs an auditable trail and offer chain-of-thought output as the answer, when the right answer is structured evidence in the response.

Koko: Exactly that. Observe the failure, name it precisely, match the technique to that failure and nothing stronger. That's domain two thinking.

Koko: Here is the fact: in a long-running agent, four distinct things compete for the context window. Tool definitions loaded upfront. Accumulated tool results. Conversation history. And thinking blocks. Those are the four claimants, and each one has its own documented remedy. They are not interchangeable.

Sam: And that mapping matters because I have watched teams apply the wrong fix. They hit the ceiling and reach for the first lever they can find, which is usually just trimming history, when the real culprit might be tool results that have been sitting in the window since turn three.

Koko: Exactly. So let me name the four remedies before we go further. Tool search keeps definitions out of the window until they are actually requested — so you are not paying for the definition of a tool you have not called yet. Context editing clears old tool results server-side once they have done their job. Compaction condenses the conversation history. And prompt caching does not shrink the window at all — it changes what repeated content costs to process, but the tokens are still there.

Sam: That last one is the one worth pausing on. Caching is a cost remedy, not a space remedy. The window is still full.

Koko: Right. And the exam will absolutely put those two next to each other. Now let me give you the scenario, because this is where the four-way distinction stops being abstract. A research agent has run for two hundred turns and is at the ceiling. The team enables context editing with a trigger threshold and a keep count, so the last few tool results survive — because you do not want to delete results you are still reasoning over. They also exclude one specific tool whose results are still load-bearing for the current task.

Sam: That exclusion flag is doing real work there. If you clear indiscriminately you can delete something the model still needs for the next step.

Koko: And the third parameter the team sets is a minimum amount to clear per operation. This one has a precise reason. Clearing old tool results invalidates the cached prefix for whatever comes after it. If a single pass only recovers a handful of tokens, the cost of rewriting that cached prefix exceeds what you saved. So a pass that clears less than the minimum threshold is a net loss, and the system should wait until there is enough to clear to make it worth it.

Sam: So the minimum-clear setting is essentially a break-even guard. You are not clearing for the sake of clearing — you are clearing when the savings outrun the cache rewrite cost.

Koko: That is the right way to hold it. Now for the analogy. Think of a suitcase with a strict weight limit and four people packing it. Each person packed different things. When you hit the limit, you cannot fix it by weighing the bag again. You have to open it and find out who packed what — because the right move for a pair of heavy boots is different from the right move for a stack of papers. Same problem, four different solutions.

Sam: And the version of this I keep seeing on teams is people running compaction on the conversation history when the actual mass is tool results from a long search loop. They compress the wrong compartment.

Koko: Which is why the takeaway is: find out where the tokens actually went before you choose a remedy. Not after. The four fixes address four different sources, and the minimum-clear parameter exists as a reminder that clearing is not free — it has its own cost structure.

Sam: What is the precise question to ask when diagnosing? Is it just token counts per category?

Koko: Token counts by source, yes — how much is definitions, how much is accumulated results, how much is history, how much is thinking. Once you see the distribution you can match it to the remedy. If definitions are the bulk, tool search. If results are piling up, context editing. If the history is sprawling, compaction. If the cost is high but the window is not full, caching.

Sam: That diagnostic frame is actually the thing I would want someone to memorize going into this exam.

Koko: Now here is the trap, and it is a seductive one. The misconception is that a bigger context window removes the problem. It does not. A longer window changes when you hit the wall, not whether you hit it. And more importantly, as irrelevant material accumulates — old tool results no longer relevant to the current task, tool definitions for tools you called on turn twelve — attention degrades and cost climbs even before you reach the hard limit. Context editing exists because removing dead weight improves focus, not only because it saves money. The exam will offer you a larger window as the architectural answer to runaway context. It is not.

Sam: The option next to it on the exam will say something like 'upgrade to the model with the largest available context' and that will look like the scalable architectural choice.

Koko: And it buys you time, not a solution. The right answer is to manage what is in the window, not just widen it. Know your four claimants, match them to their remedies, and mind the break-even on every clear operation.

Koko: Two reuse mechanisms, and the exam will absolutely make you choose between them. Let's get the distinction clean. Prompt caching saves you money on the same tokens. You have a stable prefix — system prompt, policy extract, tool definitions — and instead of paying full price every time, cache reads come in at a fraction of the base input price. Cache writes carry a small markup, so break-even lands on the second hit. From the third request onward, you are ahead.

Sam: And the tokens are still going into context every time — you are just paying less for them.

Koko: Exactly right. The tokens are there. The cost is reduced. Now Agent Skills work differently. Skills send fewer tokens. The mechanism is progressive disclosure — only the Skill's name and description sit in context at startup. The actual instructions load when that Skill is triggered. Bundled files, scripts, anything attached to it — none of that costs you a thing until it is actually read or run.

Sam: So the distinction is: caching pays less for what is there, and Skills leave most of it outside the context entirely until it is needed.

Koko: That is the whole module in two sentences. Let's make it concrete. Document-review service. Every request comes in with the same system prompt, the same policy extract, and the same tool definitions. One cache breakpoint goes on the last block that is identical across every request. Everything before that breakpoint is cached. The variable document — the thing that changes per request — sits after the breakpoint and is never part of the cache prefix.

Sam: And separately, the same service has three domain procedures — say, revenue recognition, contract risk, and disclosure requirements. Those move out of the system prompt and into Skills. A request about revenue recognition loads that one procedure. The other two never enter context.

Koko: Right. And before those moved to Skills, all three procedures were in the system prompt on every single call, whether the request needed them or not. That is pure waste.

Sam: The analogy you use here is one I've actually repeated in design reviews.

Koko: Caching is a season ticket. Same journey, lower fare. Skills are packing lighter — you did not bring the thing at all. Those are two genuinely different moves. A season ticket still requires you to carry it. Packing lighter means it stayed home.

Sam: And that maps cleanly onto the placement rule for the breakpoint. I've seen teams put it in the wrong spot and wonder why costs don't drop.

Koko: The takeaway on cache placement: put the breakpoint on the last block that is identical every time. If anything that varies appears before the breakpoint — a timestamp, the user's name, the actual question — the lookback never matches a previous request, so the cache write fires on every call. You pay the markup, you get nothing back.

Sam: The version of this mistake I keep seeing on teams is that they build a beautifully structured prefix, then include a request ID or a session timestamp at the top for logging purposes. Cache never hits.

Koko: Stable prefix, breakpoint, variable content after. In that order. And for Skills: reach for them when guidance is conditional. If a chunk of instructions only matters for some requests, it should not be in the system prompt paying full freight on every call.

Sam: The discriminator I'd use: is this guidance always relevant, or only sometimes? Always relevant, it belongs in the system prompt, possibly cached. Sometimes relevant, it belongs in a Skill.

Koko: That is the instinct the exam rewards. Now the trap, and this one is subtle. The Skill's description looks like documentation. It is not. It is trigger metadata, and it is the only part of the Skill that is always in context. That description has to do two things simultaneously: say what the Skill does, and say when to use it — in the actual words a real request will contain.

Sam: If the description is written like a README — 'this Skill handles revenue recognition procedures per ASC 606' — but real users ask 'how do we book this software contract,' the Skill sits there unused and the model improvises from whatever else is in context.

Koko: Unused guidance in a Skill is actually worse than unused guidance in a system prompt, because at least the system prompt text is visible. A Skill whose description doesn't match real requests is invisible and silent. The misconception is treating the description as a label for humans. It is a signal for the model, and it has to be written that way.

Koko: Before we land this domain, Sam — you have been working these systems. Walk me through the order of operations the way you'd hand it to a new architect on your team.

Sam: Classify the failure first — is this a behavior problem, a knowledge problem, a cost problem, a latency problem? Then try the parameter. If that does not move it, try the prompt. If the prompt can't reach it, fix the context — window size, caching, Skills, what is actually in there and when. And only after all of that do you consider changing the model. Because changing the model is the highest-friction move, and most problems are not model problems.

Koko: That order of operations is the spine of this entire domain. Classify, then parameter, then prompt, then context, then model. If you carry nothing else out of today, carry that.

Sam: And the context step has real sub-steps now — placement of the cache breakpoint, what goes in Skills versus the system prompt, how the Skill description functions. It is not just 'put stuff in the prompt.'

Koko: Domain two is thirteen percent of the exam, and it rewards exactly the kind of reasoning you just described — not what you reach for first, but why you reach for it in that order and what each choice costs. That is the Professional level distinction.

Sam: The drills are where this actually sticks. Flashcards are one thing, but the scenario questions are where you find out if the instinct is real.

Koko: Drills and flashcards for this domain are at KokoAI Academy — that is koko knows dot A I. Everything from module one through this one, with practice scenarios written to the Professional exam format. You have done the hard work sitting here — now go make it automatic. You are closer than you think.