CCA-F Signals & Moves — Part Two

Chris: So between sessions I went back through all five domains, drilled the decision rules from part one, and one pattern kept coming up over and over in the practice scenarios. Any time a scenario used the word always or never — always happens, may never happen, guaranteed compliance — I kept seeing it. I want that one nailed down cold.

Koko: You picked exactly the right one to open with, because that is the single highest-yield tell on the entire exam. And here is the thing — we actually closed part one on this instinct. We just named it at the domain level. What we are doing now is applying it at the level of individual items, which is where it gets sharp.

Chris: Right, part one was the shape of the rule. This is the rule meeting actual scenario language.

Koko: Exactly. So here it is, clean. Any time a scenario tells you that a step must always happen, or that something may never happen, or that compliance is guaranteed — the answer is a mechanism, not better instructions. Those two words, always and never, are the exam's way of telling you that a non-zero failure rate is unacceptable. And anything you write in a prompt has a non-zero failure rate. Always.

Chris: Because the model can still be prompted around it, or it misreads context, or the prompt just doesn't fire correctly in a weird edge case.

Koko: Exactly. So the analogy I keep coming back to: imagine a fire door. You don't put a sign on it that says please keep closed. You put a spring on it. The spring is the mechanism. It makes the wrong state — door open — structurally harder to reach. That is what the exam is asking for. A hook, a prerequisite gate, a code-level check — something that makes the non-compliant path structurally difficult or impossible, not something that asks nicely.

Chris: Okay so let me give you the cues I flagged. Scenario says: every refund over a threshold needs approval before it processes.

Koko: Gate. A prerequisite check that cannot be skipped — the refund does not move forward until approval is recorded. Not a note in the system prompt reminding the agent to ask for approval.

Chris: The disclosure step must run before publish.

Koko: Hook in the pipeline. Publish is literally unreachable unless disclosure has completed and returned a success state. Same move, different surface.

Chris: No agent may touch production without a ticket.

Koko: Code-level check. The agent's action against production is blocked at the API or tool layer unless a valid ticket ID is present. You are not telling the agent to check — you are making the call fail if it doesn't.

Chris: Same move every time. The cue changes, the answer doesn't.

Koko: That is the instinct the exam rewards. Now — here is the trap, and it is a real one. Not everything belongs in a hook. The trap is over-mechanizing. The exam will sit right next to the correct answer an option that says something like: add a hook that enforces consistent tone, or enforce formatting requirements at the pipeline level. And that sounds rigorous. It isn't.

Chris: Because tone and format are preferences, not hard constraints. They can be legitimately wrong in a specific context, and you need to be able to override them.

Koko: Right. The rule for what gets a hook has three parts: stable, checkable, and consequential. Stable means the rule does not change with context. Checkable means you can write a binary test for it — approved or not, ticket present or not. Consequential means getting it wrong causes real harm. Tone preferences fail all three. A refund approval requirement passes all three.

Chris: So the discriminator is: does it meet all three? If yes, enforce. If it fails any one of them, it stays in the prompt.

Koko: That's the line. And that line is what the exam is drawing when it says always or never. It is telling you all three conditions are met, so stop reaching for a better prompt and reach for a gate.

Chris: So last module we were working through signal-to-move. I want to get into the loop family, because this is the one that burned me in practice exams. The cue I kept seeing: anything in a scenario about an agent that keeps going when it should stop, or stops when it should keep going.

Koko: Right, and both of those are the same root problem dressed in opposite clothes. The loop is driven by exactly one thing: the stop reason. Not the text, not the tone, not whether the reply sounds like it wrapped up — the stop reason field.

Chris: So tool use as a stop reason means: run the tool, append the result, come back around.

Koko: Exactly. The model is mid-sentence, functionally. It handed you a tool call the way a surgeon hands you a scalpel mid-operation — the work is not done, it is paused waiting for the result.

Chris: And end turn means the work is finished. The loop exits.

Koko: Full stop. End turn is the model saying I am done. You do not iterate.

Chris: Here is where the exam makes it hurt. What if the reply text looks completely finished — clean summary, the works — but the stop reason is tool use?

Koko: You iterate anyway. The reply is not the signal. The stop reason is the signal. The prose can sound like a polished conclusion while the stop reason is screaming tool use. If you read the text and decide you are done, you have just abandoned a pending tool call mid-flight.

Chris: And the trap the exam sets is an answer choice that says something like: inspect the reply text and if it appears complete, exit the loop.

Koko: That is the trap, yes. It sounds sensible — of course you read the reply — but it puts the wrong field in charge. The stop reason is authoritative. The text is explanatory.

Chris: Flip side: the reply sounds tentative, hedged, like the model is not sure it finished — but the stop reason is end turn.

Koko: Same rule. You exit. Tentative prose on a completed turn is still a completed turn. The model's uncertainty about its answer is not an instruction to loop.

Chris: Okay, second tell in this family — an agent that never terminates at all, or one that terminates way too early. The scenario usually describes runaway iteration or a premature exit.

Koko: Both of those are loop architecture problems. Never terminates — you have a loop with no iteration bound, and probably no stop-reason check, so it just keeps calling the tool forever. Terminates too early — the loop is reading the wrong field, something other than the stop reason, and it exits on a false signal.

Chris: And the move is: add an explicit iteration bound plus a proper stop-reason check. Both together.

Koko: Both together. Think of it like a kettle with a timer and a temperature sensor. The timer is your iteration bound — it cuts the power if something goes wrong. The temperature sensor is your stop-reason check — it cuts the power when the job is actually done. You need both because either one alone fails a different way.

Chris: The option sitting next to that in an exam item will say: rewrite the prompt to be more explicit about when to stop.

Koko: Which sounds appealing because prompts are the thing architects touch most often. But the termination condition lives in the loop logic, not in the prompt. A clearer prompt does not add an iteration bound. The trap is moving the fix to the wrong layer.

Chris: Stop reason first, bound second, prompt is not the answer. Got it.

Koko: That is the whole loop family. One field, two directions it can fail, one fix for both.

Chris: So in part one we mapped the five domains and talked about how the exam rewards instinct over recall. Module three is delegation — and you said there are exactly three signals to recognise. The first one is the phrase 'the subagent did not know about X.'

Koko: Right, and the mechanism behind that signal is the thing to lock in. Subagents start in isolation. They inherit nothing from the coordinator's context. Think of it like hiring a contractor who shows up with a blank notepad — whatever the coordinator learned before making the call, the subagent simply does not have unless someone writes it down and hands it over.

Chris: So the move is passing the findings explicitly, in structured fields. Not just dropping a transcript into the prompt.

Koko: Exactly. And the key detail is keeping content separate from its metadata in those fields. The finding itself in one place, where it came from and what confidence level it carries in another. That structure is what lets the subagent actually use the information rather than having to re-parse prose.

Chris: The option sitting next to the correct answer will say something like 'summarise the findings above' — which sounds like passing context but is just a prompt with no findings in it yet.

Koko: That is the trap, and it catches a lot of people because it looks like diligence. The word 'summarise' feels active. But if the findings are not already in the message, there is nothing to summarise. The subagent gets an instruction and a blank page.

Chris: Clean. Second signal: 'this takes too long.' The scenario has independent subtasks and the time cost is the symptom.

Koko: Yes, and the tell for the move is that word — independent. If the subtasks do not depend on each other's outputs, there is no reason to run them in sequence. The move is emitting multiple delegation calls in a single response.

Chris: Because delegating one at a time and waiting is serial by construction. The architecture forces the latency.

Koko: Exactly right. It is not a tuning problem, it is a structural one. The trap is reaching for something that looks like optimisation — caching, faster models, tighter prompts — when the scenario is actually describing a parallelism problem. The exam is asking about shape, not speed settings.

Chris: Third signal: 'restrict what the subagent can do.' And the discriminator here is what layer the restriction actually lives at.

Koko: This is the one I find most elegant. What a subagent may do is a property of its definition — its description, its system prompt, its tool restrictions. Not a property of the conversation that spawned it.

Chris: So scoping the coordinator does not scope the child. The option the exam wants you to pick wrong will be something like 'add an instruction to the coordinator's prompt telling it not to allow the subagent to call tool X.'

Koko: The trap, precisely. The coordinator's prompt controls the coordinator. To restrict the subagent, you have to go into the agent definition itself and remove or fence the tool there. The lock lives on the door, not on a note slipped under it.

Chris: Three signals, three distinct layers — context passing, call structure, permission scope. None of them overlap.

Koko: And that non-overlap is the point. The exam will mix the vocabulary to see if you reach for the right layer or the adjacent one. Blank-notepad subagent: pass structured findings. Serial latency on independent tasks: fan out in one response. Restrict capability: edit the definition, not the conversation. Each signal has one home.

Chris: So in part one we landed the hook taxonomy as a decision tree. Now I want to drill the discriminators, because the exam loves to blur them. The first pair: pre-tool-use versus post-tool-use. The signal that screams pre is 'prevent', 'block', 'stop it from happening' — anything that needs the action not to occur.

Koko: Exactly right. Think of it as a bouncer at the door. The bouncer works before anyone gets in — once they are inside, the bouncer is irrelevant. Pre-tool-use is the bouncer. The instinct the exam rewards is: if the scenario uses the word 'prevent', you are always upstream of execution.

Chris: And the trap on that one — the option sitting next to it will say something like 'inspect the tool result and flag it if the action was inappropriate'. Which sounds cautious, but that is post-execution. The action has already happened. You are writing a report about a crime rather than stopping it.

Koko: Perfectly put. Observation after the fact is not prevention. Now flip to post-tool-use. What signal gets you there?

Chris: 'Normalise', 'reshape', 'the formats coming back are inconsistent' — anything where the tool has already run and you need to clean up what it returned before the model sees it.

Koko: Right. Post-tool-use is not about stopping anything — it is about shaping what arrives back. The analogy I like: you ordered from five different restaurants and everything lands in different containers. Post-tool-use is the person who re-plates it all before it goes to the table. The tool ran. You are just tidying the output.

Chris: So the clean pair is: prevention is before, transformation is after. Now the delegation hooks, because that is where the exam gets sharper. There are two — one fires when a subagent starts, one fires when a subagent finishes. The start hook only observes. It cannot stop anything.

Koko: Correct. The start hook is read-only by design. It sees the subagent spinning up, logs it, records it, whatever — but it has no gate. The finish hook is the one with teeth. It fires on completion and can block with a reason, which sends the subagent back to work rather than letting the result through.

Chris: So the instinct is: if the scenario needs a quality gate on subagent output, you reach for the finish hook. If it just needs visibility into what subagents are being launched, the start hook is sufficient.

Koko: And here is the trap worth carrying out of this module: neither lifecycle hook rewrites a subagent's output. That is the thing people get wrong. If a question says 'use a subagent-stop hook to clean up what the subagent returns', that hook silently does nothing. The cleanup job belongs to a post-tool-use hook on the delegation tool itself — not the subagent's lifecycle hooks.

Chris: So the exam puts 'subagent finish hook' right next to 'post-tool-use hook on the delegation call', and the discriminator is: lifecycle hooks gate or observe, they do not transform. Transformation is always a post-tool-use concern.

Koko: That is the line. Gate or observe on one side, transform on the other. Once you see that axis clearly, the scenario language almost sorts itself — 'prevent' sends you before execution, 'normalise' sends you after, 'quality gate on a subagent' sends you to the finish hook, and 'clean up subagent output' sends you to post-tool-use on the delegation tool. Four signals, four distinct moves.

Chris: Okay, tool interfaces. The first signal in my notes is the agent picking the wrong tool, or getting confused between two that look similar.

Koko: Right, and the move is not what people reach for. The instinct is to patch the system prompt — say something like 'prefer tool A over tool B in these situations.' That feels like a fast fix.

Chris: And the option next to the right answer in those scenarios will say exactly that — add an instruction to the system prompt to resolve the ambiguity.

Koko: And it is a bandage over a design flaw. Here is the analogy: imagine two buttons on a control panel that are the same colour and the same size and sit right next to each other. Writing a sticky note that says 'use the left one' does not fix the buttons. And crucially, that sticky note does not travel with the buttons when you move the panel. The system prompt is not part of the tool.

Chris: So the move is fixing the tool descriptions themselves — written specifically for a reader who is deciding between this tool and the one beside it.

Koko: Exactly. Differentiation, not eloquence. The description does not need to be pretty. It needs to answer the question 'why this one and not the other one.' That is the instinct the exam rewards.

Chris: Good. Second signal: the agent treated a failure as data. My notes flag this as the error-flag problem.

Koko: Yes. Think of it like a cashier handing you a receipt that says 'your card was declined' but running it through the register as a completed sale. The surface looks like success. The information is buried in the text. A downstream system reading the success flag will never know.

Chris: So the move is always signal failure with the error flag — never a success payload whose text content happens to describe what went wrong.

Koko: Never. The error flag is the contract. Everything else is commentary.

Chris: Third signal is the retry loop. Agent retried and retried. My notes break the metadata into three pieces: category, a retryable flag, and a human-readable explanation — and they get read in that order.

Koko: In that order, yes. First question is not 'how long should I wait.' First question is 'can a retry ever work at all.' Category and retryable flag answer that before you touch the explanation.

Chris: Because the trap is retrying everything with backoff on the grounds that it is cheap.

Koko: The trap. And the exam will give you scenarios with three error types sitting together — a transient network error, a validation error, and a permission error — and the question is what to do. Retrying with backoff works for the first one. A validation error fails identically every single time. A permission error fails identically every single time. And a business rule violation — something like 'this order exceeds the daily limit' — resolves on zero attempts, because the resolution is not a retry, it is a human decision or a state change somewhere else.

Chris: So the discriminator is: read the category first, check the retryable flag, then and only then does the explanation tell you how to respond. If the flag says no, the explanation is for a human or a logging system, not for the retry logic.

Koko: That is exactly it. The instinct the exam rewards is structured triage, not optimistic retry. Backoff is a tool for uncertainty, not a substitute for reading the error.

Chris: So in part one we mapped the domains as decision trees. This block is the tool layer — same logic, earlier in the chain. The signal that gets me every time in a well-dressed scenario is when they give you a file-system question and both tools feel plausible.

Koko: Right, and the discriminator is always the same question: are you looking for something inside a file, or are you describing the file itself? Those are two completely different operations.

Chris: So the tells. 'Find where this function is called', 'find every usage', 'search for this string' — that is content search, full stop.

Koko: Every time. Content search reads the bytes inside the file. Think of it like a librarian who opens every book and scans the text. Path matching is the librarian who only reads the spine. She can tell you it ends in dot-py and lives in the utils folder. She cannot tell you what is written on page forty.

Chris: And the trap the exam sets is offering path matching as the adjacent option. The scenario will say something like 'locate all files related to this helper' and the option next to the right answer will say 'match by file name or extension'.

Koko: Exactly. And the trap is seductive because path matching sounds efficient. The worked example that makes this concrete: you are hunting a deprecated helper whose name also appears in changelog prose and in vendored copies of old code. Path matching gets you a list of files that could be relevant. Content search gets you the actual call sites.

Chris: And even then content search is not the last move. After you have the candidates you read the surrounding lines to separate a real call site from a mention in a comment or a changelog entry.

Koko: That is the instinct the exam rewards: search narrows, reading confirms. Two distinct steps, two distinct tools, in that order.

Chris: Now flip the signal. 'Match files by extension', 'find everything in this directory' — that flips to path tool.

Koko: Yes. When the description is about the file's location or its name, you are describing the file, not interrogating its contents. Path tool is exactly right there. The trap in that direction is reaching for content search out of habit because you just used it.

Chris: Then there is the edit signal. 'Change part of a file' — that is a targeted edit anchored on unique text.

Koko: Right. The anchor has to be unique. Think of it like a surgical incision — you mark the exact spot before you cut. When the anchor is not unique, the move is to extend it or replace across matches. It is not to retry the same anchor with more surrounding context and hope for a different result.

Chris: That retry instinct is the trap the exam puts in the adjacent option — 'add more surrounding lines to the anchor and re-apply'.

Koko: And the other boundary is whole-file write, which is for whole-file replacement. Scenario says you are rewriting the entire file — that is the signal. The trap there is using a targeted edit when the scope is actually the whole thing. You end up with a half-measure that is harder to reason about.

Chris: So the instinct across all of this is: read the scope of the question before you pick the tool. Inside the file, outside the file, part of the file, all of the file — each one has its own move and the exam will always put the neighbouring move one option away.

Koko: That is the whole drill. Scope first, tool second, and never let efficiency arguments talk you into the wrong layer.

Chris: The one I kept seeing misread in practice items is the 'works for me, not for the new joiner' scenario. That is a placement signal, not a content signal.

Koko: Exactly right. The rule is fine — it's where it's sitting that's broken. Think of it like a whiteboard in your office versus a whiteboard in the shared kitchen. If only you can see it, only you benefit. Anything the whole team has to share lives at project level, not user level.

Chris: And the discriminator is whether the behavior is personal preference or a team convention. Personal preference stays at user level; team convention moves to project.

Koko: That's the instinct the exam rewards: ask whose behavior needs to change, not what the instruction says. If the answer is 'everyone on the team,' the config belongs at project scope.

Chris: The option next to the right answer will usually say to copy the instruction into the new joiner's user settings — which papers over the problem without fixing the placement.

Koko: Right, the trap is solving it for one person instead of fixing the level. Now, second signal: the scenario says a convention applies to files scattered across dozens of directories.

Chris: Directory-level config only covers its own directory. So if the file type moves, the rule doesn't follow it. The move is path-pattern rules keyed to file type, not location.

Koko: Good. The analogy: directory-level config is a sign on one door. A path-pattern rule is a dress code that travels with the person no matter which room they walk into. The signal phrase to listen for is 'spread across' or 'wherever that file type lives.' That's the breadcrumb.

Chris: Third signal in the notes is 'check what actually loaded' — that's the memory diagnostic. It reports what files are in play. It doesn't trigger a reload; configuration loads from its location on its own.

Koko: This one trips people up because the diagnostic looks active. You run it, you see output, it feels like it did something. It didn't. It's a read, not a write. The trap is adding another copy of the instruction at a higher level because you think the original isn't being picked up — and now you've hidden the placement bug under a duplicate.

Chris: So the move when something isn't loading is to check the diagnostic first to confirm the placement, then fix the placement — not stack another copy on top.

Koko: Exactly. Diagnose before you duplicate. Last signal for this block: multi-file change with several viable approaches.

Chris: Plan first. The trigger is breadth plus multiple defensible designs — not how high-stakes the task feels.

Koko: That distinction matters because the exam will dress scenarios where a task sounds urgent or important but is actually narrow and clear-cut. Importance is a red herring. The real triggers are: does it touch multiple files, and is there more than one reasonable way to do it? Both boxes checked — plan before you move.

Chris: The adjacent option will say to start the change immediately because delay costs time. That is what they want you to reach for when the scenario emphasizes urgency.

Koko: And urgency is almost always the dressing on that particular trap. The instinct the exam rewards here is: more paths forward means more surface area for a mistake. Plan first, move second.

Chris: Alright, picking up where we left off. Output shape is the first tell in this block. The cue in the scenario is something like the format keeps varying across responses.

Koko: Right, and the instinct the exam rewards there is demonstration over description. Think of it like teaching someone to fold a napkin. You can write three paragraphs about crease angles, or you can just show them two examples. Two or three concrete input-output pairs lock in a shape faster than any amount of prose about the shape.

Chris: So the signal is inconsistency, and the move is examples — not a written description of the format you want.

Koko: Exactly. If the scenario says the model keeps formatting differently, you add examples. That is the discriminator.

Chris: Next tell: machine-parseable output. The cue is usually something like the downstream system needs to consume this directly.

Koko: And that cue splits into two moves depending on what is being consumed. If the answer itself is the deliverable — a JSON object the system reads — you want structured outputs, a declared schema the platform enforces. If the result is a tool call, you want a strict tool schema. The discriminator is whether the output is a data answer or an action request.

Chris: Got it. Data answer goes to structured outputs, action request goes to a strict tool schema. Now — what does having a schema actually buy you? Because that is the question I kept pressing in my notes.

Koko: It buys you exactly one thing: it removes the syntax class of error. A schema eliminates malformed JSON, wrong field names, the wrong data type in a field. That whole family of failures goes away.

Chris: But a response can be structurally perfect and still be factually wrong.

Koko: Schema-valid is not the same as correct. A response can satisfy every structural rule and still be wrong about the world. So when a scenario says the system needs to ensure the output is correct — that word correct — the schema cannot perform that check. That is asking for something else entirely, like a retrieval step or a verification layer.

Chris: That is a clean discriminator. Scenario says parseable, reach for schema. Scenario says correct, schema is not the answer.

Koko: Nail it. Last tell in this block: validation failed. The cue is an explicit failure — the output did not pass a downstream validator.

Chris: And the move is retry with the error fed back in. The option sitting next to it in the exam will say just retry — no additional context. That is what they want you to reach for, because retry sounds reasonable.

Koko: The trap is the blind retry. A blind retry samples the same distribution and tends to fail the same way. Nothing changed, so the odds do not change. But when you feed the specific validation error back in, the second attempt has information the first did not. That is a different call.

Chris: So the tell that it is a blind retry trap is that the option gives you no mechanism for why the next attempt would differ.

Koko: Precisely. If the retry has no new information, it is not a strategy, it is just hoping. The exam rewards the informed retry — error in, better output out.

Koko: Alright, context window. We said in part one that the window is the scoreboard — everything you can't fit is gone. Now let's get specific about the tells.

Chris: The first signal I have in my notes is the codebase scenario: hundreds of files, unfamiliar system. The cue phrases are things like 'the codebase does not fit' or 'help me understand this large unfamiliar system'.

Koko: Exactly. And the move is directed and incremental. You find the entry points, you read what the execution flow actually reaches, you follow the imports that carry it forward — and critically, you carry summaries forward, not the files themselves. Think of it like a detective who takes notes at each scene instead of dragging the whole crime scene to the next one.

Chris: Right, because dragging the files themselves is what evicts the relevant material. The option sitting next to the correct answer will say something like 'read all files first so nothing is missed' — and that framing of thoroughness is exactly what the examiners are dressing it up as.

Koko: That is the trap, and it wears the costume of thoroughness. It sounds responsible. But what it actually does is spend the entire window before you reach the answer, and then the part you needed most gets pushed out. Thoroughness that evicts the answer is not thoroughness — it is just expensive noise.

Chris: So the instinct the exam rewards is: surgical first, comprehensive never.

Koko: Surgical first, comprehensive never. Lock that in. Now, second signal — same domain, different symptom.

Chris: The agent contradicted something established earlier in the conversation. That is context loss showing up as behavioral inconsistency.

Koko: And the move?

Chris: Summarisation and re-grounding. You compress what has been established, you put it back in front of the model explicitly. The option next to it will say 'switch to a larger model' — bigger context limit, problem solved.

Koko: And that is a seductive option because it sounds like the architectural solution. But a larger model does not fix the reason the relevant state fell out — it just delays the same problem. The move is to manage what is in the window deliberately, not to hope a bigger window rescues you from not managing it.

Chris: So the discriminator between 'summarise and re-ground' versus 'larger model' is whether the problem is window size or window management.

Koko: Precisely. Contradiction mid-conversation is a management signal, not a capacity signal. Third tell — the scenario asks about agent confidence.

Chris: This one is subtle. The cue is something like 'how confident is the agent in this output' or 'the agent reports high confidence'. The trap the examiners set is treating the model's self-reported confidence number as calibrated to your definition of a false positive.

Koko: Right. A model's stated confidence is not yours to use directly. It is a number the model produces about itself — it is not calibrated to your cost structure, your risk tolerance, your definition of what a false positive actually costs. The move is: require a stated categorical condition — 'this claim holds if X' — and require provenance — 'this comes from source Y'. That is information you can act on. A percentage you cannot interrogate is not.

Chris: So the instinct is: condition plus provenance beats a confidence score every time.

Koko: Every time. And notice the thread across all three: the window is the scarce resource, and every move here is about protecting what is in it — what you let in, what you carry forward, and what claims you actually stake on its contents.

Koko: Alright, cost and throughput. The scenario gives you a big neon sign: the words cheaper, overnight, large volume, nobody waiting. When you see that cluster, the exam is pointing at one path.

Chris: Asynchronous batch. All three of those together — high volume, no user sitting there, cost pressure — that is the tell. The scenario is describing work that can queue.

Koko: Exactly. Think of it like a commercial laundry versus a dry-cleaner you wait in. Same cleaning, completely different operating model, chosen by whether someone is waiting. Batch is the commercial laundry: you drop off a truckload, it runs overnight, it costs a fraction per item. The instinct the exam rewards is: when nobody is waiting, stop paying for the express lane.

Chris: And the notes call out three traps inside that signal. The first one is the word blocking. The option next to the right answer will describe a pipeline or a developer process that waits on the result — and it will still frame it as batch-eligible because the volume is high or the cost savings sound attractive.

Koko: Right, and that is the trap: anything a developer or a downstream pipeline is actively waiting on stays synchronous. Volume and price do not change that. If something is blocking, it is blocking. The test will dress that trap nicely — it might say the pipeline runs on a schedule, but if it then waits on the response before the next step, you are back in synchronous territory.

Chris: Second trap — the phrase results usually arrive quickly. The notes are explicit: batch has a long processing window and no latency guarantee. So the discriminator is, do not schedule against the turnaround you happened to observe.

Koko: Schedule against the worst case. That is the instinct. The observed turnaround is just one data point. The exam will give you a scenario where someone clocked the typical response and built a deadline around it — the trap option will say something like, in practice responses return within the hour, so a two-hour SLA is fine. No. You plan for the ceiling, not the average.

Chris: Third trap is the multi-turn agentic loop. The option next to the right answer will describe a workflow that calls tools across several turns and label it batch-eligible because the individual requests look self-contained.

Koko: And the key word there is self-contained. Batch handles requests that are complete in themselves. The moment the workflow needs to call a tool, get a result, decide what to do next, call another tool — that is a loop. It depends on state across turns. That loop stays synchronous. The trap is thinking about the token cost of each call rather than the shape of the whole workflow.

Chris: Then there is a separate signal: reduce spend on a working system. That one is different because the system is already live and functional. The notes say the move is smaller models on narrow well-specified steps, and caching what repeats.

Koko: Not fewer checks — that is the trap the exam loves here. The scenario will show a working, safe system with a budget problem, and the tempting option will propose removing a validation step or collapsing two passes into one to save money. That trades safety for cost. The right move is surgical: find the steps that are narrow and repetitive, put a smaller model there, cache the outputs that do not change. The system keeps working; the bill shrinks.

Chris: So the discriminator between the two cost signals is: high-volume, no-wait work points you to batch; an existing system with a budget problem points you to right-sizing and caching, not restructuring the safety architecture.

Koko: That is the whole frame. Two signals, two moves, and the traps are always about confusing the shape of the work — blocking versus queueable, looping versus self-contained, trimming cost versus trimming checks.

Koko: Alright, tools. And we are grouping by job, not alphabetically, because the exam never says 'name a tool' — it says 'which one', which means it is always a choice between neighbours.

Chris: Right, and the neighbours are close enough that the question is always about the discriminator, not the definition. So let's run them. Reading and writing: read takes the whole file, write replaces the whole file, edit makes a targeted change anchored on unique text. Edit is the default for partial changes.

Koko: Exactly. Think of write like painting over a wall — you get the colour you want but you cover everything else. Edit is more like patching a crack. The trap is reaching for write when you only need to change three lines, because now you have silently overwritten everything around them.

Chris: And when the anchor text is not unique, you extend the anchor or replace across all matches. The failure is loud, so it never silently mis-edits — that is the safety property worth remembering.

Koko: Good. Now finding things — this is the single most reliably examined distinction in the tool set, so I am going to say the discriminator twice. Grep searches file contents. Glob matches file paths.

Chris: Contents versus paths. 'Where is this function called' is grep. 'Give me every JSON file in the project' is glob.

Koko: Exactly that. The option sitting next to the right answer will swap them — the scenario says 'find all usages of this method' and the trap option says glob. Do not take that bait.

Chris: Running things: bash. Builds, tests, version control. And the note I flagged from the material — bash is the one whose blast radius is worth scoping deliberately, because it can do anything the shell can.

Koko: Right, that is the flag the exam plants. Bash is powerful, which is precisely why you think about scope before you hand it a broad command. Moving on — delegation.

Chris: Task tool, now named Agent, with Task kept as an alias. Spawns a subagent. And the coordinator must have it in its allowed tools or the spawn is not auto-approved, which in a headless run means it gets denied.

Koko: Each subagent gets an agent definition — description, system prompt, tool restrictions. That is the configuration unit. Now, configuration surfaces. Memory files sit at user, project, and directory level. The sharing boundary is project level — that is the one the team can actually see.

Chris: Path-pattern rules handle conventions that follow a file type. Skills are declared in frontmatter, carry their own allowed and disallowed tools, and get an argument hint that shows the expected parameter at autocomplete. Plus context forking, so a verbose skill does not pollute the session.

Koko: And slash commands: project-scoped for the team, user-scoped for yourself. That distinction will show up. Now diagnostics — the memory command, or context command in current Claude Code. It reports which configuration files are loaded.

Chris: It reports, it does not trigger loading. That is the trap — the option will say it loads or reloads config, and it does not.

Koko: Plan mode before multi-file work with several viable designs. It is a thinking tool, not a doing tool. Hooks, by verb: pre-tool-use intercepts before the call and can block. Post-tool-use transforms after. Subagent-start observes a spawn. Subagent-stop can gate a finish by blocking with a reason.

Chris: And none of them rewrite a subagent's output. That is a hard line. The trap on hooks is assuming post-tool-use or subagent-stop can modify what the subagent produced — they cannot.

Koko: Last one — session control. Resume continues a named conversation. Forking branches from a shared baseline to explore divergent paths. The exam will offer both in the same scenario, and they are not the same move.

Chris: Resume is continuity. Fork is exploration. If the scenario says 'try two different approaches without affecting each other', that is forking. If it says 'pick up where this session left off', that is resume.

Koko: That is the whole surface, grouped by job. The instinct the exam rewards across all of it: match the tool to the scope of the operation. Read the scenario for what the job actually is, not what sounds closest alphabetically.

Chris: So part one gave us the six shapes — the frames you recognise on sight. This is the next layer: you have the brief in front of you, what do you actually pull out of it before you touch the first item.

Koko: Exactly, and the failure mode I see constantly is candidates reading the brief like it is a story. They absorb it, they nod, they feel informed, and then they answer from vibes. What you want to do instead is mine it — four specific things, in order, before you read a single answer option.

Chris: First extraction: who acts, and on whose authority. The brief is going to tell you whether each actor carries their own permissions or whether something upstream owns the credential.

Koko: Right, and the moment the brief says something like each user must retain their own upstream authorisation, it has just told you the items will test per-user scoping. Any option that hands the service one shared credential is dead before you finish reading it. You don't have to evaluate it — it violated a constraint the brief stated explicitly.

Chris: And if the brief names a coordinator and a set of specialists, that is the delegation shape — context passing and allowed tools are in scope.

Koko: Precisely. Second extraction: what must never happen, or must always happen. Scan for the absolutes. Approval before a refund. A disclosure before publish. No writes to production. Each of those is a deterministic-enforcement item. Think of them like a fuse panel — the rule either holds or the circuit breaks, no negotiation.

Chris: And the cue there is the phrasing itself. If the brief bothers to state something in absolute terms, it is not scene-setting.

Koko: That is the exact read. It is a contract, not atmosphere. You have already identified the move before you see the options.

Chris: Third extraction: where the volume and the latency are. The brief will mention long logs, huge payloads, hundreds of files — that is context management in scope. Or it separates a fast interactive path from a large overnight backlog.

Koko: And when it does that second thing, it has handed you the discriminator on a plate: someone is waiting on one of those paths and nobody is waiting on the other. That is the synchronous-versus-batch decision, and the brief just made it for you. The trap is treating both paths as if they share the same constraints.

Chris: Fourth extraction: what is already broken. The prototype confessions. Raw payloads returned, endpoints mirrored one-to-one, agents guessing when a lookup comes back empty, failures surfacing as raw text.

Koko: Each confession is an item. And here is where the trap lives — the trap is fixing the specific thing the brief described. The brief says the agent guesses on empty lookups, and an option says add a fallback message for empty lookups, and that sounds like a direct repair.

Chris: But the keyed answer is the fix for the class that confession belongs to — graceful degradation, structured uncertainty handling — not the surface symptom.

Koko: Exactly. You are not patching; you are recognising the pattern.

Chris: Two closing habits: re-read the brief between items in the same case, because a detail that looked decorative on the first pass can be load-bearing for item nine. The same brief is answering fifteen questions.

Koko: And the other one — notice what the brief does not say. If compliance is never mentioned, an option that invents a regulatory requirement is adding a constraint nobody gave you. The trap there is that the option sounds responsible and thorough, so it feels safe. But inventing constraints is as wrong as ignoring them. The brief is the contract. If it is not in the contract, it is not in scope.

Chris: Alright, let's run them. Same format we practised — I give you the cue, you give me the move. One clause, fast. Always, never, must, guaranteed, compliance, one hundred percent.

Koko: Enforce — do not instruct.

Chris: Prevent, block, stop it happening.

Koko: Intercept before the call.

Chris: Normalise, reconcile, inconsistent formats.

Koko: Transform after — that is a post-call hook.

Chris: And the trap on that one — too late by one step.

Koko: That is post-tool-use trying to do prevention's job. Different place in the chain entirely. Keep going.

Chris: Did not know, missing context, summarise the above.

Koko: Pass findings explicitly.

Chris: Too slow across independent subtasks.

Koko: Multiple delegation calls in one response.

Chris: Restrict what it can do.

Koko: Agent definition — not the parent.

Chris: Spawned but nothing happened.

Koko: The delegation tool is not in allowed tools — the spawn was never auto-approved.

Chris: Keeps going, never finishes.

Koko: Read the stop reason and bound the loop.

Chris: Stopped early — same field?

Koko: Same fix.

Chris: The reply looked final.

Koko: The reply is not the signal — the stop reason is.

Chris: Where is this called.

Koko: Search contents.

Chris: Every file of this type.

Koko: Match paths.

Chris: Change three lines.

Koko: Targeted edit.

Chris: Anchor is not unique.

Koko: Extend it or replace across matches.

Chris: Replace the whole file.

Koko: Write.

Chris: Run the tests.

Koko: Bash.

Chris: Works for me, not for the new joiner.

Koko: Project level — not user.

Chris: Applies across fifty directories.

Koko: Path rules.

Chris: Which files actually loaded.

Koko: The memory diagnostic — it reports, it does not trigger.

Chris: Adding another copy higher up.

Koko: That hides the placement bug — do not do it.

Chris: Multi-file, several designs.

Koko: Plan first.

Chris: Team-wide command, then personal command.

Koko: Project scope, then user scope.

Chris: Verbose exploratory skill.

Koko: Fork the context, return the summary.

Chris: Needs a parameter at invocation.

Koko: Argument hint.

Chris: Format keeps varying.

Koko: Demonstrate with examples.

Chris: Machine-readable output.

Koko: A schema the platform enforces.

Chris: Schema-valid but wrong.

Koko: Schema removes syntax errors only — semantics are still on you.

Chris: Validation failed.

Koko: Retry with the specific error.

Chris: Retried and failed identically.

Koko: It was never retryable — escalate instead.

Chris: Empty result set.

Koko: That is a result, not an error.

Chris: Failure reported as success text.

Koko: Use the error flag.

Chris: Agent picked the wrong tool.

Koko: Differentiate the descriptions.

Chris: Fixed it in the system prompt.

Koko: That is a bandage on a design flaw.

Chris: Does not fit in the window.

Koko: Explore directed, summarise forward.

Chris: And the option sitting next to that one will say: read everything so nothing is missed.

Koko: That is how you exhaust the window. Completely different outcome.

Chris: Contradicted itself later.

Koko: Context loss — re-ground it.

Chris: How confident is it.

Koko: Its own confidence is not calibrated — do not treat it as a signal.

Chris: Where did that claim come from.

Koko: Provenance per claim.

Chris: Cheaper, overnight, nobody waiting.

Koko: Batch.

Chris: Someone is waiting.

Koko: Synchronous.

Chris: Results usually arrive fast.

Koko: No latency guarantee — plan the worst case.

Chris: Multi-turn tool calling.

Koko: Stays synchronous.

Chris: Reduce spend.

Koko: Smaller model on narrow steps, cache what repeats.

Chris: Resume the investigation.

Koko: Resume by name.

Chris: Compare two approaches.

Koko: Fork from the baseline.

Chris: Rate limited, raw failures.

Koko: Structured error, backoff, escalate.

Chris: Now the case-scan set. Each user keeps their own authorisation.

Koko: Per-user scoping — never one shared credential.

Chris: A coordinator and specialists.

Koko: Delegation, context passing, allowed tools — all three.

Chris: The brief states a rule in absolute terms.

Koko: That is an enforcement item — not colour.

Chris: Long logs, huge payloads, a repo nobody can hold.

Koko: Context management.

Chris: A fast path and an overnight backlog in the same brief.

Koko: Synchronous versus batch — and the brief just handed you the discriminator.

Chris: The prototype returns raw payloads or mirrors endpoints one-to-one.

Koko: That confession is an item. The exam will ask what to do about it.

Chris: The brief never mentions compliance.

Koko: An option that invents one is adding a constraint nobody gave you — eliminate it.

Chris: A detail that looked like colour.

Koko: Re-read it. The same brief answers fifteen questions. Nothing in there is decoration.

Chris: That is the full run. And if I had to reduce the whole two parts to one sentence to walk in holding —

Koko: The move is almost always the mechanism, not the wording. That is the sentence. Carry it in.

Chris: Everything from part one — the domains, the scoring, the decision rules — it all pointed here.

Koko: It did. And you have done the work. Run these cues back to yourself one more time on the way in — just this list, out loud if you can. The flashcards and the practice quiz are at KokoAI Academy on koko knows dot A I. You are ready. Go show them the mechanism.