> ## Documentation Index
> Fetch the complete documentation index at: https://smithers.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Smithers vs. Temporal

> Temporal is the durable-execution heavyweight for distributed business systems. Smithers brings the same crash-safe guarantees to coding-agent work with no cluster, no workers, and no determinism rules.

Temporal is the reference point for durable execution, and it earned that. If you are building payment processing, order fulfillment, or any high-throughput distributed transaction system with a platform team behind it, Temporal is a great answer and this page will not talk you out of it.

Smithers applies the same core guarantee, "a crash never loses finished work," to a different unit of work: an AI agent editing a real repository over many steps, with humans in the loop. That difference in unit of work drives every design difference below.

## The short version

|                | Temporal                                                                                       | Smithers                                                                                                                     |
| -------------- | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Built for      | Distributed business transactions                                                              | Coding-agent work with human gates                                                                                           |
| Infrastructure | A server cluster (self-hosted or Temporal Cloud) plus worker fleets                            | One process and a SQLite file; `bunx smithers-orchestrator up`                                                               |
| Workflow code  | Deterministic by contract: side effects live in activities, code replays against event history | Ordinary TypeScript and JSX; state is re-read, code is never replayed                                                        |
| Agents         | You integrate them yourself inside activities                                                  | Claude Code, Codex, Pi, and AI SDK models are first-class task nodes                                                         |
| Humans         | Signals and queries you design                                                                 | `<Approval>`, `<HumanTask>`, and durable questions in the box                                                                |
| History        | Event log per workflow                                                                         | Every render frame is a row: `timeline`, `rewind`, `fork`, `replay`, plus filesystem snapshots for the repo the agent edited |
| Authoring      | SDK code in Go, Java, TypeScript, Python                                                       | A JSX tree agents write fluently and humans can review at a glance                                                           |
| Operating it   | A platform team's job, done well                                                               | A developer runs it locally; observability is one command                                                                    |

## The two designs, honestly

**Temporal replays; Smithers re-renders.** Temporal reconstructs workflow state by re-executing your code against an event history, which is why the determinism rules exist: no direct IO, no random, no time, side effects quarantined in activities. It is a powerful model and it scales to enormous throughput. Smithers persists each task's validated output to SQLite and re-renders the workflow tree against that state, so your code has no determinism contract at all. An agent task can shell out, edit files, and call flaky tools, because the unit of recovery is the step, not the instruction.

**The infrastructure floor is different by orders of magnitude.** A Temporal deployment is a service, a database, and worker fleets, or a Temporal Cloud contract. A Smithers deployment is a file next to your repo. That is not a criticism of Temporal; it is the cost of its scale profile. But most teams orchestrating coding agents are one developer with a laptop and a CI runner, and they should not need a platform team to get durable runs.

**Agent work needs things business transactions do not.** Reviewing an agent's work means seeing the diff, rewinding the repo to before the bad decision, and forking an alternate attempt. Smithers snapshots the filesystem alongside the database, so `rewind` and `fork` restore the working tree, not just the workflow state. Approvals, review loops, evals, and prompt optimization ship in the box because agent output quality is part of orchestration, not an application concern layered on top.

## When to pick which

Pick Temporal when the workload is high-volume distributed transactions, the team already runs (or wants) a workflow platform, or you need polyglot SDKs across services. Pick Smithers when the workload is agents doing real work in real repositories, you want durability without operating anything, and humans need to gate what ships. Plenty of teams will run both; they do not compete for the same jobs.

## See also

* [Smithers vs. Claude Code Workflows](/why/vs-claude-code-workflows)
* [Smithers vs. LangGraph](/why/vs-langgraph)
* [How it works](/how-it-works): the render, execute, persist loop in one page