AIエージェントが承認を求め、完了を報告し、新しい作業を受け取り、現在のプロセスが終了した後もthreadを継続する場合、メールとメッセージングはバックエンド・インフラになります。チャネルには、安定したID、配信状態、ワークフローとの相関、再試行ルール、監査記録が必要です。
ユーザーが操作中ならアプリ内通知が機能します。閉じたタブやアイドル状態のエージェントを越えて引き継ぐ必要がある場合は、メールが役立ちます。
通信基盤が担う4つの仕事
承認を求める
メッセージには、正確なアクション、リソース、スコープ、必要に応じてコスト、承認の失効期限を記載します。複数のリクエストが動いている場合、「yes」のような返信は安全ではありません。一つの操作IDに紐づく、署名済みの単一目的承認アクションを使います。
完了または失敗を報告する
エージェントの思考過程を流し続けるのではなく、人間が必要とする結果を送ります。ワークフローID、最終状態、関連する成果物またはURL、次のアクションを含めます。ログへのリンクは、受信者に閲覧権限がある場合だけ掲載します。
新しい作業を受け取る
専用inboxは受信メールをエージェントのタスクへ変換できます。システムには、送信者の検証、添付ファイルの制限、threadのID、prompt injectionへの対処、受信と実行の間のqueueが必要です。メールを受信しただけで、送信者にツール実行権限を与えてはいけません。
システムを連携させる
構造化された配信と再試行が必要なmachine-to-machineイベントには、メールよりwebhookが適しています。人間が読んだり返信したりする必要がある場合は、引き続きメールが役立ちます。両方を必要とするワークフローもあります。webhookがシステム状態を更新し、メールが人間へ判断を求めます。
AIエージェント・インフラストラクチャのガイドでは、これらのチャネルをUIの装飾ではなく、データベース、ツール、ID、実行環境と並ぶものとして扱っています。
引き継ぎに応じてチャネルを選ぶ
| ニーズ | 推奨される初期選択 | 理由 |
|---|---|---|
| 表示中のセッションを更新 | アプリ内イベント | 低レイテンシで、既存のユーザーコンテキストを利用できる |
| 不在の人へ通知 | メール | セッション終了後も残り、既知のアドレスへ届く |
| 構造化されたシステムイベントを配信 | webhook | 署名済みpayload、機械的な解析、再試行契約 |
| エージェントに会話を管理させる | 専用inbox | 安定したアドレス、thread、受信・送信履歴 |
| 重大な判断を求める | 署名済み承認ページと通知 | 同意を一つの正確なアクションに紐づける |
受信者が別のサービスで、厳密な配信が必要な場合、メールをqueueとして使わないでください。webhookまたはメッセージシステムを使い、人間向けの部分にだけメールを送ります。
単独inboxとバックエンド統合inbox
メールの読み取り、triage、返信が主な仕事のエージェントには、単独のエージェントメール製品が適しています。AgentMailは、エージェントinboxを中心に設計されたメールAPIの一例です。
データベース、ホスティング、認証、ストレージをすでに必要とし、メールは時折の通知や返信に使うアプリケーションには、バックエンド統合inboxが適しています。Cohesivity Inboxは、一つのテナントにアドレスを提供し、同じプロジェクトから送信、受信、一覧、読み取り、返信、削除を操作できます。一時テナントでは送信と宛先に厳しい制限があります。claimすると月間上限と任意のwebhookが利用可能になります。
この違いは運用上のものです。メール中心のエージェントには、専用製品の詳細な制御が役立ちます。プロダクト内のエージェントには、メールと他のバックエンドをまたいだ一つのIDとライフサイクルが役立つ場合があります。
メッセージ契約を設計する
すべての送信メッセージについて、次を記録します。
- テナント、ワークフロー、操作のID
- 宛先と送信元のID
- templateまたはメッセージのバージョン
- 利用可能な場合はプロバイダーのメッセージID
- 試行回数と最終配信状態
- メッセージが表す外部への効果
- 期待する返信または承認アクション
中断されたワークフローが同じ承認メールや完了メールを2回送らないよう、冪等性キーを使います。障害復旧ガイドでは、再試行前に結果不明の操作を照合する方法を説明しています。
受信内容を信頼しない
メールには、指示、リンク、添付ファイル、転送されたシークレット、別の送信者からの引用が含まれる可能性があります。データとしてparseし、本文でエージェントのポリシーやツール権限を上書きできないようにします。
送信者とthreadのIDは個別に検証します。添付ファイルの種類とサイズを制限し、生データを定義済みの保持ポリシーで保存します。受信メッセージから破壊的または金銭的なアクションを始める前に、改めて承認を求めます。
ユーザー不在時の引き継ぎをテストする
ワークフローが人間に最も大きく依存する地点で一時停止し、アプリケーションを閉じます。通知を配信し、リンクまたは返信経路をたどり、ワークフローが一度だけ再開することを確認します。次に同じ配信を繰り返し、アクションが重複しないことを確認します。
以下のプロンプトは、何も送信せず、実際のワークフローで不足している引き継ぎを見つけます。