Databricks and Temporal show the state contracts long-running agents actually need

A new Databricks and Temporal reference implementation offers a useful corrective to the idea that an enterprise agent is mainly a prompt, a model and a set of tools. Its personal-loan underwriting demo is built around the less glamorous failure modes that become decisive in production: workers restart, tool calls retry, reviewers answer days later, and policy changes while a case remains open. The practical lesson is that the agent needs explicit contracts for three different kinds of state, not a longer conversation transcript. Databricks describes the architecture and its limits, while the public repository supplies the runnable implementation.

Three stores, three responsibilities

Temporal holds the workflow event history used to replay control flow after a worker failure. Lakebase Postgres holds the application-facing projection: run status, messages, tool calls, evidence, review records and metrics. Unity Catalog remains the source for underwriting policy, exposed to the running application through a synced table. Optional Lakebase Change Data Feed can return operational changes to Unity Catalog-managed history tables for analysis and audit.

That separation matters. Temporal and Lakebase do not share a transaction, so the design assumes at-least-once execution. The sample assigns deterministic identifiers to runs, messages, tool calls, events and review decisions, then combines Postgres uniqueness constraints, upserts and guarded state transitions so a retried activity converges on the same logical record instead of duplicating an effect.

This is the part many agent demos omit: retry behavior belongs in both the orchestrator and the integration. Temporal decides when an activity runs again; each external system still needs an idempotency key, unique constraint or reconciliation mechanism to make that retry safe.

Human review is modeled as durable state

The model can recommend but cannot approve a loan. When a recommendation is ready, the workflow records a stable review ID and waits without occupying a worker. An underwriter can approve, deny or request more information through a Temporal signal. Both the API and workflow validate the review ID so stale or duplicate browser actions do not silently decide the wrong review round.

The pattern is broadly applicable to data agents that pause for query approval, access escalation or a business decision. A relational projection gives an application fast queries over current state; the workflow history remains the authority for execution and recovery.

The caveats are as useful as the architecture

The authors explicitly stop short of calling this production proof. Applicant and provider data are fixtures. The repository does not validate lending models, regulatory compliance, production security controls, regional availability or performance at scale. Its local crash exercise ran with Lakebase disabled, and the Change Data Feed path still requires enablement and end-to-end verification in a target Databricks environment.

The post also identifies a subtle unresolved edge: a guarded Lakebase update can affect zero rows without raising an error, but the current activity wrapper does not always distinguish an expected no-op from a state conflict. Production deployments need to inspect the stored terminal state before accepting that result.

For teams operating analytical or text-to-SQL agents, the blueprint is therefore best read as an implementation checklist rather than a benchmark. Before trusting an agent with a long-running task, define which system owns replay, which projection serves users, how policy reaches open runs, how every side effect deduplicates, how stale approvals are rejected, and how those guarantees will be tested under real failures.