動いている最中に話しかける：私たちのエージェントが割り込みを受け付ける理由

早期テスターの1人が長いタスクを進めている最中に、何も停止せずにチャットに 修正を打ち込みました。後で彼女は、その瞬間が意外なほど心地よかったと話して くれました：彼女が使っている別のエージェントツールは、新しいメッセージを 受け付ける前にまず実行を停止させるからです。「話しかけるためだけに 止めなきゃいけないのはバカらしい」と彼女は言いました、「これに比べると」。

彼女は正しい。そしてこの違いは、小さなUX上の気配りではありません。それは 私たちが早い段階で下し、繰り返し適用し続けている設計上の決定から来て います：エージェントは同僚であり、機械ではありません。 あなたは同僚に文の途中で割り込み、同僚はそれを会話に織り込みます。 電源を入れ直したりはしません。

なぜ「まず停止」が間違ったデフォルトなのか

話す前に実行を停止させることには3つのコストがあり、すべてがユーザーに のしかかります：

• 修正が遅すぎる。エージェントが脱線し始めたことに気づく 瞬間こそ、話すべきときです。停止を強いるということは、停止ボタンを 探している間、間違った道で時間とトークンを燃やすのを見ていることを 意味します。
• 停止は状態を破壊する。停止した実行は再開されません — 最初からやり直すか、さらに悪いことに「キャンセル済み」の残骸を受け取って コンテキストを説明し直すかです。途中での軌道修正の代償が、進行中の 作業全体です。
• 主従が逆転する。「今は機械に聞こえていません、後で出直して ください」は、あなたの都合ではなく機械の都合です。

私たちの実際の仕組み

実行中にメッセージを送ると、3つのことが順番に起こります：

1. あなたの言葉がまず保存される。メッセージは何かが ディスパッチされる前に、即座に会話履歴に入ります。あなたの意図は その瞬間から永続的です — キューも、バッファも、タイミングも、それを 失わせることはできません。
2. 次のステップ境界で届く。エージェントはツール呼び出しの 途中で持っているものを落としません — 人が考えを言い終えてからあなたの 指摘を受け取るように、次の自然な区切りであなたのメッセージを読みます。
3. 再起動ではなく、舵を切る。実行がすでに行ったすべては そのまま残ります。あなたのメッセージはリブートではなく、動いている タスクへの軌道修正です。

根底にある原則：ユーザー意図の永続性は、システムの都合に優先します。 言葉が保存されてしまえば、下流にあるすべてはタイミングの問題です — そして タイミングは優雅にできます。保存されなかった意図は、二度と回復できません。

実際にはどう見えるか

最も分かりやすい例はすでに公開されています。時計の話では、 創業者のリクエストがエージェントの作業中に2回方向転換しました — 「やっぱりHTML版にして」、そして「インストールできるWebアプリみたいに パッケージ化して」。それぞれの割り込みは実行中に届き、軌道を曲げました。 誰も停止を押しませんでした。出荷されたアプリは、飛行中に届いた修正に よって形作られました。

もっと地味な日常版は、退屈ですがもっと価値があります：リサーチタスクで 10通目のメッセージあたり、エージェントが間違った比較を組み立てているのに 気づき、「代わりにXと比較して」と打つ — そしてすでに集めた8つの良い ソースを失うことなく、向きを変えるのを見ます。

原則は波及する

今週、私たちは同じ問いを反対側から突きつけられました：私たちが あなたに割り込む場合 — デプロイのためのサーバー再起動 — はどうなるのか？ 正直な答えは、同じルールでした。デプロイ中、サーバーは実行中の注入を 受け付けるようになりました（あなたの保存された言葉は生き残り、次の実行が コンテキストで引き継ぎます）。一時停止するのは新しい実行の開始だけです。 ユーザーがすでに入力したものを拒否することは、私たちの都合があなたの意図を 上書きすることになります — 上で批判したのとまったく同じ逆転を、運用の衣を 着てやるだけです。

これが新しいとは主張しません — キューイングされた割り込みは、良いシステムが 昔から動いてきた方法です。ただエージェントUXでは珍しいだけです — そこでは 「話しかけるために機械を止める」がなぜか標準になってしまいました。退屈で 正しいデフォルトになれることを、私たちは嬉しく思います。