Domain cheat sheets.

TS 1.1Agentic Loops

Lifecycle: send → inspect stop_reason → if tool_use, execute tools, append tool_result blocks as role: "user", loop → if end_turn, done.

stop_reason is the ONLY authoritative termination signal.

Tool result shape

{"role": "user", "content": [
  {"type": "tool_result", "tool_use_id": "<id>", "content": "...", "is_error": False}
]}

Parallel tool_uses → one tool_result per id, all in one user turn.

TS 1.2Multi-Agent Orchestration

Topology: hub-and-spoke only. Coordinator at centre; subagents are spokes; ALL communication routes through the coordinator. Subagents NEVER talk to each other.

The isolation principle (most-misunderstood concept)

• Subagents do NOT inherit coordinator history
• Subagents do NOT share memory across invocations
• Every byte they need must be in their prompt

Coordinator's 7 responsibilities: decompose → select → partition scope → pass context → aggregate → iteratively refine → route for observability.

Failure-tracing rules

TS 1.3Subagent Invocation & Context Passing

Task tool is the only mechanism to spawn subagents. allowedTools must include "Task" or the coordinator physically cannot delegate.

AgentDefinition fields: description (used for selection — write like a function docstring), prompt, tools (subset of coordinator's), optionally model.

Context-passing rules

• Pass complete findings, not pointers
• Pass structured metadata (claim + source_url + snippet), not collapsed prose
• Write goal-oriented coordinator prompts, NOT procedural step-by-step

Parallel spawning: emit multiple Task tool_uses in a single coordinator response → executes concurrently. Sequential = separate turns = triple latency. Only safe when subagents are independent.

fork_session: independent branches from a shared expensive baseline. Use for "explore N alternatives from the same analysis."

Decision

• Many isolated subagents, no shared baseline → parallel Task
• Branches that share an expensive computed state → fork_session

TS 1.4Workflow Enforcement & Handoff

Enforcement spectrum

PROBABILISTIC ──────────────────────────► DETERMINISTIC
prompt rules → few-shot → routing → hooks / prerequisite gates
~95-99%        ~98%      ~98%       100%

The decision rule (memorise verbatim): If a single failure causes financial loss, security breach, regulatory violation, or safety harm → programmatic enforcement (hooks).

If a single failure causes only a bad-but-recoverable UX → prompts.

Canonical exam scenarios → all answer = hooks: refund verification, trade limits, compliance checks, manager approvals, age/permission gates, audit logging.

Multi-concern requests: decompose → investigate in parallel with shared context → synthesise unified resolution.

Human handoff payload (self-contained, no transcript expected)

• Customer ID
• Conversation summary (2–3 sentences)
• Root cause analysis ← exam frequently tests this as missing
• Action taken so far
• Recommended action (incl. refund amount) ← exam frequently tests this as missing
• Compliance / urgency flags

TS 1.5Agent SDK Hooks

Keyword triggers

• "Prior state" / "pre-condition" / "before X happens" → PreToolUse
• "Heterogeneous formats" / "normalise" / "redact" / "model is confused by varying outputs" → PostToolUse

Hooks vs subagents

• Rule that must be enforced → hook
• Capability that needs different reasoning / prompt / tools → subagent

Hooks don't rank tools. Hooks gate, block, or transform. Use prompts + tool descriptions for "prefer this tool over that one."

TS 1.6Task Decomposition Strategies

Discriminator (Pattern 2 vs Pattern 3): typed roles → dynamic decomposition; uniform clones → orchestrator–worker.

Evaluator–optimiser fails when: the evaluator cannot reliably distinguish good from bad. Subjective criteria → loop spins.

TS 1.7Error Handling, Retries, Observability

Three error categories

Idempotency: generate a UUID / hash of {operation + customer + amount} on the first attempt, pass it on every retry, server-side dedup. Without this, a transient retry can double-charge.

Paired-fix pattern (exam favourite): when both retry policy is broken AND duplication occurs, you need both error classification and idempotency keys. Either alone is insufficient.

Errors must reach the model when the model can do something useful. Silent harness error-swallowing (returning empty string for failed tool calls) makes the model produce confident wrong answers.

Observability minimum bar

• Trace ID per run, span IDs per loop iteration and tool call
• Structured logging of stop_reason, tool calls, hook decisions, token usage
• Per-subagent cost & latency telemetry (multi-agent costs compound)
• Replay capability via stored history

Reliability patterns

• Circuit breaker — N failures in window → stop calling for cooldown
• Fallback agent / tool — degraded answer > no answer
• Cost / token budgets — enforced at harness, not by prompt
• Per-tool timeouts — no tool blocks the loop indefinitely

CribsheetDistractor Recognition

TS 2.1Tool Interface Design

The core principle: tool descriptions ARE the routing mechanism. The model has nothing else when choosing between similar tools.

A production-grade tool description contains 5 components

1. Primary purpose — one sentence
2. Input contract — formats, types, constraints
3. Example queries it handles well — concrete strings
4. Edge cases and limitations — what it won't do
5. Explicit boundaries vs. similar tools — "Use this for X. For Y, use other_tool." ← the one most teams skip

The misrouting fix-ranking (memorise verbatim)

The exam's preferred answer is ALWAYS "expand descriptions" as the first step for a misrouting scenario.

Tool splitting — the other side

Code smell: a tool description containing "or" between behaviours, or "depending on" between conditions. Example:

"Processes refunds, partial refunds, store credits, or exchanges depending on policy and customer status."

This is unsplittable at runtime. The model can't route to it reliably. Split into purpose-specific tools with tight contracts:

• issue_full_refund(order_id, reason)
• issue_partial_refund(order_id, amount, reason)
• issue_store_credit(customer_id, amount, reason)
• process_exchange(order_id, replacement_sku, reason)

Renaming a generic tool does NOT fix this. Splitting does.

TS 2.2Structured Error Responses

The MCP isError flag is the agent's primary recovery signal. Without structured error metadata, agents guess — and guess badly (retry things that won't succeed, escalate things that needed a moment).

The four error categories (memorise the table)

Structured error payload shape

{
  "isError": true,
  "errorCategory": "business",
  "isRetryable": false,
  "description": "Refund of £450 exceeds £200 self-service limit. Customer must speak with a supervisor."
}

The description for business errors should be customer-friendly — the agent will often surface it to the user.

THE most-tested distinction in 2.2

Retryability subtlety

• Transient isRetryable: true = retry with the same input
• Validation isRetryable: true = retry only after correcting the input

Error propagation in multi-agent systems

Subagents handle local recovery. Only propagate what they cannot resolve.

• Transient error in a subagent → retry locally, fall back to alternative source, then escalate
• When propagating, include: what was attempted, partial results if any, recommended action
• Coordinator should evaluate partial results from successful subagents rather than aborting the whole task on a single subagent failure

Retry budget: even retryable errors have limits. A well-designed tool may include retryAfter and maxRetries hints. "Agent retried 50 times" in a setup = missing retry budget.

TS 2.3Tool Distribution and tool_choice

Tool overload

• 4–5 tools per agent is the production sweet spot.
• Reliability degrades sharply past 7–10 tools — softmax over descriptions thins probability margins
• Scope tools to roles: a synthesis agent should NOT have web_search; a web search agent should NOT have document analysis tools

The tool_choice values (know each verbatim)

Force-a-specific-first-step pattern (exam favourite)

Scenario: "Every customer message must first extract intent and entities before routing. Currently done via system prompt instruction; ~15% of messages skip the extraction."

Correct fix: set tool_choice: {"type": "tool", "name": "extract_intent"} on the first turn. Switch to "auto" for subsequent turns. The model literally cannot output anything other than the forced tool call. 15% miss rate → 0%.

Rule: when the requirement is "the model MUST do X first", reach for tool_choice: {"type": "tool", "name": "X"}, not a prompt instruction. Prompts request; tool_choice requires.

THE Q9-style pattern — scoped cross-role tools

Setup: synthesis agent frequently returns control to coordinator for one-line fact verifications. 85% are simple lookups, 15% need multi-source cross-referencing. Round-trip latency dominates.

Correct fix: add a scoped, constrained verify_fact(claim, max_sources=3) tool to the synthesis agent. Tool description explicitly states that complex multi-source verifications must be routed back to the coordinator.

Pattern in one sentence: for high-frequency simple operations, give the consuming agent a constrained version of the capability; complex cases still escalate to the owner.

Replacing generic tools with constrained alternatives

• fetch_url(url) → load_document(document_url) — validates allowed domains, document content-types, strips scripts
• run_sql(query) → query_orders(filters) — single-table, parameterised
• send_email(...) → send_customer_notification(template_id, ...) — templated, restricted recipients

Same capability, narrower surface, reduced blast radius.

TS 2.4MCP Server Integration

Scoping hierarchy

Tool discovery happens at connection time — all tools from all configured servers are made available simultaneously. Too many configured servers re-creates the tool-overload problem at a different layer.

Credential handling — ${VAR} expansion (most-tested 2.4 pattern)

Wrong:

{ "env": { "JIRA_API_TOKEN": "ATATT3xFf_actual_token_here" } }

Right:

{ "env": { "JIRA_API_TOKEN": "${JIRA_API_TOKEN}" } }

Rule: "shared config, personal credentials". The .mcp.json structure stays committed and shared. Secrets live in each developer's local environment.

Don't fix a credential leak by relocating the file. A team integration belongs in .mcp.json so new teammates have it. The fix is parameterisation, not relocation. Also: rotate any leaked token — git history is forever.

MCP resources (content, not actions)

• Tools = actions the agent can take
• Resources = content the agent can read (catalogues, schemas, summaries)

Example: jira://projects/INGEST/summary, db://schemas/orders, github://repos/acme/api/issues/labels.

Exam framing: "Agent makes many exploratory tool calls at conversation start to discover available data" → expose resources that catalogue what's available. The agent reads the catalogue once, then queries precisely.

Build vs. use decision

Use a community MCP server when:

• Standard third-party system (Jira, GitHub, Slack, Notion, Postgres)
• Maintained server exists
• Usage pattern fits

Build custom only when:

• Team-specific internal system
• Community server fundamentally cannot support the workflow
• Compliance/security policy prohibits the community server

Exam preference: "Configuration over construction" and "fork over fresh build". When a community server is 90% of what you need (e.g., just want different return fields), post-process its responses or fork it — don't write from scratch.

TS 2.5Built-in Tools

Grep vs Glob — THE most-tested distinction

Grep use cases: function callers, error messages, import statements, TODO comments, identifier occurrences.
Glob use cases: all test files (**/*.test.tsx), all configs (**/*.config.{js,ts,json}), files by extension.

Read / Write / Edit

Edit-failure escalation ladder (memorise)

1. Expand the old_string anchor with surrounding context until unique — the FIRST move
2. If anchor cannot be made unique (truly identical surroundings) → Read + Write the full file
3. If intent was actually "change every occurrence" → use replace_all: true

Distractors to reject: "use sed" (wrong tool category), "delete and recreate" (destructive).

Incremental codebase understanding

Correct pattern:

1. Grep for entry points (function names, error strings, identifiers)
2. Read only the entry point file
3. Grep for the identifiers found in that file across the codebase
4. Read only the implementations that matter

Wrapper-module tracing: for codebases with re-exports (index.ts does export { formatDate } from './date'), Grep finds both definitions and re-exports. Identify which references are definitions vs. re-exports vs. call sites, then trace the chain.

Grep → Glob sequencing pattern (exam favourite)

Task: "Find all callers of legacyAuth, then find the test files for those callers."

Correct sequence:

1. Grep legacyAuth( → returns caller files (userService.ts, paymentService.ts, …)
2. Derive expected test filenames from caller names
3. Glob **/{userService,paymentService}.test.{ts,tsx} → returns test files

Rule: Grep first when you're discovering content; Glob second to narrow paths around the results. Mirror form: known file set → check contents goes Glob → Grep. The order depends on what is the seed vs. the filter.

CribsheetDistractor Recognition

Carry-forwardLayer-Awareness Rule

Many wrong answers come from reaching for the right idea at the wrong layer:

When you feel the pull toward a fix, ask which layer the question is testing. The exam is at the API + MCP + tool-design layers. Hooks are usually the wrong answer in Domain 2.

TS 3.1CLAUDE.md Hierarchy

The three levels — memorise the paths verbatim

Directory CLAUDE.md scopes downward and local, never upward. A src/backend/CLAUDE.md does NOT affect work in src/.

Modular organisation (two equally valid patterns)

1. @import syntax inside CLAUDE.md — reference external files, import per-package standards
2. .claude/rules/ directory — topic-specific files (testing.md, api-conventions.md, deployment.md) as an alternative to one massive CLAUDE.md

/memory command — the diagnostic tool

Lists which memory files are currently loaded. Use to confirm the diagnosis, not to fix the bug. If a file you expected isn't there, you've found your bug — but the fix is to put the file in the right location, not to run /memory harder.

TS 3.2Custom Slash Commands and Skills

Directory structure — mirrors CLAUDE.md hierarchy

Each skill is its own directory containing a SKILL.md file. The directory name becomes the skill name.

Skill frontmatter — the three options to memorise

---
name: brainstorm
description: Explore design alternatives for a feature
context: fork
allowed-tools: [Read, Grep]
argument-hint: <feature-name>
---

THE critical distinction — Skills vs CLAUDE.md

Personal customisation pattern

Scenario: Team has a /review skill; one developer wants a stricter variant for personal use.

• Wrong: edit the project skill (affects teammates).
• Right: create ~/.claude/skills/review-strict/SKILL.md — different name, personal location, no impact on others.

Two independent axes (don't conflate)

1. Who needs it? → location (.claude/ vs ~/.claude/)
2. Is the output noisy? → context: fork or not

A skill can be project-scoped AND forked. Personal AND unforked. These are orthogonal.

TS 3.3Path-Specific Rules

Mechanism: files in .claude/rules/ with YAML frontmatter declaring a glob:

---
paths: ["**/*.test.tsx", "**/*.test.ts"]
---

All test files must use describe/it blocks, not test().
Mock external services using shared fixtures in tests/fixtures/.

Loads only when Claude Code is about to work on a file matching the glob. Not loaded for non-matching files.

Why this beats directory-level CLAUDE.md (the comparison the exam tests directly)

Glob patterns match files scattered anywhere. **/*.test.tsx catches every test file regardless of directory. A directory-level CLAUDE.md cannot do this — you'd need N copies that drift.

Token efficiency angle (commonly tested)

• Path-scoped rules load only when editing matching files → reduces irrelevant context and token usage
• Project-level CLAUDE.md would burn tokens on every interaction
• Directory-level CLAUDE.md would require duplicates

When to reach for which mechanism (the mental decision table)

The signature phrase to recognise: "pattern of files spread across the codebase" → path-specific rules.

Examples that all fit the pattern: **/*.test.*, **/migrations/**/*, **/*.tf, **/api/handlers/**/*.ts.

TS 3.4Plan Mode vs Direct Execution

This is a judgement task statement. The exam hands you a task description; you classify.

Plan mode when

• Large-scale changes (library migration affecting 45+ files, monolith restructure)
• Multiple valid approaches exist (need to evaluate before committing)
• Architectural decisions required (service boundaries, abstractions)
• Multi-file modifications where changes interact
• Unfamiliar codebase needs exploration before design

Direct execution when

• Well-understood, narrow scope (single-file bug fix, clear stack trace)
• Mechanical changes (add a validation conditional, rename a variable)
• The correct approach is already known

The dividing line: Are there decisions still to make, or just a known thing to do? Decisions → plan mode. Known thing → direct execution.

The Explore subagent

Exam phrasing: "main conversation filling up with grep output and file listings" → Explore subagent.

Same principle as context: fork for skills — keep noise out of the main conversation. Different mechanism, same goal.

The combination pattern (commonly tested)

You don't have to pick one mode for the whole task. Common workflow:

1. Enter plan mode
2. Explore the codebase, evaluate approaches
3. Produce a concrete plan
4. Exit plan mode
5. Implement the planned steps directly

If a question describes "exploring, then implementing the chosen approach" — that's the hybrid, not a single-mode choice.

Common task classifications

TS 3.5Iterative Refinement

Technique hierarchy — what to reach for when prose isn't working:

1. Concrete input/output examples (highest leverage)

When prose descriptions get interpreted inconsistently, show 2–3 concrete examples:

Input:  user_name → Output: userName
Input:  api_key   → Output: apiKey
Input:  http_url  → Output: httpUrl

The model generalises from examples more reliably than from descriptions. Three examples eliminate ambiguity that prose admits.

Exam phrasing: "Claude Code interprets the instruction differently each iteration" → concrete input/output examples.

2. Test-driven iteration

Write tests first. Share failures. Claude iterates against a machine-checkable specification rather than your prose. Strongest when behaviour is well-defined but implementation is open.

3. Interview pattern

Have Claude ask questions first before implementing. Surfaces considerations you would miss in unfamiliar domains.

Exam phrasing: "developer working in unfamiliar domain, wants to avoid missing edge cases" → interview pattern.

Batch vs sequence feedback

THE headline rule: when prose fails repeatedly, switch modalities, don't iterate on the prose. Rewording prose tends to produce different misinterpretations, not fewer. Examples constrain the output shape directly.

TS 3.6CI/CD Integration

This is the most memorisation-heavy task statement in the domain. Drill the flags.

The -p flag (print mode) — single most-tested CI detail

• claude -p "<prompt>" runs in non-interactive mode
• Without -p, the CI job hangs waiting for interactive input
• Symptom in exam questions: "the CI pipeline hangs" / "Claude is waiting for input" / "printed banner, then nothing" → answer is -p

Structured CI output (for automation)

Exam phrasing: "automated system needs to post findings as inline PR comments" → both flags together.

Session context isolation — the counter-intuitive one

The same Claude session that generated code is LESS effective at reviewing its own changes.

It retains the reasoning context that produced the code → less likely to question its own decisions (motivated reasoning).

The exam-correct pattern: use an independent review instance — a fresh Claude Code session with no prior context for the review step.

Incremental review context

When a PR gets new commits and you re-run the review:

• Include prior review findings in context
• Instruct Claude to report ONLY new or still-unaddressed issues

Without this: developers get duplicate comments on every push → lose trust → start ignoring the bot.

Exam framing: "developers ignoring the bot's comments" / "comment fatigue" / "duplicate findings on every push" → incremental review context, NOT "remove the bot".

CLAUDE.md for CI

CI-invoked Claude Code reads the same .claude/CLAUDE.md. For test generation especially, document:

• Testing standards (frameworks, patterns)
• What makes a valuable test in your codebase
• Available fixtures, mocks, helpers

Without this: CI-generated tests are low-value boilerplate (testing getters, trivial assertions). With it: tests target meaningful behaviour.

Exam phrasing: "CI generates low-quality tests" → strengthen .claude/CLAUDE.md with testing standards.

Test deduplication (commonly missed)

When using CI for test generation, provide existing test files in context alongside the source file. Without them, Claude proposes scenarios already covered — duplicating tests already in the suite.

Two separate context problems in test generation

These look similar but have different solutions. The exam may present both options — pick based on which problem is described.

TS 3.6CI/CD Quick Reference — The 5 Failure Patterns

These are the five patterns that most commonly produce wrong answers on CI/CD questions. Memorise the symptom → fix mapping:

What blocks CI most on the exam: the -p flag. If you see "hangs" or "waiting for input" — that is the answer, always.

The independent-session rule appears twice

• Domain 3 (CI/CD): use a fresh Claude Code session for review, not the one that generated the code
• Domain 4 (multi-instance review): use an independent Claude instance to review generated code without the generator's reasoning context

Same principle, two domains. On a CI/CD question it maps to -p + separate session. On a prompt-engineering question it maps to multi-instance architecture.

CribsheetDistractor Recognition

Decision treeConfiguration-Layer Decision Tree

When a question describes a need, ask in order:

1. Does it need to happen every interaction? → Project-level CLAUDE.md
2. Does it apply to a pattern of files scattered across the codebase? → Path-specific rule in .claude/rules/ with paths: glob
3. Does it apply only to one specific subdirectory? → Directory-level CLAUDE.md
4. Is it a workflow invoked on demand? → Skill in .claude/skills/ (or command in .claude/commands/)
5. Is it personal-only? → Same answer as 1–4 but in ~/.claude/ instead of .claude/
6. Is it for the CI to consume? → .claude/CLAUDE.md (still the project-level file — CI reads the same hierarchy)

If the answer to all of 1–4 is "no," you probably don't need configuration — you need a one-off prompt.

Carry-forwardLayer-Awareness Rule

Many wrong answers come from reaching for the right idea at the wrong layer:

When you feel the pull toward a fix, ask which layer the question is testing. A CI hang is a runtime-flag question (-p), not a CLAUDE.md question. A divergent-behaviour bug is a path-prefix question (user vs project), not a /memory question. Don't cross layers.

TS 4.1Explicit Criteria

The core principle: Specific categorical criteria obliterate vague confidence-based instructions.

Structure to memorise: What to flag. What to report. What to skip. Three categories, no adjectives about confidence.

The false-positive trust problem — heavily tested

When one category has a high false-positive rate, developers stop trusting all categories, including the accurate ones.

The counterintuitive fix: temporarily disable the noisy category entirely while improving its prompt. Don't tighten in place — pull it from output, restore trust in what remains, then re-enable.

Severity calibration — the prose-vs-code distinction

Prose definitions of severity drift across runs. Anchor severity levels with actual code examples for each level.

Critical: SQL injection from unvalidated input
  Example: db.query("SELECT * FROM users WHERE id=" + req.params.id)

Medium: Missing error handling on non-critical path
  Example: fs.readFile(path, cb) where cb ignores err parameter

TS 4.2Few-Shot Prompting

The headline rule: Few-shot examples are the most effective technique for consistency. Not more instructions. Not confidence thresholds. Not temperature changes. Examples.

Three deployment triggers — memorise verbatim

1. Detailed instructions alone produce inconsistent formatting
2. Model makes inconsistent judgement calls on ambiguous cases
3. Extraction tasks produce empty/null fields for information that exists in the document

Construction rules

The hallucination reduction effect — exam favourite

Documents vary in structure: inline citations vs bibliographies, narrative prose vs structured tables. Few-shot examples covering varied structures dramatically reduce hallucination because the model learns the shape of valid extractions across formats, rather than inventing data to fit the schema.

Signature phrase to recognise: "inconsistent output across runs despite detailed instructions" → few-shot examples.

TS 4.3Structured Output with tool_use

The reliability hierarchy

That is the only thing tool_use guarantees. Syntactic validity. Nothing else.

What tool_use does NOT prevent — the three persistent failure modes

1. Semantic errors — line items don't sum to stated total. Schema doesn't check arithmetic.
2. Field placement errors — right value, wrong field. Schema validates types, not meaning.
3. Fabrication — model invents values for required fields when source lacks the information.

tool_choice — three modes the exam tests

Mental shortcut: named-tool forces a specific tool; "any" forces some tool from the menu.

Schema design — the anti-fabrication toolkit

TS 4.4Validation-Retry Loops

The mechanism — three things sent back on validation failure

1. The original document
2. The failed extraction output
3. The specific validation error message

The model uses the error to self-correct. Dramatically more effective than naive retry, because the model now has signal about what specifically went wrong.

The retry effectiveness boundary — most-tested concept in 4.4

Memorise as a sentence: Retry handles output errors. Schema design handles source gaps.

detected_pattern fields — systematic improvement

Add a detected_pattern field to each structured finding (e.g., "unvalidated_user_input_in_sql_concatenation").

Exam framing: "how do you improve a code review bot's accuracy over time" → systematic data path via detected_pattern, not "iterate on the prompt".

Self-correction flows — two patterns

1. Calculated vs stated totals. Extract stated_total AND calculated_total (sum the line items yourself). Disagreement flags OCR errors, fraud, or model arithmetic mistakes — three things schemas can't catch.
2. conflict_detected boolean. When source data is internally inconsistent (header date ≠ footer date), surface the conflict rather than silently picking one.

Shared principle: extract redundantly and let inconsistencies bubble up.

TS 4.5Batch Processing

CI/CD note: Scenario 5 (Claude Code for CI) is a primary domain for Domain 4. The batch API and multi-pass review questions in this domain appear in CI/CD framing. The rules below apply directly.

Message Batches API — five facts to memorise

1. 50% cost savings vs synchronous
2. Up to 24-hour processing window — no faster, no slower-bounded
3. No guaranteed latency SLA — could return in 10 minutes or 23 hours
4. Does NOT support multi-turn tool calling within a single request — single-shot completions only
5. Uses custom_id for correlating request/response pairs

The fourth point is the sleeper trap. Agentic workflows (model calls tool, sees result, calls another tool) cannot run on batch.

The matching rule — central exam test

Blocking examples: pre-merge CI checks, IDE inline suggestions, customer-facing chat.
Latency-tolerant examples: overnight test generation, weekly compliance audits, monthly competitive intelligence.

Special case — multi-turn tool calls: even if the workflow looks latency-tolerant, multi-turn agentic loops cannot run on batch. Must be synchronous.

Batch failure handling

TS 4.6Multi-Instance Review

The self-review limitation — foundational principle: A model reviewing its own output in the same session retains the reasoning context that produced the output. It is biased toward its prior conclusions and less likely to question its own decisions.

The fix: spawn an independent instance — fresh session, no prior context — for the review step. The cold instance catches subtle issues the original misses.

This is the same principle as the CI/CD session-isolation rule in Domain 3.6 — different scenario, same architecture.

Multi-pass architecture for codebase-wide tasks

Why single-pass fails on large repos

• Attention dilution — early files get more attention than late files (or vice versa) unpredictably
• Contradictory findings — model loses track of conclusions on file 3 by the time it reaches file 47
• Misses cross-file issues — cross-file reasoning competes with per-file detail

Confidence-based routing

CribsheetDistractor Recognition

Decision treeMechanism-to-Failure Decision Tree

When a question describes a failure, ask in order:

1. Inconsistent judgement across runs / inconsistent formatting? → Few-shot examples (2–4, with reasoning)
2. Malformed JSON? → tool_use with JSON schema
3. Required field fabricated when source lacks data? → Nullable field in schema + prompt instruction to return null
4. Ambiguous categorisation? → "unclear" enum value or "other" + freeform detail
5. Format mismatch in output (e.g., date format wrong)? → Validation-retry with error feedback
6. Line items don't sum to total / semantic inconsistency? → Self-correction (extract both, compare, flag)
7. Internally inconsistent source data? → conflict_detected boolean, surface ambiguity
8. Blocking workflow (someone waiting)? → Synchronous API
9. Latency-tolerant single-shot workflow? → Batch API
10. Multi-turn agentic workflow? → Synchronous, always (batch doesn't support it)
11. Inconsistent depth across files in a large repo? → Per-file pass + cross-file integration pass
12. Need a second opinion on Claude's work? → Independent instance, fresh session
13. Want to improve a review bot over time? → detected_pattern field + analysis of dismissal patterns
14. Bot output dismissed by developers because of noisy category? → Disable that category; iterate; re-enable

Carry-forwardLayer-Awareness Rule

Many wrong answers come from reaching for the right idea at the wrong layer:

When you feel the pull toward a fix, ask which layer the question is testing. A fabrication problem is a schema-design question (nullable), not a prompt-content question ("don't fabricate"). A batch-failure question is a custom_id question, not a retry question. A self-review limitation is a multi-instance question, not a prompt-content question. Don't cross layers.

Cross-domainCI/CD Cross-Domain Map

CI/CD questions span both Domain 3 and Domain 4. When a question is framed as "Claude Code for CI/CD," the answer might live in either domain. Use this map to route quickly:

The one rule that appears in both domains in different forms: An agent/session that produced output should not review that same output. Use an independent instance. In Domain 3 it's framed as "CI code review session." In Domain 4 it's framed as "self-review limitation." Same answer.

TS 5.1Context Preservation

The headline rule: Summarisation is lossy compression that disproportionately destroys high-value tokens.

What summarisation compresses away first

The fix — persistent "case facts" block

Extract transactional facts into a structured block. Inject verbatim into every prompt. Summarisation never touches it. Conversation history above and below can be compressed; the facts block is sacred.

<case_facts>
- Customer ID: 4471
- Order: #8891, placed 2026-03-03
- Refund requested: $247.83
- Customer deadline: by Friday 2026-05-22
- Channel preference: email
</case_facts>

Lost in the middle — structural attention bias

Transformer attention is empirically biased toward the beginning and end of long inputs. Information buried in the middle is measurably less likely to be retrieved correctly. This is not fixable with a better model — it is structural.

Tool result trimming — pre-context filtering

A 40-field order lookup when 5 fields are needed = 35 fields of noise. Trim at the integration layer, before the result hits the context window. Untrimmed results accumulate across turns — turn 8 still carries the noise from turns 1–7.

Define a per-tool response shape with only the fields downstream reasoning needs. Treat tool responses like API contracts, not data dumps.

Full history requirements — stateless API

Claude API calls are stateless. Every request must include the complete conversation history. Drop earlier messages → break coherence. Use prompt caching on the stable prefix (system prompt + tools + early conversation) to make this economical.

Upstream agent optimisation — structured output across agent boundaries

In multi-agent systems, the cheapest place to fix downstream context bloat is upstream. Modify subagents to return:

• Key facts
• Citations
• Relevance scores
• Confidence values

Not verbose prose, not reasoning chains, not narrative. Reasoning happens inside the subagent's context; only distilled conclusions cross the boundary.

TS 5.2Escalation and Ambiguity Resolution

The headline rule: Three triggers warrant escalation. Two superficially plausible triggers do not.

Three valid escalation triggers

Two unreliable triggers — wrong answers

The frustration nuance — heavily tested

Memorise the distinction: Explicit human request = immediate escalation. Frustration alone = offer help first.

Ambiguous customer matching

Search returns multiple matches for "John Smith." The correct move is always:

Ask for an additional identifier — email, phone, order number, postcode.

The cost of asking is one extra turn. The cost of acting on the wrong account is enormous (wrong refund, wrong PII exposure, wrong cancellation). Never resolve ambiguity with heuristics when the customer can disambiguate it in one turn.

TS 5.3Error Propagation

The headline rule: How a failure is reported matters as much as that it happened. Silent suppression and workflow termination are both anti-patterns.

Structured error context — four required fields

Together these give the model enough context to recover. Unstructured errors force the model to give up or hallucinate.

The two anti-patterns

Access failure vs valid empty result — exam favourite

Two superficially identical responses, opposite correct behaviours.

The structured error type distinguishes these. Treat all empty results the same and you either retry valid-empties forever or accept access failures as truth. Both wrong.

Coverage annotations — synthesis output discipline

"Section on geothermal energy is limited due to unavailable journal access (3 of 7 expected sources unreachable)."

Better than silently omitting the section. The consumer of the synthesis can now decide whether to act on partial data or wait for the gap to be filled. Silent omission destroys this signal.

TS 5.4Codebase Exploration

The headline rule: Extended agentic sessions degrade. Verbose discovery output dilutes early findings; the model reverts to generic "typical patterns" instead of session-specific facts.

Two symptoms of context degradation

1. Model references "typical patterns" instead of the specific classes/functions/files it discovered earlier — generic knowledge crowds out session-specific findings.
2. Context fills with verbose discovery output (file dumps, search results) and earlier conclusions get buried.

Both symptoms have the same root: high-signal early findings get diluted by high-volume later exploration.

Four mitigation strategies — match the mitigation to the symptom

Crash recovery — manifest pattern

Each agent exports structured state to a known file location (a manifest) at meaningful checkpoints. On resume, the coordinator loads the manifest and injects it into the resumed agent's prompts.

The manifest is the source of truth, not the conversation history. Robust to:

• Process crashes
• Context window exhaustion mid-task
• Operator interruptions
• Long-running jobs spanning multiple sessions

Without a manifest, a crash means starting over. With a manifest, a crash means resuming from the last checkpoint.

TS 5.5Human Review and Confidence Calibration

The headline rule: Aggregate metrics hide stratum-level failures. Calibration requires ground truth, not intuition.

The aggregate metrics trap — exam favourite

"Our extraction system achieves 97% accuracy. We can automate."

The trap: 97% overall accuracy can hide a 40% error rate on a specific document type that is rare in the validation set. If that document type is the high-value commercial contracts, your automation is dangerous despite the headline number.

Discipline: Always validate accuracy by document type and by field segment before automating. A single aggregate number is never sufficient evidence to remove humans from the loop.

Stratified random sampling — ongoing audit

Even after calibration and deployment, continue sampling high-confidence extractions for ongoing verification.

The discipline: a small, ongoing audit of "the cases we think are fine" is what catches the failures you didn't anticipate.

Field-level confidence calibration — the full pattern

Connection to 5.2: This is what makes confidence-based decisions reliable. Naive self-reported confidence is unreliable. Calibrated, field-level, validation-set-grounded confidence is reliable. The exam tests this distinction.

TS 5.6Information Provenance

The headline rule: Attribution must travel with every claim as structured data. Conflicts are surfaced, not resolved. Dates distinguish trends from contradictions.

Structured claim-source mappings — five required fields per finding

This bundle travels with the claim through every downstream agent. The synthesis agent preserves and merges these mappings — it does not flatten them into prose.

Without this structure, attribution dies the moment any agent summarises. The final report says "studies show X" with no path back to which study, by whom, when. That is not a research output; that is a plausible-sounding hallucination risk.

Conflict handling

Two credible sources report different numbers for the same statistic. The wrong moves and the right move:

Renewable energy share of global generation in 2024:
- 30% (IEA, World Energy Outlook 2025, published 2025-10)
- 32% (IRENA, Renewable Capacity Statistics 2025, published 2025-03)

Temporal awareness — date-aware reconciliation

Many apparent contradictions are actually different reporting periods. A 28% figure from 2022 and a 32% figure from 2024 are not conflicting — they show change over time.

Same logic for: market share, headcount, regulatory status, version numbers, anything that changes.

Content-appropriate rendering — match format to content

Flattening everything into one uniform format loses information. The exam may ask which format suits a given content type — match the content, do not impose a house style.

CribsheetDistractor Recognition

Decision treeMechanism-to-Failure Decision Tree

When a question describes a failure, ask in order:

1. Conversation history hitting the limit and you fear losing transactional facts? → Persistent case-facts block injected verbatim, summarise surrounding turns only
2. Key findings buried in long inputs and being missed? → Place summaries at the beginning + explicit section headers
3. Tool result has 40 fields when you need 5? → Trim before appending to context
4. Downstream agents drowning in upstream verbosity? → Modify upstream agents to return structured key facts only
5. Customer explicitly asks for a human? → Escalate immediately, no investigation
6. Customer is frustrated but issue is simple and no human requested? → Acknowledge, offer resolution, escalate only if reiterated
7. Multiple customers match the search query? → Ask for an additional identifier (email/phone/order ID)
8. Tool call failed and you're deciding how to report it? → Structured error: type + attempt + partial results + alternatives
9. Tool returned an empty array — should you retry? → Distinguish access failure (retry) from valid empty (do not retry; that is the answer)
10. One subagent fails in a pipeline of four? → Preserve the three successes, annotate the gap, do not terminate the pipeline
11. Long codebase exploration session: model referencing "typical patterns" instead of specific findings? → Scratchpad file with key findings, referenced for subsequent questions
12. Need parallel deep dives without bloating the coordinator's context? → Subagent delegation, coordinator receives distilled output only
13. Long-running job risks a mid-task crash? → Manifest file checkpoint pattern, resume from manifest
14. 97% accuracy claimed and team wants to automate? → Demand stratified validation by document type and field segment first
15. Need to catch novel error patterns after deployment? → Stratified sampling of high-confidence extractions, ongoing
16. Routing extractions to human review? → Per-field confidence, calibrated on labelled validation set, route low-confidence
17. Two credible sources report different numbers? → Annotate both with full source attribution; let the consumer decide
18. Same statistic with different values from different years? → Include publication dates; this is a trend, not a contradiction
19. Rendering the synthesis output? → Match format to content type (table/prose/list)

Carry-forwardLayer-Awareness Rule

Many wrong answers come from reaching for the right idea at the wrong layer:

When you feel the pull toward a fix, ask which layer the question is testing. A summarisation problem is a history-management question (case-facts block), not a prompt-content question ("tell the model to remember the refund amount"). An ambiguous-customer problem is an escalation-policy question (ask for identifier), not a tool-integration question. A novel-error-pattern problem is a validation-discipline question (stratified sampling of high-confidence cases), not a confidence-threshold question. Don't cross layers.

Cross-domainCross-Domain Connections

Domain 5's smallest weight is misleading — these concepts surface across other scenarios:

• TS 5.1 → Domain 1 (Customer Support Resolution): persistent case-facts block is the canonical fix for multi-turn refund/support cases
• TS 5.2 → Domain 1: escalation logic owns half of the support-agent question space
• TS 5.3 → Domain 2 (Multi-Agent Research): structured error propagation is what keeps research pipelines recoverable
• TS 5.4 → Domain 3 (Codebase Exploration): scratchpad/subagent/manifest patterns are the codebase-agent toolkit
• TS 5.5 → Domain 4 (Structured Data Extraction): calibration + stratified sampling overlap with Domain 4.6 confidence-based routing
• TS 5.6 → Domain 2: provenance is the difference between a research synthesis and a plausible-sounding hallucination

The calibrated-confidence pattern (TS 5.5) and the multi-instance review pattern (Domain 4.6) are the same architectural idea expressed at different layers. Recognise the family resemblance.