Skip to main content
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

TemporalSmithers
Built forDistributed business transactionsCoding-agent work with human gates
InfrastructureA server cluster (self-hosted or Temporal Cloud) plus worker fleetsOne process and a SQLite file; bunx smithers-orchestrator up
Workflow codeDeterministic by contract: side effects live in activities, code replays against event historyOrdinary TypeScript and JSX; state is re-read, code is never replayed
AgentsYou integrate them yourself inside activitiesClaude Code, Codex, Pi, and AI SDK models are first-class task nodes
HumansSignals and queries you design<Approval>, <HumanTask>, and durable questions in the box
HistoryEvent log per workflowEvery render frame is a row: timeline, rewind, fork, replay, plus filesystem snapshots for the repo the agent edited
AuthoringSDK code in Go, Java, TypeScript, PythonA JSX tree agents write fluently and humans can review at a glance
Operating itA platform team’s job, done wellA 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