Agent Card

ウォレットは、プロダクトに組み込んでエージェント決済を有効にするウィジェットだ。2種類のカードを収める。1つはユーザーが既に持つカードをつなぐもの、もう1つは新しいAgentcardを発行するもの。肝は、アプリもエージェントも本物のカード番号を見ないこと。漏れるものがない。

Connectはユーザーが既に持つクレジットカードとデビットカードを受け付ける。購入はすべて本人の口座で処理され、特典は積み上がり続ける。オンボーディングはメールのコードで完了する。カードは数秒で使える。カード情報はAgentcardの安全な保管庫にあり、実際に支払いが起きるときだけ共有される。

Issueは数秒で新しいAgentcardを作る。エージェントはVisaが使える場所ならどこでも支払える。カードは1回の購入向けの単発か、サブスクなど向けの支出上限付き多目的か。どのカードも1つの店と1つの金額に固定されるので、番号が漏れても他には何も買えない。

エージェントカードは自前のガードレールを持つ。上限はカードごとに設定し、店に紐づける。エージェントがいくら、どこで使えるかを事前に決められる。自律的な購入に綱をつけるイメージだ。この仕組みが、取引ごとに人が承認を押さなくても支払いを走らせる。

自前のブラウザ自動化を組み、Agentcardで支払いを完了させることも、Agentcardの購入APIとその連携を使うこともできる。後者は会社が毎月追加している。どちらが合うか迷うなら、多くのチームはAPIから始める。2つのルートがあれば、既存のエージェント構成を全面的に作り直さずにつなげられる。

開発者は購入ごとに1%を得て、さらにダッシュボードで設定した上乗せも得る。単なるコスト部門ではなく収益の柱であり、エージェント製品を大量に運用するチームには効く。小銭ではなく本物の金だ。

発行したカードは、請求を1枚のインボイスにまとめる前払いの会社残高からか、Apple PayやGoogle Payで入金したユーザー残高から引き落とされる。自前の会計フローを求める会社は前者、ユーザーに資金を持たせたいチームは後者を選ぶ。

ウォレットはiMessageエージェント、エージェントブラウザ、ホスティングサービスを狙い、会社は10分未満で実装できるとしている。なぜこの速さが効くのか。支払いの一手は、動くエージェントを最後に止める部分になりがちだからだ。つないでしまえば、エージェントは中途半端なタスクを残さなくなる。