Nathan FlurryのRivet、AI agentの状態をActorsへ分解した転換

Nathan Flurryが関わるRivet Actorsの公式READMEは「Rivet Actors are the primitive for stateful workloads.」と説明する。出典

Rivetは、AI agentやsessionごとに状態を保持し、queue・workflow・WebSocketを同じ実行単位へまとめる方向から始まった。

stateless functionを呼ぶたびに文脈を再構成するのではなく、長時間動くActorとして状態を扱う。出典

その後、SQLite、self-hosting、Cloud pricing、agentOSへ広がり、ActorはAI agentだけでなくchat、collaboration、tenant databaseのprimitiveになった。

FreeからEnterprise On-Premまでの導入経路は、prototypeと規制環境を同じ概念でつなぐ。出典

2026年にはJavaScriptとPythonのagentOS Execution APIを公開し、agentが実行環境を使うための周辺まで扱い始めた。

Rivetの現在地は、単なるworkflow engineではない。

agentが状態を持ち、待ち、再開し、ユーザーと同期するためのruntimeを、開発者が一つのモデルで設計できるかという挑戦だ。出典

RivetのPMFは、AI agentやcollaborative appで、状態・queue・retry・realtime通信を別々に組み合わせる負担を減らしたい開発チームにある。

公式READMEは一つのActorにstate、storage、networkingを持たせる構成を示し、agentやsession単位の実行モデルを説明する。出典

stateless functionだけでは扱いにくい長時間処理を、active時だけ動くprocessとして扱える点が刺さる。

ただし、既存backendが十分に単純ならActorへの移行理由は弱い。

Actorのstate・networking・queue・workflowを同じruntimeで扱う実装知識と、AI agent・collaboration・dynamic appへ展開するSDK群がmoatになる。

OSSなのでcode単体の独占性は弱いが、運用面のintegrationsと開発者体験は蓄積する。出典

直接のnetwork effectは弱い。

利用者が増えても一つのActorの性能が自動で上がるわけではない。

一方、OSS contributors、SDK、integration、実装例が増えるほど、後続チームの導入コストが下がるecosystem効果はある。出典

AI agent、chat、共同編集、per-tenant databaseなど、長時間保持する状態とrealtime通信が必要なteam向けだ。出典

単発のHTTP API、厳密なSQL transaction中心の業務、すでにKubernetesとworkflow基盤を標準化した大企業には、移行コストの検証が要る。

第一に、stateful workloadという抽象化をagent、chat、collaboration、tenant databaseへ広げたこと。出典

第二に、Cloudとself-hostingの両方を用意し、prototypeからregulated deploymentまで導入経路を残したこと。

第三に、agentOSやSQLiteなど周辺機能をActorのlife cycleへ接続したことだ。出典 出典

Actorはstateの所有者、retry、region、永続化の境界を明示する必要があり、stateless APIより学習コストが高い。

in-memory state、SQLite、BYO databaseの選択は柔軟だが、障害復旧やmigrationの責任を消さない。出典

Cloud依存の可用性、self-hostingの運用負荷、価格と大規模性能の要検証が残る。

売上、ARR、調達額、従業員数は公式公開情報から要確認だ。出典

GitHub、quickstart、documentation、Discordを使ったdeveloper-led growthで、まずself-hostedまたはFree枠のprototypeへ入る。出典

stateful executionやactive coordinationが必要になったteamをHobby、Team、Enterpriseへ拡張する。

無料導入の広がりと、運用・SLAを有料化する境界が成長のトレードオフだ。出典

主要チャネル: github, documentation, community, developerLed, selfHosting

新しいinfrastructureの価値は、primitiveを増やすことではなく、state・通信・retry・scheduleの境界を同時に設計できることにある。

RivetのActorはagentやtenantという自然な単位へ技術を寄せ、開発者が複数サービスを接着する作業を減らす。出典

一方で抽象化は責任を消さない。

導入前にstate ownership、障害時の再実行、region、データ保持を決めることが本番化の条件になる。

日本では、社内agent、顧客workspace、ゲームやchatのrealtime backendから試すのがよい。

データ所在地、監査ログ、self-hostingとCloudの責任分界を日本語runbookで示し、security reviewを先に通す導入が現実的だ。