個人貸款承銷是一個天然的持久化代理場景：同一執行流程既要收集徵信、收入等證據，又要按政策評估，並在休息或外部系統等待時接受人工稽核。由於雲端工作節點隨時可能重啟，簡單的請求-響應鏈路無法保證進度不丟失。Databricks 的參考實現借用 Temporal 負責執行控制流，Lakebase Postgres 承載面向應用的可查詢狀態，從而把“已完成的工作”和“接下來該做什麼”分開儲存。
Temporal 的核心是 Workflow 事件歷史。Workflow 代表一次代理執行的確定性控制流；Activity 是對模型、工具或資料庫的呼叫，呼叫結果記錄在事件歷史中並可重試；Signal 則向執行中的 Workflow 傳送非同步指令，例如稽核人的決定。發生故障時，新的工作節點透過回放事件歷史重建狀態，已記錄的 Activity 結果不會再次執行，而未完成記錄的呼叫仍可能再次觸發。因此，模型呼叫、工具呼叫與資料庫寫入分別設定了不同重試策略，避免副作用被無限放大。
Lakebase Postgres 不替代 Temporal，而是儲存應用檢視。agent_ops 中的表記錄執行狀態、訊息、工具呼叫、稽核意見、事件和指標；agent_policy 則是從 Unity Catalog 同步來的只讀策略表。由於二者的寫入不共享事務，活動程式碼需要定義“重複執行也安全”的契約。參考實現採用確定性 ID（run_id、message_id、tool_call_id、review_id 等）作為主鍵或唯一約束，並用 upsert 與守衛更新來確保重試落到同一邏輯行。例如把工具狀態寫回 started 時，只有當前狀態非終態才允許更新；若該行已經 succeeded 或 failed，PostgreSQL 會更新零行而不是報錯。不過生產者程式碼需要檢查受影響行數，並把零行結果分類為預期 no-op 或衝突，這也是生產系統必須注意的邊界。
架構上，React 與 FastAPI 負責 UI、API 和啟動 Workflow，Temporal Cloud 儲存事件歷史並排程任務，工作人員執行回放與各類 Activity。承銷政策以 Unity Catalog 為源，透過連續同步表進入 Lakebase；當寫入 agent_ops 後，若開啟 Lakebase Change Data Feed，還可把執行證據、推薦、稽核決定與指標釋出回 Unity Catalog 管理的 Delta 歷史表，為審計和分析提供統一通道。
作者認為，這種組合最適用於需要跨工作節點存活、長時間等待人工輸入、嚮應用暴露關係型狀態並在執行期間應用治理資料的代理場景。Temporal 決定何時重試，而每個有副作用的工具或資料庫必須自己定義如何處理同一個重試——這正是構建可靠雲代理的關鍵。