Databricks、TemporalとLakebaseで耐久性のあるエージェントを構築する方法を示すが、デモは難所も浮き彫りに

Databricksは9月8日、ワーカークラッシュ、リトライ、数日に及ぶレビューが発生しても、TemporalとLakebaseを用いて耐久性のあるエージェントを構築する方法を示すリファレンス実装を公開した。このシステムは個人向けローンの審査にこのアーキテクチャを適用しており、完了済みの確認項目を1つでも失うと、意思決定の証跡が損なわれかねない。

重要な変化は、新たなエージェントフレームワークやより大きなモデルではない。DatabricksとTemporalは、エージェントの状態を役割の異なる2つのシステムに分割している。Temporalは制御フローを保持し、Lakebaseはアプリケーション、レビュー担当者、アナリストが照会できる運用データを提供する。

この分割は同時に、中心的な緊張関係も生む。耐久性のある実行は記録済みの作業を復旧できるが、すべての外部作用を厳密に1回だけ実行できるわけではない。アプリケーションには依然として、安定した識別子、保護されたデータベース書き込み、ポリシーバージョンのルール、そしてコンポーネント間で不一致が生じた際の照合が必要となる。

Databricks、エージェントの耐久性をテスト可能なシステムへ

このリファレンス実装は、エージェントを一時的なチャットセッションではなく、長時間にわたるビジネスプロセスとして扱う。

リファレンス実装は、証拠収集から人間による判断まで、ローン申請を追跡する。そのエージェントは、信用情報、収入、債務返済比率、引受ポリシーの確認を、それぞれ独立した処理として実行する。

この例では申請者とデータプロバイダーをモック化しているため、実際のローン申請は処理しない。この選択により、融資モデルの性能ではなく実行時の挙動に実験の焦点を絞っている。

サンプル申請者の1人は、信用スコア665で、重大ではない延滞フラグが1件ある。エージェントは証拠を収集し、用途別のポリシー閾値を評価して、推奨内容を生成する。ただし、最終的な融資判断は下せない。

引受担当者は、承認、否認、または追加情報の要求を行わなければならない。最後の選択肢では、先行する証拠とレビュー担当者の判断理由を保持したまま、同じ案件を次のエージェントターンへ進める。

このシナリオは、単一のモデルリクエストより意図的に難しく設定されている。複数の確認が完了した後にワーカーが停止する可能性がある。データベース書き込みは、その完了がTemporalに届く前にコミットされる場合がある。レビュー担当者は案件を何日も開いたままにすることもある。

古いブラウザが、案件が先へ進んだ後に古いコマンドを送信することもある。その一方で、アプリケーションのデプロイを伴わずに引受ポリシーが変更される可能性もある。

こうした状況から、復旧、制御されたリトライ、永続的な待機、運用上の可視性、実行時ガバナンス、監査履歴という6つの実務要件が生じる。トランスクリプトだけでは、それらを満たせない。

トランスクリプトはメッセージを記録するが、完全な制御フローまで記録するとは限らない。どの処理が完了したか、どの結果が受け入れられたか、どのコマンドがプロセスを進めたかを自動的には示さない。

そこで実装では、各ローン実行にTemporal Workflowを割り当てる。Workflowは耐久性のある制御フローであり、記録された履歴によって別のワーカーでも状態を再構築できる。

モデル、データベース、引受ツールへの呼び出しはActivitiesとして実行される。Activityはリトライ可能な処理で、その結果はWorkflowのEvent Historyに記録できる。

レビュー担当者の応答はSignalsとして届く。これは開いているWorkflowへ非同期に配信されるコマンドである。Temporalは、数日間にわたってワーカープロセスを確保し続けることなく、この待機状態を保持できる。

ReactとFastAPIはユーザー向けアプリケーションを処理する。実行の開始、証拠の表示、案件一覧の提示、レビュー判断の送信を担う。Temporal Cloudは実行履歴を保存し、ワーカーへタスクを振り分ける。

Lakebase Postgresはアプリケーション向けの投影を保持する。投影とは、実行中に生成される更新から構築された、現在のWorkflow状態を照会可能な形で表現したものである。

Unity Catalogは引受ルールのソースであり続ける。継続的に同期されるテーブルによって、これらのルールはLakebase経由で利用可能となるため、ワーカーはコードをデプロイせずに更新済みポリシーを読み取れる。

このアーキテクチャにより、エージェントの障害時の挙動は可視化され、再現可能になる。耐久性を漠然とした約束から、具体的な復旧・整合性契約の集合へと変える。

ただし、このデモはそれらの契約を1つのデータベースに統合してはいない。TemporalとLakebaseは別々のシステムのままであり、その間の隔たりこそが、より難しいエンジニアリング上の問いを生む。

エージェントメモリは実行状態ではない

耐久性のあるエージェントには、保存されたメッセージや取得された記憶だけでなく、制御フローに関する記録済みの判断が必要である。

多くのエージェントシステムは、永続化をメモリとして説明する。会話を保存し、以前の文書を取得し、中間結果をデータベースに置く。こうした機能はモデルがコンテキストを取り戻す助けにはなるが、実行そのものを再構築するわけではない。

たとえば、ワーカーが信用情報チェックを完了した後に終了したとする。代替ワーカーは、その結果が記録されたか、再試行しても安全か、次にどの処理を実行すべきかを判断しなければならない。

これは制御フローの問題である。スケジュール済みのActivities、完了結果、タイマー、受理済みの人間によるコマンド、リトライ試行、現在のレビューラウンドが含まれる。

Temporalはこの情報を順序付けられたEvent Historyに保存する。リプレイ時、Workflowコードは記録されたイベントを消費し、証拠、トークン使用量、レビュー状態といった変数を再構築する。

記録済みのActivity結果は、再実行される代わりにリプレイ時に返される。したがって、完了済みの信用情報チェックや記録済みのモデル応答は、そのWorkflow実行において固定されたままとなる。

記録されていない完了は別のケースである。モデルプロバイダーは、ワーカーが接続を失う直前にリクエストの処理を完了するかもしれない。Temporalが結果を受け取らなければ、別の試行をスケジュールできる。

この制約は重要だ。モデル呼び出しには副作用がまったくないとは限らず、決定論的である保証もない。同一の入力でも、2回目の応答は1回目と異なる可能性がある。

このデモでは、個々の処理タイプにリトライポリシーを割り当てている。モデルActivitiesは、schedule-to-closeの3分間ウィンドウ内で最大4回の試行を許可する。

ツールActivitiesは、start-to-closeタイムアウト60秒で最大3回の試行を許可する。Lakebase Activitiesは、start-to-closeタイムアウト15秒で最大5回の試行を許可する。

これらの数値は、普遍的な本番環境のデフォルトではなく、あくまで例の設定を示すものだ。チームは、プロバイダーの挙動、レイテンシ目標、障害モード、下流への影響に応じてリトライ上限を設定する必要がある。

Temporalの耐久性のある実行モデルは、リプレイに必要な履歴を保持することでプロセス復旧に対応する。ただし、支払い、メール、データベース変更、モデルリクエストを自動的に安全に再実行可能にするわけではない。

各外部操作には冪等性契約が必要となる。冪等性とは、繰り返し試行しても重複した影響を生じさせず、意図した1つの結果へ収束することを意味する。

ローンデモは、決定論的な識別子によってこの契約を構築している。実行、メッセージ、ツール呼び出し、イベント、レビューラウンド、レビュー担当者の判断には、それぞれ安定したIDが付与される。

Postgresの主キーと一意制約により、リトライで無制限の複製が作られるのを防ぐ。Upsertにより、繰り返し試行は同一の論理行を対象にできる。

保護された更新処理が、さらに1層を加える。たとえば、保留中のツール呼び出しを、終了済みのレコードを再オープンせずに完了へ移行するなど、有効な状態遷移のみを許可する。

ただし、保護された更新であっても慎重な解釈が必要だ。PostgreSQLでは、対象がすでに終了状態に達している場合、エラーを出さずに0行が更新されることがある。

Databricksの記事は、現在のActivityラッパーが、この0行という結果を常に失敗へ変換するわけではないと認めている。本番コードでは、それを無害と見なす前に保存済みの状態を確認すべきだ。

この詳細は、有用なエンジニアリングの参照実装と、完成された本番パターンを分ける。耐久性のあるオーケストレーションは復旧の仕組みを提供する一方、安全なビジネス上の意味論は依然としてアプリケーション開発者が定義する。

同じ原則は引受業務以外にも当てはまる。決済プロバイダーには冪等性キーが必要であり、メールシステムには安定したメッセージIDが必要であり、対応していないツールには照合記録が必要となる。

社内エージェントを構築するチームには、検索可能な証拠レイヤーも必要だ。構造化されたエンジニアリングナレッジベースは、こうしたワークフローに関する文書、判断、技術的コンテキストを人々が確認する助けになる。

より大きな教訓は明確だ。メモリはモデルの記憶を助け、耐久性のある実行はシステムの継続を助ける。本番エージェントには通常、両方が必要だが、この2つは代替可能ではない。

責務の分離でTemporalとLakebaseを用いた耐久性のあるエージェントを構築する

この設計が機能するのは、TemporalとLakebaseが異なる利用者のために異なる種類の真実を保持するからである。

Temporalは実行上の真実を担う。その履歴が、どのタスクが完了したか、どのタイマーが発火したか、どのSignalsが到着したか、リプレイ中のワーカーが次に何をすべきかを決定する。

Lakebaseは現在のアプリケーションビューを担う。実行ステータス、メッセージ、ツール証拠、レビュー記録、運用イベント、推奨メタデータ、リトライ指標をリレーショナルテーブルに保存する。

この分割により、ユーザーインターフェースは通常のSQLパターンで現在の案件を照会できる。レビュー担当者は保留中の案件を見つけ、1件の推奨内容を確認し、実行間の運用指標を比較できる。

証拠はWorkflowが閉じる前に表示される。ポリシー参照が完了すると、構造化された結果は、閾値、実際の値、ルール結果、根拠、ポリシーソースとともに利用可能になる。

これは人間によるレビューを含むシステムで重要だ。レビュー担当者は、推奨の根拠となる証拠を見るためにプロセス全体の完了を待つべきではない。

アプリケーションは2つのLakebaseスキーマを使用する。agent_opsスキーマは運用記録を保持し、agent_policyには統制された引受ポリシーの読み取り専用コピーが含まれる。

すべてのActivityは、Workflowと整合した識別子を用いて行を書き込む。そのため、データベースの投影が追いつく間も、リトライは同じ論理レコードを更新できる。

LakebaseはTemporalのリプレイの一部にはならない。この境界により、通常のアプリケーション照会がWorkflow実行を決定することを防ぐ一方、両システムをまたぐ更新がアトミックではないことも意味する。

Temporalイベントが記録されても、Lakebaseの投影は一時的に遅れる場合がある。また、Temporalが対応するActivity完了を記録する前に、データベース書き込みがコミットされることもある。

このアーキテクチャはこの隔たりを受け入れ、結果整合性を採用している。結果整合性とは、別々のビューが短時間は不一致でも、リトライと決定論的な書き込みによって最終的に収束することを意味する。

これはダッシュボードや案件一覧には妥当な設計である。ただし、データベースビューをビジネス状態に影響するコマンドの検証に使う場合には、より慎重な扱いが求められる。

Lakebaseは、使い慣れたPostgresアクセスとアプリケーション指向のインデックスを提供する。その運用データベースモデルは、エージェントメモリ、現在の状態、特徴量提供ワークロードもサポートする。

そのコンピュートは、設定された上限内で自動スケールできる。Scale-to-zeroではアイドル状態のコンピュートを停止できるが、非アクティブ状態の後の最初のクエリでは起動レイテンシが発生する可能性がある。

こうしたデータベース機能は、変動の大きいエージェントトラフィックに役立つ。ただし、容量計画、接続上限、プール設定、復旧テストが不要になるわけではない。

ポリシー経路も同様に重要です。Unity Catalog は、クレジットや債務返済比率のルールを含む用途固有のしきい値を保存します。継続的に同期されるテーブルにより、これらの値が Lakebase 内で利用可能になります。

ポリシー所有者は、ワーカーや API を再デプロイすることなくソースを更新できます。後続の参照では、Postgres から伝播済みのルールを読み取れます。

これにより、すべての業務上のしきい値をアプリケーションコードに埋め込む必要がなくなります。同時に、オーケストレーション層が明示的に答えるべきポリシー適用時点の問題も生じます。

進行中の案件は開始時に適用されたルールを維持すべきか、それとも後続のターンで新しいポリシーを採用すべきでしょうか。どちらの選択も、一貫性、監査可能性、顧客対応に影響します。

デモでは、推奨結果とともに適用されたしきい値とそのソースを記録します。この証跡により、レビュー担当者は特定の結果にどのポリシーが影響したかを再構築できます。

Lakebase が利用できない場合、サンプルはフィクスチャのポリシーを使用し、そのフォールバック経路を記録できます。記事が正しく指摘しているように、規制対象のワークフローでは代わりにフェイルクローズとする可能性があります。

この選択をリトライライブラリに委ねることはできません。古いポリシーまたはフォールバックポリシーが法的・運用上許容されるかどうかは、プロダクトオーナー、コンプライアンスチーム、エンジニアが定義する必要があります。

提案された戻り経路では Lakebase Change Data Feed を使用します。有効化すると、データベースの変更を取得し、Unity Catalog が管理する Delta 履歴テーブルに公開できます。

Databricks によると、このフィードは変更をおよそ15秒ごとにバッチ処理します。この間隔は事後的な監査と分析に適しており、アプリケーションは現在の状態を Lakebase から直接読み取ります。

ただし、リポジトリはその経路に向けてスキーマを準備しているだけです。対象環境で観測されたエンドツーエンドのフィード実行は含まれていません。

したがって、Temporal と Lakebase を用いて永続的なエージェントを構築するには、実行上の真実、運用上の真実、ガバナンスされた分析履歴という3つの明確な境界が必要です。

これらの境界が明示されているとき、このパターンは価値を持ちます。チームが「durable」という言葉を、すべてのコンポーネントが常に一致することだと考えると、危険になります。

人によるレビューが一貫性のトレードオフを明らかにする

引受担当者の待機は、耐久性にコマンドの識別子、古い状態の拒否、独立したワークフロー検証が含まれなければならない理由を示しています。

モデルが推奨結果を生成した後、Workflow は実行と現在のターンからレビュー識別子を作成します。保留中のレビューを Lakebase に記録し、AWAITING_REVIEW に入ります。

その後、Temporal はワーカーを占有せずに条件を待機します。人間が応答するまで時間がかかっても、オープンな Workflow はプロセスの置き換えを乗り越えられます。

API は承認、却下、または追加情報の要求を受け付けます。まず、Lakebase が該当するレビューを依然として保留中と示しているかを確認します。

さらに、送信されたレビュー識別子と現在のレビューラウンドを比較します。不一致の場合、明らかに古い判断を転送するのではなく、競合を発生させます。

このデータベース事前チェックはユーザー体験を改善しますが、権威あるものではありません。特に Activity のリトライ中は、Lakebase の投影が Temporal より遅れる可能性があります。

そのため API はコマンドを Signal として送信し、Workflow は実行状態に照らして再度検証します。重複または古い判断は、永続的な制御フロー内で無視されます。

この2回目のチェックは不可欠です。別のレビュー担当者が案件を進めている間もブラウザタブが開いたままになったり、新しいレビューラウンドの開始後に以前のリクエストが到着したりする可能性があります。

HTTP 202 レスポンスは、Temporal が Signal を受信したことだけを確認します。Workflow が業務上の判断を受理したことを意味するわけではありません。

クライアントは、結果として生じた状態を確認するために Lakebase のビューを更新する必要があります。この区別により、トランスポート層の受信確認を融資承認と誤認することを防げます。

Workflow が判断を受理すると、冪等な Lakebase Activity がそれを永続化します。承認または却下により実行は完了します。

追加情報の要求では実行が再開されます。レビュー担当者の根拠が新たなユーザーメッセージとなり、ターンが進み、次の推奨結果には新しいレビュー識別子が割り当てられます。

この仕組みにより、各レビューラウンドに安定した境界が与えられます。また、主要なトレードオフも明確になります。応答性のあるアプリケーション状態は、権威ある実行状態とは別物です。

チームは一時的な不一致を前提に設計する必要があります。インターフェースでは、保留中のコマンド、競合、遅延した投影、拒否された古いアクションを明確に伝えるべきです。

運用ダッシュボードでも、意図的な待機と障害を区別する必要があります。引受担当者を待っている案件は健全ですが、リトライで停止している Activity には介入が必要です。

デモでは、Workflow、ターン、Activity 試行の各レベルでメトリクスを公開しています。運用担当者は Temporal 履歴を調べ、Lakebase の状態を照会し、ワーカー環境を個別に確認できます。

この分離により、遅延の原因が人によるレビュー、モデルの可用性、データベース認証、または失敗したツールのどれなのかを診断しやすくなります。

一方で、運用上の対象領域も増えます。チームは Temporal、Lakebase、ワーカーのデプロイ、接続プール、同期ジョブ、それらを結ぶ契約を監視しなければなりません。

認証は、もう1つの長期的な懸念をもたらします。Lakebase クライアントはマシン間 OAuth を使用し、一時的なデータベース認証情報が期限切れになる前に接続プールを更新します。

認証情報のローテーションがなければ、Workflow 自体が復旧可能であっても、ワーカーは予測可能なスケジュールで失敗する可能性があります。永続的な制御フローは、期限切れの接続を利用可能にはしません。

したがって、永続的なエージェントフレームワークを比較する開発者は、チェックポイント対応だけで判断すべきではありません。コマンドがどのように識別されるか、副作用がどのように重複排除されるか、権威ある状態がどこに存在するかを問うべきです。

また、古いインタラクションも意図的にテストすべきです。2つのレビューセッションを開き、一方を進めた後、古い判断を送信します。

正しい実装であれば、そのコマンドを拒否するか、安全に無視するはずです。また、後から結果を説明できる十分な証跡を保持すべきです。

融資の例が有用なのは、これらの詳細を重要な判断に結び付けているからです。人による承認は、モデル呼び出しの間に置かれた装飾的な停止ではありません。

これは、識別子、認可、ポリシーコンテキスト、監査要件を伴う状態遷移です。そのため、エラー後に再起動する会話アシスタントよりも、耐久性に対する厳しいテストになります。

このデモは本番環境への対応を証明していない

Databricks は信頼できるアーキテクチャを提示していますが、同社自身の証拠でも、融資コンプライアンス、スケール、完全なデータループ検証は未解決のままです。

リポジトリは、ワークフローの順序付け、レビュー動作、OAuth 構築、冪等な永続化、メトリクス契約、API 起動、ワーカー設定を対象とする21件の成功テストを報告しています。

クラッシュリカバリ演習では、決定論的プロバイダーを使用します。ワーカーの実行を停止し、プロセス復帰後も記録済みの進捗が残ることを検証します。

これらのテストは、限定的な耐久性の主張を裏付けます。選択された障害下で、例の制御フローと永続化契約が意図どおり動作することを示しています。

しかし、エージェントが融資システムとして妥当であることまでは検証しません。申請者の記録とプロバイダー応答はフィクスチャであり、デフォルトのスクリプト化されたプロバイダーはライブモデルへの依存を避けています。

リポジトリは、融資モデルの品質、規制遵守、本番セキュリティ、地域での可用性、または大規模なパフォーマンスを立証していません。Databricks はこれらの制限を直接明示しています。

ローカルのクラッシュ演習も、Lakebase を無効にして実行されました。Temporal の復旧を切り分けていますが、完全に統合されたデータ経路全体での復旧は検証していません。

同様に、Change Data Feed の経路は有効化とデプロイの作業として残っています。例ではテーブルを準備していますが、履歴がエンドツーエンドで到着する様子は示していません。

記事が公開された時点で、Change Data Feed は Public Preview でした。成熟したサポートコミットメントや検証済みの地域カバレッジを必要とするチームにとって、プレビューのステータスは重要です。

データベースと Workflow はトランザクションを共有しません。安定した識別子とリトライにより収束は実現しますが、チームには長期化または想定外の不一致に対する照合も必要です。

本番の照合プロセスでは、一致する投影を持たない Workflow を特定すべきです。また、Activity の結果が Event History に入らなかった、コミット済みのデータベース副作用も検出すべきです。

ポリシー同期も同じ厳密さで検討する必要があります。後続の実行はデプロイなしで更新済みポリシーを利用できますが、進行中の実行には文書化されたポリシーバージョンのルールが必要です。

フォールバック動作は別のリスクを生みます。Lakebase が無効である場合、またはポリシー行が利用できない場合、デモはフィクスチャのポリシーに置き換えられます。

この動作はローカル開発には役立ちますが、多くの規制環境ではサイレントフォールバックは許容されません。システムはフォールバックを記録しますが、実行を継続すべきかはポリシー所有者が判断する必要があります。

公開された証拠では、パフォーマンスは未検証のままです。エージェントのワークロードでは、突発的な書き込み、長い履歴、大きなトランスクリプト、不均一なレビューキューが生じる可能性があります。

Temporal の履歴保持、リトライ量、モデルのレイテンシー、ワーカーの並行性、データベース接続制限、投影の更新は、すべてシステム動作に影響します。

Lakebase のオートスケーリングは需要に対応できますが、新規接続とウォームアップ済みデータも依然として重要です。スケールゼロでは、アイドル時の効率と引き換えに起動時のレイテンシーが生じる場合もあります。

セキュリティ要件は TLS と一時的な認証情報にとどまりません。実際の引受プラットフォームには、厳格な認可、機密データ管理、保持ルール、監査アクセスの境界が必要です。

モデルの推奨結果にも独立したガバナンスが必要です。証拠とポリシーを記録することでトレーサビリティは向上しますが、推奨が公正または正確であることは立証されません。

完全な評価では、不利益処分の理由付け、不足した証拠、矛盾するプロバイダーデータ、ポリシー変更、ツール入力を操作しようとする試みをテストします。

また、コンポーネント境界をまたぐ運用インシデントもテストすべきです。例としては、利用不能なポリシー同期、遅延した投影、部分的な認証情報ローテーション、利用不能な外部プロバイダーがあります。

したがって、このアーキテクチャは本番を想定した形ではあるものの、本番認定済みではないものとして読むべきです。この区別は、残る作業を明確にするため、リファレンスの価値を高めます。

Databricks は、オーケストレーション、運用ストレージ、ガバナンスされたデータの間で責任を割り当てる方法を示しました。しかし、実際の負荷の下ですべての契約を検証する必要性をなくしたわけではありません。

このパターンが有効かを示す3つのシグナル

次に必要な証拠は、統合された復旧、ポリシーの一貫性、管理された引受デモを超えた導入を検証するものです。

第1のシグナルは、観測されたエンドツーエンドの Change Data Feed デプロイです。公開されたシステムは運用テーブルを準備していますが、フィードの有効化と宛先の検証は未完了です。

検証が成功した場合は、ツールの証拠から人によるレビューを経て、Unity Catalog が管理する履歴に至るまで、1つの実行を追跡すべきです。また、遅延、重複、スキーマ変更、中断後の復旧も文書化すべきです。

その結果は、運用活動をガバナンスされた分析履歴へ戻せるという主張を強化します。未検証の経路に依存し続けるなら、完全なデータループという説明は弱まります。

第2のシグナルは、復旧テスト全体で Lakebase を使用する、公開された負荷・障害調査です。ワーカーのクラッシュ、データベースのリトライ、認証情報のローテーション、投影の遅延を含めるべきです。

有用な結果では、完了時の動作、リトライの分布、古いコマンドの拒否、アプリケーション状態が収束するまでの時間を報告します。

これにより、Temporal の復旧を単独で検証するのではなく、アーキテクチャを統合システムとしてテストできます。また、スケーリングの限界や運用上のボトルネックがどこで現れるかも明らかになります。

第3のシグナルは、実際に人がレビューするワークフローでの導入です。融資はあくまでデモですが、同様の要件は、保険金請求処理、調達、セキュリティ対応、規制対象の承認に見られます。

信頼できるデプロイメントでは、ポリシーのバージョン管理、状態の整合、フォールバック動作の制御、人による介入の監査をどのように行うかを説明する必要があります。こうした実践は、特定のモデルプロバイダーよりも重要です。

このようなデプロイメントから得られる証拠は、記事の中心的な判断を裏付けるでしょう。耐久性を備えたエージェントは分散アプリケーションであり、その障害を明示的にモデル化しなければなりません。

耐久性を会話のチェックポイントだけに限定するデプロイメントは、逆の方向を示すことになります。副作用、長時間の待機、変化するポリシーが、リカバリー契約の対象外に置かれてしまうためです。

開発者にとって当面の問いは、すべてのエージェントにTemporalとLakebaseが必要かどうかではありません。短時間で読み取り専用のタスクの多くは、2つのマネージドシステムとプロジェクション層を正当化しません。

問うべきなのは、エージェントがワーカーより長く存続できるか、外部状態を変更するか、人を待つ必要があるか、あるいは独立して変化するポリシーを適用するかです。こうした特性が、耐久性のある実行を必要とします。

これらが自社のシステムに当てはまるなら、agent architectureを確認し、クラッシュテストを再現し、再試行可能なすべての副作用を検証してください。続いて、実行上の真実と運用上の真実が一時的に食い違った場合に何が起こるかをテストします。

これが、TemporalとLakebaseを用いて耐久性のあるエージェントを構築しようとするチームにとっての実践的な基準です。まずは重要なワークフローを1つ選び、各システムの権限を定義し、リカバリーの証拠をプロダクトレビューの一部に組み込んでください。