When an order, a loan or an assignment stops halfway through, the cost shows up weeks later as a penalty, a refund or a customer who leaves, and every AI agent added to the process is one more step that can stop halfway. At TechFabric our engineers build these systems for automotive and lending companies on Temporal and Databricks. At Location Services, a vehicle recovery company, a missed "Closed" status could lead to a wrongful repossession and the penalty that follows, so we rebuilt that process as a durable workflow on Temporal, and every close now lands, retrying on its own and alerting operations when retries run out. Its repossession platform has since moved onto Databricks, where Lakebase carries the operational data the assignment engine reads and writes, Unity Catalog holds the grants and Unity Gateway sits in front of the model calls.
For the business, that means a process either completes or tells someone it couldn't, and AI spend and data access sit under one set of controls. Databricks keeps the data, the business definitions and the governance, and Temporal keeps track of where each process has got to.
Two questions every distributed system has to answer
Every system that runs a business process across services, vendors and models keeps two kinds of state.
The first is the data: customers, vehicles, loans, inventory, the metrics leadership reads, and the models trained on all of it. It has to be correct, governed, and the same number wherever someone asks for it.
The second is the state of the process: this loan is waiting on a payoff quote, this assignment was sent to the vendor but not confirmed, this agent has called two tools and is waiting for a person to approve the third. That state usually lives nowhere in particular. It's spread across queues, status columns, retry tables and the memory of whichever server happened to be running the job.
The Location Services failure came from not holding the second one at all: the status update had no record of where it had got to, so nothing knew to try again. Databricks has become a very good home for the first. Temporal is the home for the second.
What Databricks covers now
Three parts of Databricks matter most for this kind of system.
Lakebase for operational data
Lakebase is managed Postgres inside Databricks. It reached general availability in January 2026, with autoscaling, scale to zero, instant branching and point-in-time recovery.
At Location Services, Lakebase carries the operational data the assignment engine reads and writes. At DealerIQ, now TotalLoop, the sales intelligence that matches a dealership's customers to cars on the lot moved off Cosmos DB and SQL Server onto Lakebase, and the separate copy that had to be kept in step went away. Branching is the feature I'd point leadership at. Every schema change can be tested on a copy-on-write branch of production data before it ships, which is why we prefer Lakebase over Snowflake Postgres for this kind of work.
Unity Catalog and Unity Gateway for governed AI
Unity Catalog treats models, tools, MCP servers and agents as securable objects, with the same grants you already use for tables. An agent gets EXECUTE on the one function it needs, not the schema.
Unity Gateway, formerly Unity AI Gateway, became generally available in August 2026. It routes every model and MCP request, applies rate limits, budgets and per-user caps, and records who called what. An agent that loops stops at its cap instead of running up spend until someone reads the invoice. I covered the governance side in more detail in Governing AI agents with Databricks and Temporal.
Genie Ontology for domain-oriented applications
This is the piece I think gets the least attention and matters most for applications built around a business domain.
Every domain has words that sound obvious and aren't. In auto finance, a phrase like "active customer" can mean ninety days of transactions to finance and an open account to operations. In a dealership, "equity" depends on which payoff figure and which valuation you use. When an application or an agent has to pick a meaning on its own, two of them asked the same question come back with two different numbers, and both sound sure. We wrote about exactly this in Finance said ninety days, operations said open account.
Databricks puts those definitions in Unity Catalog. Metric views define each business metric once, and dashboards, notebooks, alerts and Genie all query the same view. Genie Ontology, in Public Preview, is the context layer on top. It scores each piece of context by where it came from, how often it's used and how fresh it is, and it only uses context from assets the person asking is allowed to see.
That gives you a practical shape for domain-oriented design. Each domain, whether that's recovery, origination or inventory, owns its definitions as metric views in its own schema. The applications and agents in that domain query those definitions instead of carrying their own copy in code or in a prompt. When the business changes a definition, it changes in one place, and every screen, report and agent reads the new meaning. Our Genie Accuracy work is built around keeping those definitions honest with a regression suite of recorded answers.
What Temporal adds
Databricks answers what the data is and who may touch it. It doesn't remember that step four of a seven-step process failed at three in the morning, and that memory is what Temporal adds.
Temporal runs your business process as a workflow written in ordinary Python, Go, Java, TypeScript or .NET code. Every step it takes is recorded in an event history. Four properties follow from that, and they're the ones leadership should care about.
- Durability. The workflow's state is persisted after every step, so a crashed server, a redeploy or a lost connection doesn't lose the process. It's still waiting exactly where it was.
- Retries. Each call to the outside world, an API, a database write, a model, is an activity with its own retry policy and backoff. Completed steps are never repeated, so a retry doesn't send the email twice or charge the card twice.
- Rehydration. When a worker picks a workflow back up, Temporal replays the history to rebuild its state and carries on from the next step. A process that waits three days for a payoff quote survives every restart in between.
- History. The same record is an audit trail. When someone asks what happened to a given loan or assignment, the answer is a record, not a reconstruction from logs.
Why this matters more for AI in production
An AI agent is a distributed system with an unreliable component in the middle. Model calls time out, hit rate limits and return something unusable. Tool calls fail. Agents run for minutes or hours, and some wait for a person.
An agent loop that keeps its progress in memory loses all of it on a restart, and the usual fix, retrying from the top, repeats tool calls that already had an effect. Put the same agent in a Temporal workflow and each model call and tool call becomes an activity, so a rate limit means waiting and retrying that one call, and a crash means resuming from the last completed step. A human approval becomes a signal the workflow waits for, recorded in its history, so a retry neither skips it nor asks twice. Temporal has an integration with the OpenAI Agents SDK built on this idea.
How the two fit together
Temporal orchestrates. Databricks holds the data, the definitions, the models and the permissions. Each workflow step that needs data or a model goes through Databricks, under Databricks' governance, and the workflow keeps track of where the process has got to.
In practice the split looks like this.
| Concern | Databricks | Temporal |
|---|---|---|
| Operational data | Lakebase (Postgres) | Reads and writes it as activities |
| Analytical data and features | Delta tables, Lakeflow pipelines | Triggers jobs and waits for results |
| Business definitions | Metric views, Genie Ontology | Queries them, never copies them |
| Models and agents | Mosaic AI, Model Serving, Unity Gateway | Calls them as retryable activities |
| Permissions and audit of data | Unity Catalog | Runs each step under the right identity |
| State of the process | Not its job | Event history, timers, signals |
| Failure and recovery | Not its job | Retries, compensation, replay |
Temporal doesn't replace Lakeflow Jobs. Lakeflow Jobs orchestrate data pipelines inside the platform, and they're good at it. Temporal orchestrates business processes that cross systems, where a vendor API, a credit bureau, a model, a person and a Databricks job can all sit in the same run.
Where we've done this
Location Services, vehicle recovery. The workflow we built on Temporal for closing assignments handles the whole lifecycle of a close, from receipt to confirmed transmission to the vendor, with automatic retries, configurable backoff, an alert to operations when retries run out, and a full event history operators read in Temporal's web UI. Location Services' repossession platform has since moved off Synapse and SQL Server onto Databricks in waves that could each be rolled back, and its rules engine came through unchanged.
Athlinks, more than 400 million athlete records. Matching more than 400 million records from sources that never agreed is a job that can't just start over when it dies halfway. We paired a serverless AWS pipeline with Temporal so the compute scaled out while the workflow held the state. Failed steps retry on their own, and failures reach Slack as they happen.
AutoFabric, auto loan origination and refinance. This is our own product, so it's the architecture we can open up. Agents run credit pulls, VIN decode, deal structuring, stipulations and payoff quotes in the lender's environment. Unity Catalog holds the governed data and the permissions the agents inherit, Mosaic AI serves the models, the operator screens are Databricks Apps, and Temporal carries the long-running steps, so a payoff quote that takes days survives a restart. Every action is checked against policy and recorded, which is what a lender needs when an examiner asks why a deal went the way it did.
In each of these, Temporal holds the state of the process, so failure handling lives in the workflow instead of being scattered through the code.
What this means for leadership
Here is what the combination buys, in the terms a board would use.
- Fewer silent failures. A process either completes or tells someone it couldn't. Nothing sits half-finished for a week.
- Scale without a rewrite. Temporal workers scale out horizontally and Lakebase autoscales, so volume growth is a capacity question, not an architecture question.
- AI you can defend. Every agent action has a governed identity in Unity Catalog, a budget in Unity Gateway, a shared definition in a metric view, and a recorded history in Temporal.
- One data platform. The application database, the analytics and the models sit under one governance model instead of three systems kept in step by hand.
- Engineers on the business problem. Retries, timers, idempotency and state come from the platform instead of being rebuilt in every service.
Lakebase has limits on history retention and active computes that we wrote about recently and design around for clients. Temporal workflow code has to be deterministic, so every call to the outside world moves into an activity, which changes how a team writes code. Neither is a reason to wait, but both belong in the plan.
Where to start
Start with the one process that costs the most when it half-completes, where a missed step has a penalty, a customer complaint or a regulator attached. Put a Temporal workflow in front of the services that already run it, with your existing APIs called as activities, so nothing gets rewritten. Move the operational data that process reads and writes into Lakebase. Define the two or three metrics it depends on as metric views, and route any model call through Unity Gateway with a budget.
Then test the failure you're worried about. Kill the worker between the approval and the action, and confirm the workflow resumes without asking twice or acting twice. Once one process runs that way, the second one is mostly new workflows and new grants. If you'd like a hand with the first one, our Databricks and durable execution teams do this work alongside your engineers.
Frequently asked questions
Does Temporal replace Databricks Lakeflow Jobs?
No. Lakeflow Jobs orchestrate data pipelines inside Databricks. Temporal orchestrates business processes that cross systems, such as a vendor API, a model call, a human approval and a Databricks job in one run.
Where does the workflow's state live, Lakebase or Temporal?
Both, for different things. Temporal keeps the state of the process, meaning which step ran, what it returned and what it's waiting for. Lakebase keeps the business data the process reads and writes, such as the loan, the assignment or the order. Keeping them apart means a replayed workflow rebuilds its progress from Temporal's history while the business record stays the single source of truth.
Why use Genie Ontology and metric views instead of putting definitions in the agent's prompt?
Because a definition in a prompt is a copy, and copies drift. A metric view is defined once in Unity Catalog and every dashboard, Genie space and agent queries the same one. Genie Ontology adds context on top and only uses assets the person asking has permission to see, so a domain application gets consistent answers under each user's own grants.