How Temporal Works as a Workflow Engine in a Software Factory

The software factory needs a way to run multi-step processes that survive crashes, network failures, and hour-long model inference calls. Temporal is the leading candidate for that job. It is a durable workflow engine that tracks exactly where every process is, what it is waiting on, and what to do when something fails. But the factory treats Temporal as a replaceable implementation detail, not a load-bearing architectural choice.

What Temporal Provides

Temporal gives the factory durable execution. Each workflow, the path of a single task from intake to merge, is recorded as a series of steps. If the server crashes halfway through a model call, Temporal remembers the exact state and resumes from that point. It handles retries with configurable backoff, timeouts for stalled operations, and signals for external events. The factory does not need to build any of this itself. Temporal is a mature, battle-tested platform for exactly this kind of orchestration.

The factory uses Temporal behind the control plane. The control plane defines what the sequence of steps is. Temporal ensures that sequence runs reliably, even when things go wrong.

Durable Workflows in Practice

A typical factory workflow: intake receives a spec. The control plane starts a Temporal workflow. Step one calls the spec-lint station. Step two calls the spec gate. Step three calls the plan and build stations. Each step writes its output as an artifact, and the workflow advances. If the build station takes too long, Temporal fires a timeout. If the model call fails, Temporal retries with backoff. If the entire process crashes, Temporal resumes from the last completed step when the factory restarts.

The factory does not poll. It does not manage queues. It does not persist workflow state manually. Temporal handles all of that. The factory just defines the steps and lets Temporal worry about reliability.

Temporal Is Replaceable

The decision register calls this D-016, and it is deliberate. Temporal is the leading candidate, but the control plane's contract is so minimal that swapping the engine is a config change. The control plane sequences and records. It never depends on Temporal-specific features. It calls stations through port interfaces. It records transitions through the provenance port. If Temporal were replaced with a simple queue tomorrow, or a serverless workflow, or a custom orchestrator, the control plane would not change. Only the adapter behind the workflow port would change.

This is the hexagonal architecture pattern applied to orchestration. The core defines the sequence. The port defines the interface. The Temporal adapter implements it. The factory does not couple to Temporal. It couples to the sequence contract.

When Temporal Makes Sense

Not every factory needs Temporal. A simple queue with a state machine works for straightforward pipelines. Temporal adds value when processes are long-running, multi-step, and failure-sensitive. Model inference calls that take minutes. Builds that need hours. Approval workflows that wait days for human sign-off. Temporal remembers where each of these is and handles the complexity of resumption, retry, and timeout without the factory code needing to care.

The factory is designed to work with or without Temporal. The control plane is the same either way. Temporal just makes the belt more reliable.