Build durable agent workflows using Temporal plus Lakebase

Why durability matters for long-running agent runs

Cloud agents that gather evidence, apply policy, and wait for human review can outlive the worker or process that started them. Typical failure modes include worker restarts, transient tool failures, and waits measured in days. Durable execution must preserve both completed results and the control-flow state that determines what happens next. Without that, runs can lose work, repeat side effects, or block operator visibility.

How the reference underwriting agent ties components together

The reference implementation demonstrates a loan underwriting flow that: collects credit and income evidence, applies policy to produce a recommendation, and waits for a human reviewer. FastAPI assigns a run_id used across the API, the Temporal Workflow, and Lakebase rows. Temporal Workflow state records which Activities have completed and what the agent is waiting for. Activities write evidence, decisions, and metrics into Lakebase so the UI can show current data while the Workflow remains open.

Practical requirements and patterns

The underwriting scenario lists six concrete requirements: recovery, retries, long waits for human or external input, operational visibility, runtime governance for policy changes, and auditability of evidence plus decisions. Implementers should map those requirements to Temporal and Lakebase responsibilities. Temporal handles the durable control flow and replayable Activity results. Lakebase stores the relational operational view and policy lookups.

Because the systems do not share a transaction, Activity execution is at-least-once. Make Postgres updates idempotent. Use deterministic identifiers, constraints, guarded updates, and upserts to ensure repeated Activity attempts target a single logical record without producing duplicate side effects.

When this architecture is most useful

Choose Temporal plus Lakebase when sessions must survive worker replacement, accept input after long waits, expose relational state to a UI or downstream system, and apply governed data that can change while a run is open. This combination is especially useful when Databricks already governs inputs or downstream analytics, because Unity Catalog remains the authoritative policy source while Lakebase provides queryable operational state.

• Keep identifiers deterministic across retries.
• Treat Activities as at-least-once and make database writes idempotent.
• Sync Unity Catalog policy into Lakebase tables so policy updates become available without code deployments.
• Use Lakebase Change Data Feed if you need to publish operational history back to Unity Catalog-managed Delta tables.