エージェントランタイム設計

Agent runtime 設計に関する継続的な観察集。各項目は独立しているが、いずれも同じ判断を指している：プロトコル層の設計が agent の挙動品質を決める。

拒否権の境界（veto boundary）——マルチ Agent 協調は指示の伝言ゲームではない。Orchestrator はタスクを分解し意図を割り当てるが、受け手側の各 Agent には明確な拒否権の境界が要る：どんな場合に上流の指示を拒否してよく、どんな場合に必ず実行するのか。拒否権の境界がないオーケストレーションは、エラーが伝播したときにブレーキを持たない。（note）

ツール状態としての自然言語（natural language tool state）——agent が bash を書くときにコメントを添え、&& echo ok || echo failed で exit code を言葉に翻訳するのは、一見冗長だが、実際には状態をモデルが最も消費しやすい表現に変換している。Tool use を設計するときは、tool input に intent の記述を持たせ、tool output に自然言語の状態を返させてよい——裸のデータだけにしない。（note）

tool_result のロール設計（tool call role design）——Claude が tool_result を role: user に入れるのは混乱ではない：ここでの "user" は client / environment が差し戻す外部観察を運ぶのであって、生身の人間の発言ではない。一方 Codex / Responses API はツール呼び出しと結果を独立イベントとしてモデル化する。二つのプロトコル形状は、コンテキスト操作（トリミング・リプレイ・キャッシュ）への影響が異なる。（note）

Context System の六層責務（context system layering）——「コンテキスト」を一塊のままモデルに与えるのは、複雑性が暴走し始める起点だ。責務を分層する：System Prompt には安定した identity、少数の越えてはならない境界、出力プロトコルだけを置く（一時的な状態や bad case の例外は置かない）；Dynamic Context には当該ターンで確認済みの事実・状態・許容空間を置く；State/Code/Engine が状態遷移と決定論的裁定を担う；Tool/Retrieval は必要時に外部事実を取得し、出所と鮮度を付す（関連しそうなものを一括投入しない）；LLM は実際の会話の理解・曖昧さの処理・自然な表現だけを担う（システムが既に知っている確定事実を繰り返し推測しない）；Frontend/Guard がユーザー確認とアクション実行という最後の関門を担う（高リスクなアクションを一行の Prompt に託さない）。表現形式はそれぞれ異なる複雑性を担う：boolean は関門、enum はレール、schema は構造境界、自然言語はオープンワールド担当——判断基準は、そのルールが確率的実行を許容できるかどうかだ。（source）

会話の空気（conversational air）——構造化の逆の極端は、モデルを「飢えさせる」ことだ。すべてを boolean/enum/短いフィールドにすると、モデルはユーザーが長く待っていること、前のターンで同じ質問をしたこと、この一言が不満への応答なのか確認なのかを知らず、「どのフィールドも正しいのに他人のようだ」という返答を生む。「今回は両親も一緒だから、詰め込みすぎないで」という原文を削れば、構造的に正しい旅程でも体験は悪くなり得る。原則：確定的な情報が「理解を要する散文」のふりをするのをやめさせ、同時にモデルが実際の会話を理解するのに必要な文脈は残す——自然言語は少ないほどよいのではなく、帰属先のない暗黙ルールが少ないほどよい。「ツール状態としての自然言語」と互いの境界条件になっている：状態は言語に翻訳できるが、文脈はフィールドに圧縮できない。（source）

遅延は回答品質そのもの（latency as answer quality）——リアルタイム agent には狭いユーザー意思決定ウィンドウがある：提案が決定の形成前に届けば助けになり、後に届けばただの割り込みだ。実測例：リアルタイムのカスタマーサポート Copilot に RAG を足したところ、オフライン指標は軒並み改善、エンドツーエンド遅延は ~2.6s→~5.5s、リリース後の採用率はゼロになった——モデルは愚かになっておらず、内容も悪化しておらず、システムはエラーも出していないのに、プロダクトとして失敗した。推論：能力（検索など）はリアルタイムのクリティカルパスに常駐する必要はなく、オフライン資産・few-shot・非リアルタイムフローへ退避できる；評価はエンドツーエンド遅延と実際の採用を同じ一枚の絵に入れ、かつ三つのスケール——コンポーネントと契約、エンドツーエンドの連鎖、本番プロダクトの成果——を同時に見なければならない。単一ノードの正しさは単一ノードの正しさしか証明せず、harness 全体の証人にはなれない。（source）

エンジニアリング実践側の対照サンプルは agent-iteration-harness：イテレーションが複数ラウンドに入ると、runtime 設計の問題（誰がどのコンテキストを見るか、誰に拒否権があるか、劣化はどう堰き止められるか）が、成果のむらとして表面化する。