クラウド上のエージェントは、リクエストやワーカー、コンテナ、デプロイメントより長く生き続ける。ユーザーが翌日戻ってきて別のワーカー上で続きを始めるためには、プロセスから独立した進行状態が必要である。しかも「完了済み操作の結果」と「次に何をするかを決める制御フロー状態」の両方が欠かせない。この記事の個人ローン審査エージェントは、証拠収集、ポリシー適用、AIレコメンド、人間の審査という一連の流れを持ち、どの段階でワーカーが落ちてもよいように設計されている。
Temporalでは、Workflowが1エージェント実行の耐久性のある制御フローを表し、Activityはモデル・ツール・DBへの呼び出しで結果はEvent Historyに保存される。審査者の決定はSignalとして実行中Workflowへ送られる。失敗後は新しいワーカーがイベント履歴をリプレイして状態を再構築し、記録済みのActivity結果は再実行されない。逆に完了未記録のモデル呼び出しは、実際にプロバイダ側で処理済みでも再試行され得るため、Activityごとにリトライポリシーを設定している。
Lakebase Postgresは実行状態の「アプリ向けビュー」を提供する。agent_opsスキーマには実行ステータス、メッセージ、ツール呼び出し、審査記録、イベント、メトリクスが入り、FastAPIはSQLでこれらを照会する。agent_policyはUnity Catalog由来の読み取り専用ポリシーテーブルだ。Temporalのイベント履歴とLakebaseの書き込みの間にはトランザクションがないため、書き込みがコミットされた後にActivity完了報告が失われると、Temporalは同じ論理書き込みをもう一度スケジュールする。
この問題に対処するため、参考実装ではrun_idやtool_call_id、review_idなどの決定論的IDを主キー・一意制約に使い、同じIDに対するupsertやガード付き更新で状態遷移を制御する。たとえば開始状態へ戻す書き込みは、既存行が終端状態でない場合だけ成功し、すでにsucceeded/failedなら更新行数は0になる。エラーにはならず、呼び出し側が影響行数を確認して期待されたno-opか競合かを判断する必要がある。この「外部副作用をリトライ可能にする契約」は、すべてのツールで求められる。
全体の構成は、React+FastAPIがAPI/UIを担当し、Temporal Cloudがイベント履歴とタスク分散を担い、ワーカーがリプレイと各種Activityを実行する。Unity Catalogのポリシーは継続同期テーブルでLakebaseに公開され、活動中にポリシーが更新されてもコードデプロイなしで利用できる。Change Data Feedを有効にすると、エージェントの証跡や判断がUnity Catalog管理のDelta履歴テーブルへ公開され、監査と分析に使える。これにより、人間の審査を数日待つようなワークロードでも、回復性と運用監視、ガバナンスを両立できる。