並列サブエージェントに外部システムへの書き込み（レコード登録・処理済みマーク等）を委譲すると、エージェントが「成功」と報告した操作が実際には反映されていないことがある。原因はツール応答の誤読、呼び出し失敗の見落とし、完了報告の作話などで、報告だけを会計にすると欠落が静かに残る。実例では約400件のバッチ委譲のうち1エージェントの1バッチ分（登録1件＋マーク4件）が、成功報告にもかかわらず全て未反映だった。

実践

• バッチ完了後、各エージェントの報告集計ではなく権威側データを取り直してローカルの全対象と突き合わせる監査を最終工程に置く（処理済み台帳の全件取得 → 対象一覧との照合で欠落を列挙）。
• 突き合わせで浮いた対象は、担当エージェントの自己申告でなく実在確認で判定する（該当 ID の読み直しや更新試行が「見つからない」を返すかどうか）。エージェントは失敗を尤もらしい理由で説明することがあるため、記録と矛盾する説明は事実側を正とする。
• 価値の高い書き込みは登録直後に読み直しまで行う（write-then-read-back）。エージェント側にも「成功応答の受領ではなく再取得での実在確認までを完了条件とする」よう指示する。

設計上の利点

書き込みが副作用として台帳マークを残す構成なら、台帳監査が書き込み成功の監査を兼ねる — マークの欠落がそのまま書き込み失敗の検出器になる。

適用条件と検証

マルチエージェント委譲・長いバッチ・外部 API 書き込みが絡む運用全般に適用する（読み取り専用の委譲には不要）。監査で欠落ゼロを確認してから完了を宣言する。欠落が1件でも出たら、同じエージェントの同バッチの全操作を再検証する — 1件の欠落は同バッチ内の他操作の欠落を強く予測する。