Perplexity Computer Email、誰でもエージェントタスクを依頼可能に。ただし信頼性が試金石に
Perplexityは、期間限定の無料トライアル中、アカウントを持たない人にもメール経由でComputerエージェントを開放した。CEOのAravind Srinivas氏によると、誰でもメッセージを転送するか、computer@perplexity.comをCCに入れることで作業を委任できるという。この発表により、Perplexity Computer emailの利用対象は、同社の従来のドキュメントで対象とされていた登録ユーザーを超えて広がる。
このエージェントは、メールスレッドをタスクの文脈として保持しながらバックグラウンドで動作する。報じられているところでは、各リクエストは同じWeb・モバイル表示、実行ステップ、監査証跡を備えた標準的なComputerセッションになる。ユーザーは別のアプリケーションを開かず、使い慣れた受信トレイから開始できる。
この利便性こそが中心的な緊張関係を生む。メールによってエージェントへの委任は日常的なものに感じられるかもしれないが、通常のメールは安全なコマンドインターフェースとして設計されたものではない。確立済みアカウントの外へアクセスが広がるなかで、送信者確認、権限、レビューの管理が引き続き信頼できることをPerplexityは示す必要がある。
この動きは、OpenAI、Google、Microsoft、その他のエージェント提供企業にも、業務依頼がすでに届いている場所での競争を迫る。競争の軸は、どのアシスタントが最も優れた回答をするかから、どのエージェントが最小限の摩擦で責任を引き受けられるかへ移りつつある。
Perplexity Computer Emailがアカウントの障壁を取り除く
重要な変化は、Computerがメールを受信できることではない。Perplexityが、誰でもアカウントなしでこの入口を使えるようになったと述べている点だ。
Computer in Email自体は完全に新しい機能ではない。Perplexityは2026年8月24日、既存のComputerユーザー向けにこの機能を発表した。このバージョンでは、ユーザーはメッセージの送信、会話の転送、または進行中のスレッドへのエージェントの追加を行えた。
10月の拡張はさらに踏み込んでいる。9月30日の公開投稿で、Srinivas氏はPerplexityアカウントを持たない人でもcomputer@perplexity.comを通じてタスクを委任できると述べた。また、これらのタスクは期間限定で無料になるとも説明した。
この新しいアクセス方針は、本記事のために確認した同社ドキュメントにはまだ記載されていない。公式の8月の資料では、依然としてこの機能はComputerユーザー向けと説明されている。したがって、アカウント不要への拡張は、十分に文書化された恒久方針ではなく、PerplexityのCEOによる展開に関する主張として扱うべきだ。
基本的な操作は意図的にシンプルに設計されている。新規メッセージに指示を書き込む、既存のスレッドを転送する、または会話にエージェントをCCで追加できる。メールの件名、本文、過去のメッセージ、添付ファイルがタスクの文脈を提供できる。
この設計により、受信トレイは軽量なジョブキューへと変わる。ユーザーは送信前に、依頼内容を正式なプロンプトとして組み立て直す必要がない。契約に関する議論、スプレッドシートのやり取り、リサーチ依頼には、エージェントに必要な情報の大半がすでに含まれている可能性がある。
Perplexityによると、各リクエストは完全なComputerセッションとして実行される。この違いは重要だ。システムは単にメール返信を生成するだけではない。手順を計画し、利用可能なツールを使い、成果物を作成し、元のスレッドを通じてファイルを返すことができる。
同社のメールワークフローでは、いくつかの例が紹介されている。アナリストは添付文書から財務モデルを依頼できる。弁護士は複数の改訂版にまたがる未解決事項の抽出を依頼できる。別のユーザーは、整理・書式設定済みのスプレッドシートを求められる。
これらの例は独立した性能テストではなく、あくまで同社によるデモンストレーションである。それでも、想定される範囲は明確になる。Perplexityはメールを、要約や返信案だけでなく、実質的な作業を開始するための手段にしたいと考えている。
セッションはComputerのWebおよびモバイルインターフェースからも引き続き利用できる。ユーザーは受信トレイの外で進行状況を確認し、実行された手順をレビューし、関連する監査記録を閲覧できる。メールスレッドは唯一の操作画面ではなく、入口として機能する。
この分離は長時間にわたる作業に有用だ。メールは委任と納品を担い、Computerインターフェースは作業の可視性を提供する。このモデルは、同僚にタスクを任せ、後から詳細を確認するためにプロジェクト記録を開くことに似ている。
アカウント不要という主張は、このモデルを複雑にする。既存のドキュメントによると、Computerは送信者を確認し、その人のコネクター、権限、Memoryを使用する。アカウントを持たない人には、こうした確立済みのリソースがあるとは限らない。
Perplexityは、新規ユーザーにおける本人確認、セッション所有権、保存、権限境界がどのように機能するのかを公には説明していない。アカウント不要のタスクが制限されたツールセットで動作するかどうかも不明だ。これらの詳細が、この拡張がどれほど重要なものになるかを左右する。
現時点で確認できる基盤はより限定的だ。Computerはメールのタスクを受け付け、スレッドの文脈を理解し、成果物を返し、通常のセッションを作成し、監査証跡を保持する。CEOの投稿は、重要だが文書化の少ない層を加えている。すなわち、オープンアクセスと一時的な無料実行だ。
メールがAIエージェントの配布レイヤーになりつつある
Perplexityが競っているのは、誰かがAIアプリケーションを開く瞬間だけでなく、誰かが仕事を委ねると決める瞬間だ。
職場での依頼の大半は、すでに限られたチャネルを通じて届く。メール、メッセージングプラットフォーム、会議、チケッティングシステム、共有ドキュメントだ。各依頼を別個のAIインターフェースへ移すよう求めることは摩擦を生み、多くの場合で文脈も失わせる。
Perplexityのメールエージェントは、この二つの問題に対応する。転送によって元の会話を保持し、エージェントをCCに入れることで、依頼を議論している人々の近くに置ける。ユーザーは別の製品内で履歴を手作業で再構築することなく、作業を委任できる。
これは重要だ。エージェント製品には技術的能力以上のものが必要になる。繰り返し使える入口が必要だ。利用者がその所在を覚え、開き、資料を集め、仕事を改めて説明しなければならない場合、能力あるシステムであっても使われないままになり得る。
メールは例外的な到達範囲を持つ。企業、デバイス、ソフトウェア環境をまたいで機能する。また、添付ファイル、タイムスタンプ、参加者、引用履歴、誰が何を依頼したかを示す認識しやすい記録も運ぶ。
こうした特性は、メールをエージェントのインターフェースとして魅力的にする。同時に、センシティブなものにもする。スレッドには、機密の財務情報、法的文書の草案、顧客情報、認証情報、社内の意見対立などが含まれる場合がある。
Perplexityの当初の設計は、確認済みの送信者にのみ返信することで露出を抑えようとしている。出力をすべての参加者に自動配信することはない。同社によると、エンタープライズユーザー向けのより広範な全員返信サポートは後日提供される予定だ。
この制約は、エージェントによる実行が通常のメール支援といかに異なるかを示している。文章作成アシスタントは人間が送るための文面を提案する。実行エージェントは接続されたシステムを参照し、ファイルを変換し、他の受信者がアクセスできない情報を扱う可能性がある。
送信者のみに返信する仕組みは、意図しない情報開示の経路を一つ減らす。しかし、それで認可に関するすべての問題が解決するわけではない。システムは、無害な文脈と、引用メッセージや添付ファイルに埋め込まれた指示とをなお区別する必要がある。
アカウント不要のプロモーションは、Perplexityの獲得戦略も変える。Computerは当初、より限定された層を対象としたプレミアム製品として立ち上げられた。メールは、最初のタスク前にオンボーディングを必要としないトライアルの仕組みを作り出す。
有用な結果自体がオンボーディングのきっかけになり得る。誰かが難しい依頼を転送し、成果物を受け取り、その後でより広範なComputerインターフェースに注目する価値があるかを判断する。これは通常のソフトウェアファネルを逆転させる。
期間限定の無料提供は、このアプローチを支える。最初のやり取りから支払いと登録の両方を取り除くからだ。しかしPerplexityは、対象となるタスク数、プロモーション終了時期、含まれる機能を明らかにしていない。
こうした未公表の条件は、ユーザーと競合他社にとって重要だ。無制限のトライアルであれば、高コストな複数ステップの作業を補助することになる。厳しく制限されたトライアルであれば、メールで提供される製品デモに近いものとなる。
Perplexityはまた、オーケストレーションモデルを示す機会も得る。Computerは、専門モデルとサブエージェントに作業を分配するエージェントとして登場した。その価値は、こうしたリソースを完成した出力へと調整することにかかっている。
立ち上げ時、PerplexityはComputerが19のモデルを利用できると述べた。同社の後続資料では、拡大するモデルセットと定期的なワークフローが説明されている。統合やモデル選択の変化に伴い、正確な利用可能性は変動し得る。
メールはその複雑さを隠す。ユーザーは各ステップでモデルを選択したり、各サブタスクを監督したりする必要がない。エージェントは成果志向の依頼を受け取り、舞台裏でワークフローを管理する。
これが製品としての賭けだ。Perplexityは、基盤となるモデルが他社提供であっても、調整には価値を持たせられると考えている。インターフェース、文脈処理、ルーティング、コネクター、メモリー、監査記録が差別化されたシステムとなる。
受信トレイからの入口は、この提案を試しやすくする。同時に、人への業務委任とエージェントを比較しやすくもする。ユーザーは、結果が完全な形で、時間どおりに、使える形式で届くかどうかを判断するだろう。
真の競争は、別のアプリなしで委任できることにある
Perplexityの主要な相手は一社ではない。エージェントが働く前に、ユーザーがAIの目的地を訪れなければならないというアプリ中心の前提だ。
OpenAI、Google、Microsoft、Anthropic、そして多数のスタートアップが、リサーチ、コーディング、ブラウジング、職場ツールとの連携を行うシステムを構築している。製品には違いがあるものの、多くはいまだ専用のチャットまたはエージェントインターフェースの中から始まる。
Perplexityは、タスクがすでに存在するコミュニケーションチャネルへComputerを近づけている。メールより前には、SlackとMicrosoft Teams向けのComputer入口を導入していた。受信トレイはこの戦略を、単一のコラボレーションプラットフォームの外へ拡張する。
この経路は、Perplexityに実用的な配布上の優位性を与える。転送されたメッセージは、新しいワークスペースより行動変容が少なくて済む。また、本来なら急ごしらえのプロンプトに縮小されかねない会話履歴も保持できる。
このアプローチは、人間の専門家が依頼を受け取る方法に似ている。人は背景資料をアナリストに転送し、必要な出力を伝え、返信を待てる。Computerは同じ業務上の位置を占めようとしている。
ただし、ソフトウェアへの委任は人間への委任と重要な点で異なる。同僚は、社内政治、曖昧な同意、疑わしい指示を認識できる。エージェントは、セキュリティ制御が介入しない限り、直近の命令を文字どおりに解釈する可能性がある。
そのため、監査証跡は装飾的なものではなく中心的な要素となる。ユーザーは、エージェントがどの情報にアクセスし、どのような手順を実行し、どのように成果物を作成したのかを知る必要がある。追跡可能性のない結果は、重要な業務では信頼しにくい。
Perplexityは、メールのタスクがWeb上で開始されたセッションと同じ手順および監査履歴を保持すると述べている。これにより一貫したレビュー画面が提供される。また、実行記録全体を扱いにくいメール返信へ押し込める必要もなくなる。
アプリがなくなるわけではない。その役割が変わる。必須の開始地点ではなく、確認、介入、より深い管理を行う場所になる。
このハイブリッド設計は、すべてのインターフェースをメールに置き換えるよりも説得力がある。受信トレイは依頼を受け取り、成果物を返す用途には適している。一方で、並行するサブタスクの監視、権限の見直し、障害の診断には向かない。
Perplexityにとっての課題は、これらの画面間の移行を分かりやすくすることだ。アカウント保有者はリンクをたどり、認証済みセッションへ入れる。アカウントを持たない新規ユーザーには、明確な所有権確認と検証のプロセスが必要になる。
同社はこの導線を詳細には文書化していない。受信者はメールアドレスの確認、一時セッションの作成、あるいは最終的な登録を求められる可能性がある。どの選択肢も、製品が実際にどれほど摩擦なく使えるかを左右する。
競合他社は目に見えるインタラクションを模倣できる。エージェントを起動するメールアドレスは、再現が難しい概念ではない。より深い競争は、コンテキスト、権限、実行品質、運用上の信頼性をめぐるものだ。
Microsoftは、Outlook、Teams、Microsoft 365、エンタープライズのアイデンティティシステムがすでに管理機能を共有しているため、自然な優位性を持つ。GoogleもGmailとWorkspace全体で同様の強みを持つ。両社はエージェントを組織データの近くに配置できる。
OpenAIとAnthropicは、モデル品質、エンタープライズ統合、開発者エコシステム、エージェントプラットフォームを通じて競争できる。したがってPerplexityは、自社のオーケストレーション層が単一プロバイダーのアシスタントよりも優れた完成成果物を生み出すことを証明しなければならない。
この圧力が、完成済みの成果物への注力を説明する。検索回答だけでは、もはや防御可能なカテゴリーを確立できない。エージェントは、スプレッドシート、レポート、プレゼンテーション、データセット、あるいは業務を前進させるその他の成果物を返す必要がある。
独立した裏付けは依然として限られている。2月のローンチ評価では、Perplexityが製品上の不具合を発見した後、予定していたメディア向けデモを中止したと指摘された。同誌は独自のハンズオンテストを完了していなかった。
この出来事は現在の品質を示すものではない。ただし、アクセス拡大が戦略的に重要である理由は示している。より多くのユーザーと実際の業務が、統制されたデモでは得られない証拠を提供できる。
したがって、アカウント不要の試用には二つの目的がある。製品を広く配布すること、そして信頼性をより広い範囲で検証することだ。Perplexityは、Computerが入念に準備された例の外で、不完全な職場の依頼を解釈できるかを学ぶことになる。
ユーザーにとって、評価は成果中心であるべきだ。システムは依頼を理解し、適切なコンテキストを使い、機密性を保ち、レビュー可能な成果物を作成したか。利便性が意味を持つのは、こうした条件が満たされる場合に限られる。
より容易な委任がセキュリティ境界を広げる
メールはエージェント利用への障壁を下げる一方で、重要な行動を実行できるツールに、信頼できないコンテンツを近づけることにもなる。
メールスレッドには複数の発言者が含まれる。引用文、転送された指示、署名、外部リンク、添付文書、そしてエージェントに指示する意図などなかった人々が書いた内容が含まれる場合もある。
この混在はプロンプトインジェクションのリスクを生む。プロンプトインジェクションとは、信頼できないコンテンツに、AIシステムを本来の目的から逸らすよう設計された指示が含まれることを指す。エージェントはユーザーの依頼と、読み取る資料の中に隠された命令を区別しなければならない。
転送された文書が、タスクを無視して別の情報を開示するようエージェントに指示する可能性がある。調査中に開いたWebページにも同様の指示が含まれるかもしれない。Computerが追加される前に、悪意ある参加者が意図的にそのような文面をスレッドに入れることもできる。
送信者の検証は、この問題の一部しか解決しない。誰がタスクを開始したかの確認には役立つが、スレッド内のすべての要素を信頼できるものにはしない。システムには依然として、データアクセスとツール利用を囲む境界が必要だ。
権限は別の複雑さを生む。Perplexityの当初のメール向けドキュメントでは、タスクは送信者のコネクターとアクセス権を使うとされている。そのアイデンティティがあらかじめ設定済みであれば、既存のアイデンティティに沿った実行を維持できる。
アカウント不要版には明確な同等機能がない。新しい送信者には、接続済みアプリケーション、保存済みメモリ、組織ポリシーがない可能性がある。Perplexityはセッションをメールと添付ファイルに限定できるが、その設計を公に確認してはいない。
制限された環境はリスクを下げる一方、実用性を狭める。エージェントは文書を要約し、公開情報を調査し、ファイルを作成できるが、社内アプリケーションを必要とするワークフローは完了できない。
より広いアクセスは価値を高めると同時に、リスクも大きくする。ユーザーがクラウドストレージ、メッセージング、業務ソフトウェアを接続する場合、システムはメールによって送信者の意図を超える行動が引き起こされないよう防ぐ必要がある。
この緊張関係はPerplexityに限ったものではない。エージェント業界全体が同じ問題に直面している。役に立つエージェントには権限が必要だが、安全なシステムは権限を最小化すべきだ。この二つの目標は権限境界で交わる。
セキュリティ研究者は、最小権限を、特定のタスクに必要なアクセスだけをシステムに与えることだと説明することが多い。自然言語の依頼では、必要なリソースをすべて事前に指定することがほとんどないため、この原則をエージェントに適用するのは難しい。
エージェントは途中で別のファイルやコネクターが必要だと判明するかもしれない。広範な常設アクセスを与えれば中断は避けられるが、ミスの影響は大きくなる。確認を求めれば制御は改善するが、自律的な実行は弱まる。
業界はサンドボックス、承認ゲート、ポリシーエンジン、監視レイヤーで対応している。最近のエージェントセキュリティの取り組みは、最小権限の実現がいかに難しいかを浮き彫りにしている。エージェントは有用であるために実際のリソースへアクセスしなければならないが、正しい境界を定義することは容易ではない。
Perplexityの監査証跡は、実行中および実行後に役立つ。セッションが取った手順を明らかにし、レビューのための証拠を提供できる。ただし、すべての行動が適切だったこと、あるいはすべての解釈が正しかったことを保証するものではない。
監査可能性と予防は異なる目的を果たす。ログはユーザーが何が起きたかを理解する助けになる。権限管理、隔離、確認は、そもそも何が起き得るかを制限する。
メールは同意をめぐる曖昧さも持ち込む。エージェントをスレッドに追加すると、他の参加者が書いたメッセージが公開される可能性がある。それらの参加者は、AIシステムが自分の文面や添付ファイルを処理することを知らないかもしれない。
組織は、従業員が会話を外部エージェントへ転送できる条件を定めるポリシーを必要とする。法務、金融、医療、カスタマーサポートのチームは、個人ユーザーより厳しい要件に直面する可能性がある。
送信者のみに返信するルールは、スレッド全体への自動的な情報開示を防ぐが、別のコミュニケーション上の問題を生む。他の参加者はエージェントが何を作成したか、あるいはその出力が後の意思決定に影響したことを把握できない場合がある。
エンタープライズ向けの全員返信サポートには、慎重な制御が求められる。システムはスレッド参加者、データ分類、変化するアクセス権を尊重しなければならない。また、権限のない受信者に機密の接続済みデータが届かないようにする必要もある。
無料プロモーション中であっても、コスト管理は別の不確実性として残る。複数ステップのエージェント作業は、大量のコンピューティングリソースを消費し得る。Perplexityはプロモーションの制限や、使い捨てメールアドレスによる悪用をどう防ぐかを開示していない。
レート制限、タスク複雑性の上限、添付ファイルの制限は、妥当な保護策になるだろう。同時に、それらは「誰でも」が実際に何を意味するかを形作る。Perplexityがルールを公表するまで、ユーザーは試用に境界があると考えるべきだ。
精度はより身近な問題をもたらす。洗練されたスプレッドシートやレポートにも、誤った前提、不完全な調査、捏造された詳細が含まれる可能性がある。完成した成果物はチャット回答より権威があるように見えがちで、レビューの必要性を高める。
ユーザーは、とりわけ法務、金融、医療、運用の場面で、Computerの出力を検証のために準備された作業として扱うべきだ。監査証跡はそのレビューを支援できるが、専門知識の代替にはならない。
妥当な最初のテストは、機密性のない情報を使った、元に戻せる依頼である。公開調査の整理、サンプルデータセットの整形、ユーザーが検証できる資料からの草案作成などが例に挙げられる。
このアプローチなら、重要なシステムへの即時アクセスを許可せずに実行品質を測定できる。また、Computerが不足情報、曖昧な指示、確認要求をどのように扱うかも明らかになる。
独自のレビュー手順を構築する人にとって、検索可能なAI knowledge baseは、生成された成果物の隣にソース資料を保存できる。目的は、エージェントの出力に検証が必要になった際にも証拠を利用可能に保つことだ。
Perplexityの主張が魅力的なのは、セットアップを不要にする点にある。未解決の問いは、同社が安全な委任における摩擦を取り除いたのか、それともその摩擦を目に見えにくい制御の中へ移しただけなのかだ。
メールによる委任が定着するかを示す三つのシグナル
次の試金石は、何人が一度Computerへメールするかではない。無料期間が終わった後、繰り返し行う仕事を任せるほど信頼されるかだ。
第一のシグナルは、アカウント不要アクセスに関する更新済みドキュメントだ。Perplexityは、新規送信者をどのように検証し、セッションを作成し、タスクデータを保存し、削除を処理するかを説明すべきである。また、接続済みアカウントなしで利用できるツールも定義すべきだ。
明確なドキュメントは、これが持続的な製品チャネルだという主張を強める。ソーシャル投稿への依存が続くなら、より限定的なプロモーション、または最終ルールが定まっていない実験を示唆するだろう。
同社は無料アクセスの境界も公表すべきだ。ユーザーは、制限がタスク数、所要時間、ファイルサイズ、計算量、ツール利用のどれに依存するのかを知る必要がある。明確な終了日があれば、将来の利用可能性をめぐる混乱を防げる。
第二のシグナルは、Perplexityが権限と敵対的コンテンツをどう扱うかだ。同社の既存の製品ノートは、既存ユーザー向けに送信者検証、接続済み権限、Memory、送信者のみへの返信を確認している。
新たな利用者層は、未解決のケースを生む。Perplexityは、未登録の送信者がWebセッションの所有権をどう得るのかを示す必要がある。また、転送された指示に異なる信頼レベルが与えられるかも説明しなければならない。
きめ細かな承認プロンプトとコネクター制限に注目したい。こうした制御があれば、Perplexityがメールを信頼できない入力チャネルとして扱っていることが示される。可視的な確認なしに広範な行動が可能であれば、信頼は損なわれる。
独立したセキュリティテストは、機能説明以上に重要になる。研究者は、引用文、添付ファイル、外部ページがタスクをリダイレクトできるかを検証すべきだ。また、出力が無関係なセッションの情報を露出しないかも試験する必要がある。
すべての失敗を排除できるエージェントプラットフォームはない。意味のある比較は、封じ込め、検知、復旧に関するものだ。高影響の行動を阻止し、有用なログを生成するシステムは、より強い運用モデルを提供する。
第三のシグナルは競合の反応だ。GoogleとMicrosoftは主要なメールプラットフォームを支配しており、OpenAIとAnthropicもすでに多くの職場ユーザーにサービスを提供している。いずれもエージェントへの委任を受信トレイのネイティブアクションにできる。
直接的な対応は、Perplexityのチャネル戦略を裏付ける一方、その基盤となる製品への圧力を高める。ネイティブプロバイダーは、外部のメール受信者よりも深く、アイデンティティ、管理、保持、権限を統合できる。
Perplexityはクロスプラットフォームの到達範囲で対抗できる。各プロバイダーによるインターフェース再設計を待たずに、単一のアドレスを多くのメールサービスから利用できる。この中立性は、ソフトウェア環境が混在するチームに訴求する可能性がある。
実行品質が、単なる中立性で十分かどうかを左右する。より良い結果を生み出し、より多くのツールをサポートし、より長いタスクを処理できるなら、ユーザーは外部ワークフローを受け入れるだろう。出力が同程度であれば、ネイティブの操作を選ぶはずだ。
継続的な利用は、最も明確な採用シグナルとなる。無料タスクを1回使うだけでは、好奇心を反映しているにすぎない可能性がある。繰り返し依頼されることは、ユーザーがエージェントの解釈、納品形式、タイミング、コンテキストの扱いを信頼していることを示す。
Perplexityは、いずれ総タスク量以上の根拠を示す必要がある。完了率、修正頻度、人間による介入、継続利用、セキュリティインシデントは、実用的な価値をより明確に示すだろう。
無料トライアルにより、同社は広範なテスト環境を得る。どのような依頼がメール経由で自然に届くのか、またユーザーがどこでワークフローを離脱するのかを観察できる。その情報は、将来のテンプレート、権限、コネクタの設計を導く可能性がある。
同時に、この製品はより雑然とした入力にもさらされる。実際のスレッドには、不完全な依頼、古い添付ファイル、意見の対立する参加者、明示されていない期待が含まれる。デジタル同僚として提示されるエージェントにとって、この混乱を扱えることは不可欠だ。
業界全体は、ユーザーが明示的なエージェントインターフェースと、目に見えない委任のどちらを好むかを注視すべきだ。専用アプリケーションは、制御性と充実した監視機能を提供する。コミュニケーションチャネルは、設定の手間を減らし、既存のコンテキストを維持する。
おそらく、どちらか一方のモデルが全面的に勝利することにはならない。ユーザーはメールやメッセージングツールでタスクを開始し、レビューが必要になった段階でアプリケーションへ移るかもしれない。Perplexity Computer emailは、すでにこのハイブリッド型のパターンに従っている。
このモデルは、引き継ぎが分かりやすいままであれば機能しうる。ユーザーは常に、エージェントがいつ開始したのか、どのアイデンティティを代表しているのか、どのリソースにアクセスできるのか、そしてどこで停止できるのかを把握できるべきだ。
Perplexityは、最初の操作を非常に簡単にした。スレッドを転送し、アドレスをコピーし、望む結果を説明する。困難な作業は、そのメッセージが送信トレイを離れた後に始まる。
Perplexityのメールエージェントは、権限、不確実性、リスクを隠すことなく、この身近な操作を信頼できる委任へと変えられるのだろうか。今後数か月で、ドキュメント、独立したテスト、そして繰り返される実利用を通じて答えが示されるはずだ。
