最大配点ドメイン。エージェントの心臓部（ループ）から、複数エージェントの協働、hookによる強制、セッション管理まで。うちの組織の Lead/Worker 運用がそのまま出題範囲。
stop_reason だけで判定する。stop_reason を確認 →「tool_use（ツールを使いたい）」なら要求されたツールを実行して結果を返す →「end_turn（話し終わった）」ならループ終了Claude Code のターンそのもの。ツールを呼んでは結果を読み、また次のツールを呼ぶ動きの裏側が全部このループ。rules/workflow-cycle.md の停止条件（試行N回・CRITICAL到達で止める）は、このAPIレベルのループの上に載せた業務レベルの安全網という関係。試験ではまずAPIレベル（stop_reason）で答える。
stop_reason で判定するrules/lead-worker-orchestration.md がこのパターンの実装。「Lead は判定・分解・委譲・統合のみ」「Worker間の直接通信は禁止（必ずLeadを介す）」は、試験用語でいうハブ&スポークと情報ルーティングの一元化。rules/audit-independence.md の盲検原則は「サブエージェントのコンテキスト独立性」を監査品質に応用したもの。
allowedTools に "Task" が含まれている必要があるCLAUDE.md の「怠惰な委譲の禁止（具体的なファイルパス・行番号・変更内容を含むプロンプトで委譲）」＝明示的コンテキスト渡しの運用ルール化。agents/*.md の frontmatter（description / model / tools）が AgentDefinition に相当。「独立タスクは1メッセージで並列に投げる」運用もそのまま試験の正解パターン。
get_customer で顧客IDが確認されるまで process_refund の呼び出しをブロックする前提条件ゲート（サンプル問題Q1の正解そのもの）この対立軸は rules/extension-layer-decision.md の「影響（確率的・お願い）か保証（決定論的・強制）か」そのもの。実装例は hooks/larc-approval-gate.sh（本番書込みを承認なしでは通さない）と hooks/git-identity-guard.sh（identity不一致のcommitをブロック）。構造化ハンドオフは rules/handoff-memory.md の引き継ぎテンプレ（確証／未確証／残り）が同じ思想。
実行前ブロック型の実物が hooks/larc-approval-gate.sh（Lark本番書込みを検問、exit 2でブロック）と hooks/git-identity-guard.sh。PostToolUse型は scripts/hooks/session-budget-breaker.js（トークン消費の監視）。「$500超の返金ブロック」は larc の広告予算変更ゲートと同型の問題として読める。
CLAUDE.md のバッチ処理パターンが同じ判断軸：「各タスクが独立→並列」「相互依存→ループ」「対象が動的・大規模→動的ワークフロー」。rules/audit-independence.md の直列監査（editorial-checker → geo-auditor）はプロンプトチェイニングの実例。rules/lead-worker-orchestration.md の Competing Hypotheses（仮説ごとに検証Workerを立てる）は動的分解の実例。
--resume <セッション名>：名前付きセッションの再開。数日がかりの調査を続きからfork_session：共通の分析結果を土台に、独立した枝を複数作って別アプローチを比較する（例：2つのリファクタ方針を同じ土台から試す）この「新規＋構造化サマリー」がまさに rules/handoff-memory.md のセッション引き継ぎ（確証済み／未確証／残り の3分割で次セッションに渡す）。memory/project-*.md の「次回の続き」セクションは、試験用語でいう structured summary injection。fork は Agent tool の subagent_type: "fork" で日常的に使っている機能。
Claudeの応答が「なぜそこで止まったか」を示すフラグ。tool_use＝ツールを使いたいから一時停止（→ループ継続）、end_turn＝言い終わった（→ループ終了）。エージェントループの制御はこれ一本で行う。
「送信 → stop_reason確認 → ツール実行 → 結果を履歴に追記 → 再送信」の反復。エージェントと呼ばれるものすべての心臓部。
車輪のように、中心（コーディネーター）とだけ各エージェントがつながる構造。子同士の直接通信を禁じることで、観測・エラー処理・情報の流れを一元管理できる。
Task＝サブエージェントを生成する公式の仕組み。allowedTools＝そのエージェントが使ってよいツールの許可リスト。コーディネーターの allowedTools に "Task" が入っていないと子を呼べない。
サブエージェントの型定義。説明文（いつ使う子か）・システムプロンプト・ツール制限を含む。うちの agents/*.md の frontmatter に相当。
サブエージェントは親の会話履歴・記憶を自動継承しない、という仕様。渡したい情報はプロンプトに明示的に書く。試験全体で繰り返し問われる大前提。
ツール実行の後／前に割り込む検問所。Post＝結果の正規化・監視、実行前介入＝ポリシー違反のブロック。「プロンプトは確率的、hookは決定論的」という対比で覚える。
大きな仕事を固定の直列ステップに割り、前段の出力を次段の入力にする方式。手順が予測できる多段レビュー向き。
resume＝名前付きセッションの再開。fork＝共通の土台から独立した複数の枝を分岐。「前回のツール結果が古いなら、要約を渡して新規セッション」が試験の推し判断。
人間や別エージェントへ引き継ぐときに、顧客ID・原因分析・推奨アクションなど決まった項目のセットで渡すこと。「会話ログを読めない相手」が前提。