オーケストレーター：なぜ意図がプロセスを超えて存続すべきか

現在のエージェントスタックは逆転している。サーフェス（端末、エディタ）がモデル、ツール、履歴を所有し、アイデンティティは一時的である——新しい端末を開けばエージェントは消えてしまう。筆者は、インテントを単一のプロセスから切り離すオーケストレーター層を提案する。主要な特性：

• セッションを超えたアイデンティティ： 論理的なエージェントがプロセス間で永続化する。セッションは行き来するが、エージェントは残る。
• サーフェスを横断するルーティング： エージェントは作業を異なるマシン（例：リポジトリボックス、GPUボックス、電話）に派遣し、それらを無関係なものとして扱わない。
• 真のハンドオフプリミティブ： 型付きオブジェクトで、何が完了したか、未完了か、ブロックされた判断を運ぶ——損失のあるチャット履歴ではない。
• サブエージェントではなくピアエージェント： 異なるコンテキストにある二つのエージェントが、どちらも所有しない制御プレーンを介して連携する。
• クロスドライバー呼び出し： 「安価なモデルで要約、高価なモデルで行動」はプロンプトエンジニアリングではなくプリミティブである。オーケストレーターがコスト、レイテンシ、機能に応じてステップごとにランタイムを選択する。
• 持続する承認サーフェス： エージェントが承認で一時停止し、あなたが三つのタイムゾーン離れている場合、承認はエージェントを生かしたままあなたの元に届く。

具体的な例：不安定なテストのトリアージ

現在、あなたは三つの端末を開き、Claude、Gemini、Grokの間でスタックトレースを貼り付けている。筆者が望む流れは、単一のオーケストレーターインテントの下で：「この不安定さをトリアージし、修正案を提案し、レビューを受ける」

• Ollama（ローカル）： テストログを取り込み、ノイズを除去し、構造化された障害サマリーを生成する。無料で、マシンから出ない。
• Gemini CLI： サマリーとリポジトリを受け取り、疑わしい変更を特定し、パッチを草案する。大規模コンテキスト、コード読み取りに強く、リポジトリへの読み取り専用アクセス。
• Grok Build： パッチと元の障害を受け取り、判定（出荷/修正/エスカレーション）をレンダリングする。別のモデルファミリーによるセカンドオピニオン。書き込みアクセスなし。

三つのランタイム、三つの権限スコープ、三つのコスト階層、一つのインテント。オーケストレーターはステップ間でハンドオフオブジェクトを運び、一つの承認を提示する（三つの断片的な会話ではなく）。Grokが「エスカレーション」と言った場合、インテントは一時停止し、人間の判断を待つ——OllamaやGeminiを生かしたままにせずに。

先週の時点で、少なくとも三つの端末ネイティブコーディングエージェントがローカルで動作している：Ollamaランタイム、GoogleのGemini CLI、およびプランモードと並列サブエージェントを持つxAIのGrok Build。モデルは安価で交換可能な部分である。オーケストレーターは退屈で耐久性のある部分であるべきだ。