When the stem says "root cause," "most effective," "directly addresses," or "best" — don't ask "what would help?" (several options help). Ask:
"What causes the symptom, and which option removes that cause?"
Exam tell: options that add structure or process — more few-shot examples, tiers, confidence scores, a bundled tool, a routing layer, self-critique — usually treat the symptom. When two options both "help," the one that eliminates the cause wins.
| Tempting patch (you picked) | Why it's only a patch | Root-cause move (correct) |
|---|---|---|
| Add few-shot examples of bad comments | Pattern-matches; the vague instruction stays vague, won't generalize | State explicit criteria: flag only when claimed behavior contradicts actual behavior |
| Categorize findings into tiers | Reorganizes the queue; devs still click into each to read reasoning | Surface reasoning + confidence inline — kills the investigation-time bottleneck |
| Ask Claude to self-critique its output | Same context ⇒ same confirmation bias; it already rationalized the call | An independent second instance, blind to the generator's reasoning |
Build composite tools (get_customer_with_orders) | New maintenance; masks that Claude already supports multi-tool turns | Prompt Claude to batch related tool calls in one turn |
| Switch parallel agents to sequential to dedupe | Throws away parallelism to fix an upstream boundary problem | Coordinator partitions the space up front, then runs parallel |
| Add verification gates between sequential steps | Reinforces serial processing & redundant fetches — the actual problem | Decompose into concerns, investigate in parallel with shared context |
| Strengthen the system prompt ("verification is mandatory") | Probabilistic — non-zero failure rate; 12% already skip it | Programmatic prerequisite / hook gate (see §2) |
Your own CLAUDE.md: "block process_refund until get_customer returns a
verified ID." On the mock you still chose the system-prompt option. Lock this:
Financial · irreversible · "must always" · regulatory → a deterministic gate (hook / programmatic prerequisite), never a prompt instruction.
Why: prompt guidance has a non-zero failure rate. When the scenario hands you a number — "12% skip verification, causing wrong refunds" — that's the proof the prompt is insufficient. A gate makes the bad path impossible, not just discouraged.
Distinguish from §1: the patch-vs-root table is about quality/efficiency; this is about guaranteed compliance. Both reject the prompt-tweak distractor, for different reasons.
The Message Batches API is async, fire-and-forget: you submit, it processes (up to 24h), you collect. There's no way to intercept a tool call mid-request, run the tool, and hand results back for Claude to continue. So it breaks any iterative tool-calling loop.
Tell: the distractor names latency ("24h is too slow, but it could otherwise function"). The "could otherwise function" clause is false — the architectural limit (no mid-request tools) applies regardless of speed. Also: no multi-turn tool calls within one request.
After all system data is fetched, escalate only when resolving needs human judgment a rule can't supply — a true policy gap (e.g. policy covers own-site price drops but is silent on competitor matching).
Not triggers: speculation ("they might change their mind"), two issues in one message (handle both), or "awkward to deliver" contradictory evidence (present it). The agent must not invent policy — but it also must not defer a clearly answerable request.
CLAUDE.md.