Coordinator

coordinator はユーザーが実際に対話するペルソナです。すべてのチャット セッション（Web UI、Slack、Telegram、Feishu）は 1 つの coordinator インスタンスに所有されます。これは ワーカーではなく、会話を駆動する 長命の ReAct ループで、いつ自分で直接答えるかを判断し、いつ specialist へ AgentTool 経由で dispatch するかを 判断します。

Identity

フィールド	値
Persona name	default
ワーカーとして spawn 可能か	いいえ —— エージェントカタログから default は除外される
Session モデル	(user, chat thread) ごとに chat_sessions 1 行が長命で存在
Tool bag	幅広い：query_*、AgentTool、SendMessage、TaskStop、redirect スタブ
Persona 本文	manager イメージに同梱。組織ごとのオーバーライドはマウントファイル経由

coordinator の挙動をフリート全体で変更したい場合は、組み込みの default.md をカスタム版でマウントオーバーライドしてください （カスタムエージェント 参照）。 AgentRegistry.Replace の seam がユーザーエージェント編集 UI を支えており、起動時のオーバーライド ファイルも同じコードパスを使います。

直接できること

coordinator の tool bag には manager スコープで動作するすべての読み取り専用 query ツールが含まれます。

• query_promql、query_logql、query_traceql —— テレメトリ。既知の ハルシネーションケースについては coordinator 側でスタブ化されており （incident-investigator へリダイレクト）、以下で説明します。
• query_knowledge —— vault + アップロードに対する RAG。
• query_incidents、get_incident_detail、query_alert_rules、 query_devices —— アラート / インベントリ。
• query_change_events —— 直近の設定 / ルール / デバイスの変更。
• expand_topology、find_topology_node —— サービスグラフ。
• get_active_incidents —— 現在オープンなアラート。
• BC ハンドラーツール —— UI から組織 / ユーザー admin が行うあらゆる操作。

意図的にホスト shell やホスト単位の検査ツールは 持ちません。それらは specialist 側にあります。

制御ツール三点セット

coordinator にだけ存在する 3 つの特殊ツールです。マルチエージェントの オーケストレーションを制御するもので、クエリは行いません。

AgentTool

ワーカーを dispatch します。同期。完全なスキーマ、重複排除挙動、 「些事を delegate しない」ガードレールについては エージェント概要 に記載しています。形は次のとおり。

{
  "description": "Find which process is OOM-ing on node-01",
  "subagent_type": "specialist-compute",
  "prompt": "On device_id=7 we saw mem_used_pct=98 at 14:02. Find the top RSS processes and check dmesg for oom-killer hits. The user originally asked: 'who's eating memory on node-01?'"
}

システムリマインダーがペルソナカタログを注入するので、LLM は有効な subagent_type の値を把握できます。リマインダーは ターンごと に入る ため、長いセッションで attention drift が起きても LLM はどの specialist が 存在するかを忘れません。

SendMessage

ターンを終わらせずに ユーザーへ中間メッセージを送信します。たとえば coordinator が「specialist-network に dispatch するので少し待ってください」 と dispatch が落ち着く前に伝えたいときに使います。ワーカーはこのツールを 持ちません —— ユーザーと話すのは coordinator だけです。

IM ブリッジはこれを使ってチャット内のプレースホルダーメッセージを更新します （Slack なら chat.update、Telegram なら editMessageText、Feishu なら PUT /messages）。Web UI はこれを使って最終回答の前に中間テキストを トランスクリプトにストリームします。

TaskStop

実行中のワーカーを丁寧にキャンセルします。たとえばユーザーが dispatch の 途中で話題を変え、実行中ワーカーの回答が不要になったとき、coordinator は TaskStop を発行します。

内部的には Runtime.StopWorker を呼び、ワーカーの context.CancelFunc を発火させます。ワーカーは次の ツール呼び出しで ctx.Done() を観測し、Status = killed を立てます。

dispatch するか直接答えるか

coordinator のペルソナプロンプトはルールをこう記述しています。

AgentTool 不是默认选项。能用本地工具 1-2 步答出来的，自己答。复杂深挖 （需要 5+ 步 / 跨主机 / 跨信号面）才派。

訳すと、dispatch するのは以下のときだけです。

• 深い反復 が必要（集中した検査で 5 回以上のツール呼び出し）、
• ホスト側ツール（host_bash、host_probe_*、host_du_summary）が 必要、または
• coordinator が持っていない ドメイン特化の tool bag から恩恵を受ける。

「node-01 の load は？」程度なら coordinator は get_host_load 1 回で 直接答えます（より正確には、redirect スタブ経由の AgentTool(specialist-compute)。原則は同じです）。「order サービスが 502 を投げ始めた理由とどう対処すべきか？」なら incident-investigator へ dispatch します。

Redirect スタブ（ハルシネーション対策）

coordinator の bag には、LLM がハルシネーションしやすいツール名 （host_bash、host_du_summary、host_restart_service、get_host_load、 correlate_incident など）に対する RedirectStub エントリが入っています。LLM がスタブ済みの名前を選ぶと、スタブは 次を返します。

{
  "status": "redirect",
  "hint": "This tool is not available in coordinator scope. Re-invoke via AgentTool to dispatch to specialist-disk.",
  "reason": "目录占用分析",
  "suggested_call": "AgentTool(description=\"…\", subagent_type=\"specialist-disk\", prompt=\"<self-contained task>\", background=true)",
  "why_stub_exists": "Coordinator's job is dispatch + triage. Deep-dive tools live on specialist workers; calling them inline is the wrong pattern."
}

これらのスタブがなければ、eino のグラフランタイムが [NodeRunError] tool X not found in toolsNode indexes で中断して ターンを浪費します。あれば LLM は結果から学び、次のイテレーションで 正しい AgentTool 呼び出しを試みます。スタブのリストは CoordinatorRedirectStubs にあります。純粋なデータなので、新しいハルシネーションが現れたら追記して ください。

specialist bag 全体をシャドウしないこと

各スタブは LLM に提示されるスキーマリストのスロットを 1 つ消費します。 スタブを多用するとプロンプト予算が膨らみ、LLM がスタブを有効な候補として 扱い始める可能性があります。eval でハルシネーションが観測されたツール だけにスタブを付けてください。

ユーザーから見えること

ターンごとに coordinator は以下が可能です。

1. トークンを直接ストリーム —— 回答が短く自己完結している場合。
2. 読み取り専用 query ツールをインラインで呼ぶ —— query_incidents、 expand_topology、query_knowledge。
3. AgentTool でワーカーを dispatch —— SPA がペルソナ名と 1 行の description 入りの「Agent タイル」をワーカー実行中に表示します。最終的な ワーカー結果はタイルの子として表示されます。
4. SendMessage で中間メッセージを送る —— 通常は遅い dispatch が 落ち着く前（「調査中、specialist-network を起動します」）。
5. TaskStop でワーカーを止める —— 稀。通常は dispatch 途中でユーザーが 方向転換した場合のみ。

ユーザーがワーカーの生のトランスクリプトを目にすることはありません。 coordinator がワーカーの Result を自身の返信に合成します。

セッションと監査

• coordinator セッションは chat_sessions に agent_id = "default"、 parent_session_id = NULL で存在します。
• ワーカーセッションは parent_session_id が coordinator の行を指します。 監査 UI はこのツリーをたどって親 → 子の実行を描画します。
• すべてのツール呼び出しは LLM が見た引数と切り詰めた結果とともに audit_logs に 1 行記録されます (セルフ可観測性 参照)。

coordinator のカスタマイズ

coordinator のペルソナファイルはオーバーライド できます。典型的に 変更したくなるもの。

• dispatch ガイダンス（自チームの「いつ delegate するか」ポリシーが 異なる場合）。
• 出力言語 / トーン（チャネルの default_locale を使うか、ペルソナ本文に固定）。
• dispatch する前に coordinator に使わせたい読み取り専用インラインツールの 一覧。

変更す べきでない もの。

• エージェントカタログブロック —— 機械生成です。編集しても次回リロードで 再生成されます。
• redirect スタブのセマンティクス —— ペルソナではなくコードです。
• default という name —— ランタイムは名前で coordinator を引きます。

ホットリロードの仕組みは カスタムエージェント を 参照してください。