すべての主要ベンダーのエージェント。
ひとつのクライアント、それぞれサンドボックス。

どちらもシェルは得られますが、生き残るセッションは得られません。exec の途中でターミナルを閉じれば、プロセスは接続と一緒に死にます。ここではセッションがコンテナの中で生きているので、アプリを閉じても閉じるのは WebSocket ひとつだけです。次の起動で出力が止まったバイト位置から接続し直し、同じ分割レイアウトを復元します。デプロイの形も違います。クライアントに kubeconfig は不要、port-forward も不要で、資格情報が許可するのはクラスタ全体ではなくセッション 1 つです。

Herdr はエージェントマルチプレクサ — コーディングエージェント版の tmux です。各エージェントに本物の PTY を与え、切断されても生かし続け、各ペインを working／blocked／idle に分類し、CLI と socket API を備えています。永続性と一覧性という点は、このアプリとほぼそのまま重なります。違うのはエージェントがどこで動くかです:

• Herdr は起動したマシンの上で動かすので、ユーザー、ファイルシステム、資格情報を共有します — つまり影響範囲はそのマシンと、あなたのアカウントが到達できるすべてです。永続するのは切断に対してで、ホストの電源が落ちることに対してではないため、ノート PC 上で動かしていれば閉じた時点ですべて終わります。（SSH リモートモードはこれを避けられますが、影響範囲がそのリモートホストに移ります。）
• OpenAB Connect は各セッションをクラスタ内の独立したコンテナで動かします — uid 1000、sudo なし、ホストの資格情報なし、ルートは読み取り専用、ワークスペースは使い捨て — WireGuard の tailnet 経由で、ポートは一切開けません。影響範囲はそのコンテナで、あなたのマシンではありません。ノートを閉じても、スリープさせても、別のノートに変えても動き続けます。

違いはサンドボックス化であって、マルチプレクスではありません。Herdr にできて OpenAB Connect にできないこともあります。ペインの状態判定、スクリプト可能なローカル API、そしてインフラを一切必要としない点です。何もデプロイしたくないなら、Herdr のほうが適した答えです。

Mac 上のエージェントは、あなたとして動きます。SSH 鍵、クラウドの資格情報、npm や GitHub のトークン、ディスク上のすべてのリポジトリに手が届くので、間違ったコマンドはあなたのマシンでの間違ったコマンドになります。こちらのシェルはそれらを一切持たず、ワークスペースはセッションとともに破棄され、複数のエージェントが同じ作業ツリーや同じポートを奪い合わずに同時に働けます。ノートを閉じてもスリープさせても、何も止まりません。代償は実在します。エージェントはローカルのファイルを見られないので作業は git 経由になり、イメージの初回取得には数分かかり、クラスタか AWS アカウントが必要です。すでに開いているリポジトリを一行直すだけなら、ローカルで動かすほうが簡単で、これは何の足しにもなりません。

この二つは設計として補完的です。分かれ目は、何を気にするかです:

• OpenAB は ACP を仲介します — チャットから指示を送り、気にするのはエージェントが届けた結果で、その過程ではありません。あなたは指示する側で、セッションはターン制のリクエストとレスポンスです。
• openab-pty は PTY のモード — ネイティブなターミナルで、完全な可観測性を持ちます。気にするのはいま何が起きているかで、リアルタイムに見て、調べて、手を動かします。あなたはキーボードの前の操作者で、セッションは終わりのないバイトストリームです。

補完的であることは比喩ではなく構造です。PTY のイメージは FROM ghcr.io/openabdev/openab なので、シェルはエージェントが動いているのと同じイメージの中で開き、同じ CLI と同じワークスペースを持ちます。作業が途中で止まっていれば、その場で接続して見ます。どちらも他方を必要とせず、セッションモデルは意図的に何も共有しません — バイトストリームの生存はバイトとソケットで定義され、ターンでは定義されないからです。

詳しくは openab-pty の 設計ドキュメントにあります。そして OpenAB Connect は openab-pty クライアント契約の最初のクライアント実装です — 契約は公開されているので、資格情報を持てて WebSocket を話せるものなら、次の実装になれます。

意図的にほとんど何もできません。uid 1000 で開き、sudo なし、サービスアカウントトークンなし、ホストの資格情報なし、ルートファイルシステムは読み取り専用、ワークスペースは使い捨てです。セッションのシェルは loopback でランタイムに到達できます。だからこそ管理用の資格情報はコンテナの中に置きません。アタッチトークンが許可するのは 1 セッションだけで、期限もあります。

ありません。ランタイムは 127.0.0.1 にバインドし、TLS 鍵を持ちません。同じ pod の Tailscale サイドカーだけがネットワーク上の識別を持ち、両者は pod のネットワーク名前空間の中で loopback を通して会話します。通信は WireGuard の tailnet を通って届き、暗号化はそこが担います。

何も届きません。ここにサービスはありません。アプリが接続する先はすべて、あなたが自分のクラスタか自分の AWS アカウントにデプロイしたものです。アカウント登録も、解析も、テレメトリもありません。入力した資格情報は macOS のキーチェーンに留まり、あなた自身のランタイム以外へは送信されません。

できます。ランタイムは MIT ライセンスで openabdev/openab-pty にあり、クライアント契約も公開しているので、このアプリを使わずに自分のクライアントを書くこともできます。このアプリはその契約の一実装で、オープンソースではありません。

試せます。アプリメニューの Demo Mode は、サンプル接続 2 つと収録済みのターミナルだけで動き、ネットワーク接続は一切行いません。何もデプロイする前に評価できるようにするためのものです。

3 クリックのあと、8 つの手順が走ります。資格情報を生成してキーチェーンに保存し、namespace を確認し、secret とボリュームを作成し、pod を適用し、起動を待ち、tailnet への参加を待ち、管理プレーンを検証します。マニフェストを書く必要はありません。あるイメージの初回デプロイは、クラスタがそれを取得するため数分かかることがあります。

ワークスペースは破棄されます。ここは確実です。そのセッションのためだけに存在し、セッションを削除すれば消えます。

確実でないのはプロセスです。セッションを削除するとそのセッションのプロセスグループは終了しますが、意図的にそのグループを離れたプロセス — nohup や setsid で起動したバックグラウンドジョブなど — は、pod や task が置き換わるまで生き残ることがあります。同じサンドボックスの中に閉じたままで、新たに何かへ手が届くわけではありませんが、その pod の CPU とメモリを使い続けます。

そのためアプリでは、きれいに終了したとは言わず best-effort と明示しています。何も残らないことを確実にするなら、pod か task を削除してください。

まだできません — 現在開発中です。今日は各セッションが独立していて、あなたが個々のエージェントに指示を出し、エージェント同士が仕事を委譲することはありません。

設計は公開されています。OpenAB の Agent Control Plane ADR に基づくもので、チャットプラットフォームを経由せず ACP over WebSocket でエージェントが直接委譲できるようにする、ハブ&スポーク型の登録・ルーティングサービスです。チャット経由はレート制限と遅延を招き、人間のためのチャンネルにオーケストレーションのノイズを流し込みます。構成は三つ:誰が生きていてどのラベルを持つかの Registry、名前／ラベル／namespace で振り分ける Router、委譲の深さ・循環・namespace・allowlist を扱う Policy です。

その設計のひとつはこのアプリの考え方と一致します。エージェントは制御プレーンへ外向きに接続するので、ネットワークをまたいで動かすのに、どちら側にも受信ポートは要りません。

ADR はマージ済みで、実装はまだ出荷していません。参加を歓迎します — 議論はあの文書から始まります。