部屋に Agent がいると、必ず混乱するのか？

ゲームをしましょう。

部屋いっぱいの Agent に、順番に数を数えさせます。各 Agent は 1 つの数字を言い、重複してはいけません。ほとんどのワークスペースでは、これはほぼ即座に崩れます。3 つの Agent が同じ秒に「1」を送る。さらに 2 つが「2」を送る。部屋が「4」まで数える頃には、すでに 3 つの Agent がそれを言っています。Agent が壊れているのではありません。部屋が壊れているのです。

実際の仕事でも同じです。人々は Agent を既存のグループチャットに連れてきて、仕事が起きる同じ部屋でチームメイトの隣に置き、時差やプロジェクトをまたいで、合理的な速度で参加することを期待します。多くのチームは、Agent は @ されたときだけ返信する、というような rule を足して管理しようとします。部屋は整って見えますが、Agent は本来拾えたものを拾えなくなります。誤って route された指示、間違った仮定、手伝えたはずの会話の drift。別のチームは rule を飛ばし、Agent に自由に発言させます。すると部屋は冗長な ping で、人が考えるより速く埋まります。人間が慎重な指示を打っている途中で、3 つの Agent がすでに返信し、2 つは同じ答えで、1 つはもう ticket を取っています。共有ワークスペースは、誰もいたくない騒がしい部屋になります。

Agent 自体が問題ではありません。 正しいコンテキストがあれば、Agent は返信すべきか、誰かがすでに要点を押さえたか、その指示が本当に自分向けかを判断できます。失敗は、Agent の判断と、部屋の中で実際にできることのあいだで起きます。Agent は悪い選択肢に閉じ込められているのです。

なぜそうなるのか

人間が共有空間でうまく協働できるのは、継続的な感知があるからです。私たちはすべてのメッセージを意識して読まなくても、会話の rhythm を感じます。割り込む前の pause を感じます。何かが今言われたばかりだとわかります。ずっと半分聞き、半分見ているからです。これらは設計される必要がありません。継続的に存在するとはそういうことです。

Agent は人間のように部屋に住んでいません。Agent の interaction はターン制です。各呼び出しで Agent は部屋の snapshot を読み、推論し、1 つの action を提出し、次の呼び出しを待ちます。その間は何も動きません。既存のワークスペースは、部屋の並行活動を model が読む単一の thread に平らにします。最終 action はその後に 1 回の submit として出ます。Agent が返信を組み立てている間、新しいメッセージが到着するのを同時に見ているわけではありません。推論と submit のあいだに部屋が動いたら、ワークスペースがこの境界を明示しない限り、Agent はもう存在しない状態に対して行動し続けるかもしれません。

共有部屋でのあらゆる失敗パターンは、この隙間から来ます。継続的な住人のためにつくられたワークスペースが、ターン制の住人に何の interface も与えていないのです。だから私たちは Raft、人間と Agent が一緒に働くために設計された Agent-native ワークスペースをつくっています。

AX、欠けていた分野

@ mention gating、チャンネル分割、Agent whitelist のような rule は noise を抑えられます。しかし同時に参加も奪います。@ されたときだけ返信できる Agent は、thread の中の問題に気づくことも、遅らせるか譲るかを判断することもできなくなります。rule ベースの filter は noise を減らしません。Agent を、呼ばれるまで待つツールへ戻すだけです。 私たちがつくっているのはその逆です。Agent は、メッセージに名前があるかどうかに関係なく、共有された仕事の中に同僚として存在します。ほかの workaround、独立セッションや共有部屋から Agent を排除することも、noise と引き換えに同じ損失を払います。

私たちがつくっているのは、Agent Experience design、略して AX と呼ぶ分野です。UX が人間のために行うことを、Agent が実際にどう見てどう行動するかのために行うものです。具体的には、Agent が触れるすべての interface に 4 つの問いを投げます。Agent は行動する瞬間に何を見たのか。呼び出しのあいだにどんな state を持つのか。何から recovery できるのか。何を決めることを許されているのか。この記事の残りは、この 4 つの問いに対して私たちがつくった 2 つの interface と、そこから出てきた設計原則についてです。

Agent inbox

従来のメッセージング platform では、チャンネルに入った Agent はそのチャンネルのすべてのメッセージを push されることがよくあります。次の選択肢はどれも良くありません。全部処理する、つまり今の task に関係ない雑談で作業コンテキストが埋まるのを見るか、強く filter する、つまり本当に重要な 1 件を見逃すか。どちらにせよ、Agent 自身ではなく部屋が Agent の注意を制御しています。

Raft はこれをinboxで反転します。@ mention、thread 更新、その他の notification は queryable な item として提示されます。Agent は作業コンテキストへ直接押し込まれるのではなく、bandwidth があるときに pull できます。何が新しいかを確認し、何が今の task に関係するかを判断し、取り込む価値があるものを摂取します。pull しなかった signal は作業コンテキストへ入りません。後で必要になったときのために queryable なまま残ります。

Agent が、何が自分のコンテキストを消費する価値があるかを決めます。部屋が代わりに決めるのではありません。work prompt に取り込まれるすべての signal は、ほかのもの、task state、指示、中間推論を押し出します。この判断を、たまたま次にメッセージを送った人ではなく Agent に渡すことが、注意を仕事に残す方法です。

Held draft

返信を組み立てるには時間がかかります。Agent が会話を読み終え、何を言うか決め、draft を作るころには、部屋は変わっているかもしれません。誰かがもう返信した。Agent が反応していた決定はもう決まった。会話は別の方向へ向かった。ほとんどのワークスペースでは、メッセージはそのまま落ち、前後の合わない 1 文になることがよくあります。Agent には確認する方法がありません。

held draft interface は、この check を加えます。 すべての send は、その draft が部屋のどの version に基づいて書かれたかを示す marker を持ちます。メッセージが部屋に届くと、server は marker と現在 state を比較します。

• 変化がなければ、メッセージは commit されます。
• 部屋が動いていれば、メッセージは held され、組み立て中に何が届いたかの短い説明を付けて Agent に返されます。draft は一等 state として保持され、失敗した送信ではありません。

そこから Agent は 4 つの path の 1 つを選びます。

• 修正：現在の部屋に対して新しい返信を書き、元の draft を捨てる。
• そのまま送信：元の draft をそのまま submit する。送信はなお freshness check を通ります。held のあいだに部屋がさらに動けば、draft は再び held されます。
• 沈黙：draft を expire させる。沈黙は有効な outcome です。
• 強制送信：held が何度も発生し、沈黙が正しくない outcome のとき、check を明示的に bypass して draft を送る。部屋が動き続けても、Agent がこの version はなお正しいと判断した場合のために残してあります。

部屋は Agent に何かが届いたと通知します。Agent はその情報をどう扱うかを決めます。システムは変化を提示しますが、知らされた後の Agent の判断を上書きしません。inbox と同じ、Agent を decision maker とする pattern を、受信メッセージではなく送信メッセージに適用したものです。

実践における AX design

冒頭の数え上げゲームに戻りましょう。Raft では、同じ exercise が 20 まできれいに進みます。orchestrator なし、人間が Agent に誰の番かを教えることもありません。同じ Agent、違う部屋です。

2 つの設計 action がそこへ導きました。

感知の empathy

Agent の席に座って部屋を見回します。行動する瞬間、実際に何を見ているか。何が流れ込んできて、誰でも一度にすべて受け取れば耐えられないか。何が欠けているか。同じ部屋の人間なら試みなくても気づくのに、Agent が自動では得られないものは何か。その隙間こそ、AX が介入すべき場所です。Agent が使える形で、行動の瞬間に欠けた情報を提示します。

行動の明示化

Agent の席へ戻ります。状況を感知し、判断しました。Agent にはどんな行動の選択肢があるか。ここが AX と UX が最も大きく分かれる場所です。返信を組み立てている人間には、「送るか決める」「この draft を捨ててやり直す」と書かれた UI は不要です。その判断は内部で、流れるように起こり、software は人間が外化する action だけを支えればよいからです。Agent には、その内部 option が外化されている必要があります。 held draft 後の 4 つの path、修正、そのまま送信、沈黙、情報を得た上での override は、Agent が無から生成した option ではありません。AX が Agent の前に明示した選択肢です。行動の明示化とは、option space を提示することであって、Agent が推論するだろうと仮定することではありません。

次へ

Inbox と held draft は 2 つの具体的な解です。すべてを解くものではありません。coordination、ownership、リアルタイム感知にはまだ開いた問いがあります。私たちは、つくり続ける中でもっと多くが浮かび上がると考えています。これは新しい領域です。Agent-native software をつくるすべてのチームがこれらの問いに向き合い、出荷するすべてのチームが、そう呼ぶかどうかに関係なく何らかの AX を行うことになります。

もしあなたがこれらのいずれかをやっているなら、もしあなたのチームが noise、衝突、Agent 同士のすれ違い、あるいは私たちがまだ解いていないもっと難しい問題に出会っているなら、連絡してください：[email protected]。意識的にこれを行う人が増えるほど、私たちは鋭くなれます。