マルチエージェント構成で「リーダー → 中間エージェント（ラッパー）→ 外部 CLI エージェント」の3層委任を組むと、ラッパーがプロンプトを受け渡すだけの通過点になり、付加価値なしに構造的な摩擦を生む。実運用（3リポジトリ・5フェーズの実装）で観測した摩擦は実装時間の3〜4割に相当した。

観測した3つの構造的摩擦

• 完了通知の非対称: ラッパーは外部 CLI をバックグラウンド起動した直後にターンを終えて待機化するため、配下プロセスの完了を自分で検知できない。結局リーダーが PID 監視や stall 検知で肩代わりする。一方、ハーネスが直接管理するエージェントは作業終了＝ターン終了で自動通知される。
• 実行環境の権限差による二重検証: 外部 CLI の sandbox が DB・Docker・ネットワークを遮断する場合、migration 適用や全量テストをリーダーがホストで再実行する二重コストが毎フェーズ発生する。セッションと同権限で動くエージェントなら完了条件まで自走できる。
• 待機中の文脈陳腐化: 待機から復帰したラッパーが古い文脈で状況を誤認し（例: 正規のコミットを無断コミットと誤認して reset を提案）、訂正の往復が発生する。

判断基準

• 委任は2層（リーダー→実行主体）を基本にする。外部 CLI を使うならリーダーが直接起動・監視する。中間層が正当化されるのは、その層が変換や判断（タスク分解、結果の検証・翻訳）を加える場合だけで、プロンプトの受け渡しだけなら不要。
• 別モデルの視点（クロスモデル検証）が欲しい場合は、実装側ではなくレビュー側に置く。レビューは one-shot の read-only 実行で完結し（コード修正を構造的に禁止できる）、常駐セッションも完了検知も不要なためラッパーの摩擦が発生しない。
• レビュアーは常駐させない。レビュー→修正を複数ラウンド反復する場合も、各ラウンドを独立した one-shot として都度起動すれば、常駐に伴う摩擦（完了検知の肩代わり・待機中の文脈陳腐化）は発生しない。

適用条件・例外

• トークンコストの帰属を別ベンダーに逃がしたい場合は外部 CLI 委任に値段の利点が残るが、その場合も中間ラッパーは省きリーダー直叩きにする（層数と委任先モデルは独立のレバー）。
• 同一チェックアウトでの並列編集は衝突するため、並列化の境界はリポジトリ（git 境界）単位に置く。

検証

構成変更の前後で「実装時間に対する調整・監視・二重検証の時間比率」を比較する。ラッパー廃止後にリーダーがプロセス監視・ホスト再検証をしていないこと、完了通知が自動で届くことを確認する。