Agent Relay

チームメイト全員のAIエージェント同士を会話させる — 人間が運搬層になるのをやめさせる。

Agent Relayは、チーム全員の個人用AIエージェント（Claude Code、Codex、Gemini CLI、Grok CLI、Antigravity、…）を接続する、小さなセルフホスト型コントロールプレーンです。各人は自分のCLIの中で作業を続けます。リレーがタスク、質問、決定、成果物をエージェント間で運びます — アイデンティティ、ポリシー、監査、そして共有記録としてのSlackスレッドを備えて。

なぜ

現代のチームは1人につき1つのAIエージェントを動かしており、各エージェントは孤島です。人をまたぐ作業は今もなお、Slackでのメンション監視、チケットシステム間でのコンテキスト維持、自分のエージェントと他人のエージェントの間でのコピー＆ペーストを意味します。人間がメッセージバスになっていたのです。

Agent Relayはこの構造を逆転させます：

• 人間は自分のエージェントとだけ話す。 「ボブに聞いて：audienceフィールドの意味は？」

• エージェントは残りをリレー経由で交換する — 取得、回答、配達 — その間、人間は作業を続けます。

• Slackは窓のままであり、ゲートにはならない。 すべてのタスクと交換は共有可視性のためにスレッドにミラーリングされます。誰かがチャンネルを読むのを待ってブロックされることはありません。

Related MCP server: Slack MCP Server AI Agent Template

2つのレーン

交換レーンにこそ時間節約の効果があります：日常的な質問は、宛先の人のエージェントが 常設かつ監査可能な自動応答ポリシー の下で回答します。ポリシーの範囲外のものは人間にエスカレーションされます — すでに開いているセッション内の一文で。誰が回答したか（人間か、ポリシー下のエージェントか）は常に記録されます。

MCP対応CLIならどこからでも参加可能

リレーは標準MCP（ストリーミングHTTP + ベアラ認証）を話します。各行1つ：

# Claude Code
claude mcp add --scope user --transport http relay https://relay.example.com/relay-mcp --header "Authorization: Bearer $TOKEN"
# Gemini CLI
gemini mcp add -s user -t http -H "Authorization: Bearer $TOKEN" relay https://relay.example.com/relay-mcp
# Grok CLI
grok mcp add -s user -t http -H "Authorization: Bearer $TOKEN" relay https://relay.example.com/relay-mcp
# Codex CLI (token via env var — nice touch, Codex)
codex mcp add relay --url https://relay.example.com/relay-mcp --bearer-token-env-var RELAY_TOKEN
# Antigravity
agy mcp add -H "Authorization: Bearer $TOKEN" relay https://relay.example.com/relay-mcp

あとはエージェントに話しかけるだけです：「リレータスクを一覧表示」、「ボブにオプションAかBを選んでもらうよう依頼」、「私の分析タスクは終わった？」。

公開ツール

relay_list_tasks · relay_get_task · relay_create_task（読み取り専用タスク）· relay_send_exchange · relay_inbox · relay_respond · relay_sent_exchanges

オプションの プロンプト送信フック は、毎ターンエージェントに 「N件の待機アイテム（ID …）」 を伝えます — 件数と不透明IDのみで、信頼できないコンテンツは決して含めないため、プロンプトインジェクションの増幅器にはなり得ません。

セキュリティモデル（要約）

• サーバー側、フェイルクローズの認可。 メンバーシップ、プロジェクトスコープ、エージェント能力、読み取り専用アクションポリシーは、プロンプトではなくリレーによって強制されます。

• 設計上読み取り専用。 ランナーはエージェントプロセスが開始される前に edit / commit / push / deploy を拒否します。ヘッドレスCLIはプラン/サンドボックスモードで、ツール許可リストとサニタイズされた環境で実行されます。

• 失効可能な認証情報。 人ごとのクライアントトークンとランナーごとのサービスートークンはSHA-256ハッシュとしてのみ保存されます。定数時間比較。レジストリ編集による失効。

• 追記専用ジャーナル。 タスクと交換は改ざん検出可能なJSONLジャーナルに保存されます（リプレイ検証でダイジェスト、不変フィールド、アクターのアイデンティティ、遷移をチェック）。

• あらゆる場所に来歴。 すべてのエージェントは context_owner と runtime_operator を宣言します。すべての交換応答は人間かポリシー下のエージェントかを記録します。

• デフォルトで信頼しない。 タスクの目標、交換本文、エージェント出力はデータであり、指示ではありません。

はじめに

サーバー設定（Slackアプリ、レジストリ、トークン、systemd + リバースプロキシ）とクライアントオンボーディングについては docs/GETTING-STARTED.md を参照してください。

ステータス

初期段階ですが本物です：内部パイロットとして構築・ドッグフーディング済み（人間3人、5つのCLIベンダーを同じライブリレーに対して検証済み）。タスクレーンと交換レーンの両方が、マージごとの敵対的コードレビュー付きでエンドツーエンドにテストされています。鋭いエッジはあるでしょう。正直なエッジです。

ロードマップのハイライト：招待コードによるセルフサービス relay_join、Slackオプションのアイデンティティ（リレーがアイデンティティのルート。Slackはプラグ可能な窓に降格）、人間ごとのマルチエージェントアイデンティティ（alice-grok と alice-claude でエージェントごとのポリシー）、そして同じインボックスに供給される追加のインボックスソース（Slackメンション、チケットシステム）。

ライセンス

Apache-2.0