四十もの会話が同時に開かれているチームを想像してください。ある会話では、エージェントに顧客への提案を依頼しています。別の会話では、同僚が納期の見積もりを尋ねています。さらに別の人は、同じ機能を今月中に出せるか確認しています。
どの会話も背景の説明から始まります。顧客は誰か。何を約束したか。昨日、何を決めたか。エージェントはそれぞれ仕事を始めますが、見ている情報は一部ずつ違います。やがて誰かが、提案で約束している日付は、開発の議論ですでに見送られていたと気づきます。
そして Task が終わります。その会話は静かになります。一週間後、別の人が関連する仕事を始め、また背景を説明します。
エージェントを作る中で、私たちは何度もこの場面に立ち返りました。次の仕事を、チームがすでに学んだことから始めたいと考えました。そこから単一セッションの設計に進みました。持続する一つのメインの会話と、個々の Task を独立して実行する Worker を組み合わせます。
サブエージェントは仕事の分担を助けます。単一セッションが答えるのは、別の問いです。仕事への理解は、時間がたつ中でどこに蓄積されるのでしょうか。私たちは両方を使います。メインの会話がチームの継続性を支え、Worker がそれぞれの仕事を進める場所を持ちます。
個人からチャンネル、そしてチームへ
Poke は個人のエージェントにシンプルな居場所を与えました。一人に一つの会話です（2025 年 9 月）。個人のメール、カレンダー、ファイルをテキストの会話につなぎました。返信の下書きや会議の日程変更を、前の依頼と同じ場所から始められます。一日の用事が進む中で、その会話は何度も戻れる場所になりました。体験の中心は個人との関係です。異なる仕事の間で継続性を保つ具体例を、私たちはそこに見ました。
Claude Tag はチャンネルに一つの Claude を持ち込みました（2026 年 6 月 23 日）。誰もが同じエージェントを呼び、その仕事を見て、同僚の続きから会話を進められます。Claude は関連情報を時間とともに記憶し、管理者が許可したツールを使います。発表では、許可があれば他のチャンネルや情報源からも学べると説明されました。私たちが注目したのは共有する会話です。いつも仕事を話し合う場所で、そのまま仕事を任せられます。私たち自身の設計では、さまざまな議論と Task の情報が戻る先を、チームのメインの会話に置いています。
私たちは、一つのチームに一つの会話という形を探ることにしました。対象となる範囲は、議論をまたぐチームの仕事に沿います。納期の決定は、別々の場所で始まった仕事でも、顧客への提案に反映できます。
2026 年 4 月 28 日、私たちは以前の製品 Bridge に関する最初の関連記事を公開しました。この探索は Poke より後、Claude Tag より前にあたります。その後、現在の製品 Comma（2026 年 10 月 1 日）で取り組みを続け、この設計は今も Comma 上で動いています。
DeepSeek Harness も 2026 年 10 月 31 日に Super-agent の探索を発表しました。グループチャットでコードの仕事を能動的に進める姿は、調整を人からシステムへ移すという同じ方向を示しています。この研究プロトタイプは独自の設計に沿っています。
DeepSeek の設計記事の第 8.4 節は、クラウドの侵害やプロンプトインジェクションによる接続機器の危険と、モデルのコンテキストを通じた認証情報の漏えいを未解決の問題に挙げています。私たちが運用している内容の送信先に対する仕組みは IFC です。出所を宣言し、送信先の読者を確認し、許可されない送信は拒否し、必要なら範囲を限定した人の承認を求めます。
認証情報は別の経路を通ります。モデルは認証情報の参照を指定し、実行層が値を解決して注入します。値はモデルに返しません。
チームに残るもの
提案の仕事に新しい同僚が加わる場面を考えてみます。その人が入るのは、チームが使い続けてきた同じメインの会話です。そこに共有された決定を読み、日付が変わった理由を尋ね、三人から三つの要約をもらわずに仕事を引き継げます。ワークスペースへの参加によって共有会話を開けますが、決定の裏にある資料へのアクセスには、その資料の権限が適用されます。
完了した Task には結果と履歴が残ります。たとえば、ある顧客には特殊なエクスポート形式が必要だと分かったとします。報告は Router に戻り、後の提案でその発見と出所を参照できます。Task が終わっても、チームには学んだことを確かめに戻る場所があります。
並行作業では、この戻り道が重要です。ある Worker は顧客要件を読み、別の Worker は技術的な制約を調べているかもしれません。発見が何度も言い換えられてチームに届くと、重要な条件が抜け落ちることがあります。各 Task は発見とその出所を一緒に報告します。Router はそれらを同じメインコンテキストで受け取ります。
そこで私たちは、エージェントハーネスを二つの役割に分けました。一方がチームの継続する会話を追い、ほかの役割が個々の仕事を実行します。
Router と Worker の連携
ワークスペースには常駐する Router を一つ置きます。チームのメインコンテキストを持ち、依頼が届き、決定が変わり、結果が戻る間も会話を追い続けます。提案への依頼は、すでに進んでいる納期の議論と同じコンテキストに届きます。各入力メッセージには、出所となる会話とメッセージの識別情報が付いています。Router は議論間でコンテキストを共有しながら、各入力がどこから来たかを保持します。
Router は明確な仕事を Worker に渡します。Task ごとに新しい Worker セッションが始まり、その仕事の指示と引き継ぎ内容を受け取ります。ほかの Worker の履歴はそれぞれのセッションに残ります。複数の Worker が別々の問いを同時に調査できます。
各 Task に、目標、その達成に使うコンテキスト、期待する成果物を定めます。「この顧客を調べて」では不明な点が多く残ります。「顧客のエクスポート要件を確認し、出所と未解決の問いを添えて形式を提案して」なら、Worker には完了できる仕事があり、Router には使える結果が戻ります。
提案にエクスポート要件の確認と納期の見積もりが必要だとします。それぞれを別の Worker に任せられます。一方は顧客要件を返し、もう一方は見積もりとその前提を返します。Router は結果をメインの会話に戻し、チームが決定できるようにします。完了した仕事に、帰る道があります。
メインの会話への返信も含め、見える返信はすべて明示的な送信です。Router は宛先を指定し、その宛先の確認を通ります。モデルの出力やターンの終了が、自動で返信を公開することはありません。Worker が報告したり別の参加者に話しかけたりするときも同じ規則です。資料の閲覧は仕事のコンテキストを与え、送信は別の操作として扱います。
情報フロー制御
並行する Task は、読者の異なる出所を集めます。送信のたびに使った出所を宣言します。情報フロー制御、IFC は、送信先の読者がそれらの出所を読めるか確認します。
強制適用が有効な場合、拒否された送信は理由を返します。エージェントは制限された内容を除いて再試行するか、必要な範囲の人による承認を求められます。再試行では出所の宣言とともに本文も修正します。
IFC は、返信の準備と共有の間に、チームが確認できる一段階を設けます。
提案に戻ると、Router は見積もりをチームに示し、残る判断を尋ね、合意した答えを適切な経路で送れます。Worker の仕事には範囲があり、チームの会話はその引き継ぎを越えて続きます。
新しい Task は新しい Worker セッションを開きます。セッションを切り替える際は、未完了の仕事と参照を次へ渡します。チームには、以前の決定に戻れる場所も必要です。
チームが共に学ぶこと
再利用できる手順は、グループで共有する skill になります。編集可能な指示とリソースです。エージェント側の編集は作成者が管理します。他のエージェントは書き換えずに利用でき、読み取り専用の組み込み skill はコピーして調整できます。セッションは自分の範囲のカタログを受け取り、関連する指示を開きます。
Router は、人、環境、一般的な事実、日付付きの出来事について永続的な記憶を維持します。必要に応じて読み取り、検索します。通常の Worker は Task の引き継ぎを使い、割り当てられた Triage Worker は出所に紐づく読み取り専用アクセスを持ちます。記憶への書き込みは Router が担います。
有効にすると、Condensed Workspace はすべての内部 Router と Worker のセッションに、グループの現在の事実をまとめた同じ短い一覧を渡します。ワークスペースの所有者は直接編集できます。
エージェントの更新には、他のエージェントに役立つ現在の事実かを確認する助言的なチェックがあります。改訂と最後の書き手を記録します。所有者は記述を修正、削除でき、共有する前提を見て編集できます。拒否された更新は、その拒否 ID を付けて再試行し、明示的にチェックを上書きできます。
一つの会話を続けるコスト
この構成はメインセッションに負荷をかけます。Worker は並行して動けますが、Router は結果をまとめる必要があります。先の依頼を処理している間に、新しい依頼が届くこともあります。背後に何人の Worker がいても、人には待ち行列として感じられます。
直列の待ち行列は、今も取り組んでいる問題です。長い調査を委任すれば Router に応答する余地が増えますが、互いに影響する決定には順序が必要です。提案では、最後の約束を外へ出す前に、誰かが納期を決めなければなりません。共有会話はその依存関係を見やすくし、仕事を進める Router の責任も増やします。
履歴にもコストがあります。完了した Task は、後で役立つ情報と、二度と使わない多くの情報を残します。履歴が増えるにつれ、必要な決定とその理由を見つける手間も増えます。
同僚に議論全体を説明し直してもらわずに、昔の決定を見つけやすくしたいと考えています。その理由が、変更すべき時をチームに教えてくれます。
私たちの探索はここまで来ました。異なる人と異なる Task を通じて、チームは同じ仕事に何度も戻ります。それが共有するメインの会話を選んだ理由です。次に誰かが関連する議論を開いたとき、以前の努力がそこで待っているようにしたいのです。
